Cilkscreen reported a data race in our code. The data race was between the dereference

of a struct pointer so that we could pass a struct to a spawned cilk strand, and a

modificaton to the struct through the pointer after the spawn. We thought that the

arguments to a spawned cilk strand would be evaluation before the strand is created.

We found that cilkscreen reports the data race in the deref.cilk program but not the

deref_works.cilk program. The difference is that we force the struct pointer dereference

before the cilk_spawn rather than in the cilk_spawn function call.

When are the arguments to a spawned cilk strand bound?

If the arguments are bound before spawning the cilk strand, then the deref.cilk program

is correct. However, cilkscreen says that we have a data race between the creation of the

arguments to the spawned function f and the zero of the element on the subsequent line.

This indicates a bug in either the cilk compiler or in cilkscreen.

If the arguments are bound after spawning the cilk strand, the the deref.cilk program

is not correct. However, the cilk programmer's guide is not specific about when

pass by value arguments are evaluated.

If one changes the argument type from a "struct p" to an int, then cilkscreen does not

find any issues. This indicates that the cilk compiler does not handle struct arguments

correctly. This is captured in the deref_int.cilk program.