Darryl Miles <darryl-mailinglists@xxxxxxxxxxxx> writes:
> Ian Lance Taylor wrote:
> > "Adam Olsen" <rhamph@xxxxxxxxx> writes:
> >
> >> For example, if I had "struct { char foo; char bar[3]; }", where my
> >> first thread had a pointer to foo and was modifying it, while my
> >> second thread had a pointer to bar and was modifying it, would that
> >> meet the requirements? My understanding is that a C compiler can (and
> >> in many cases, will) use larger writes so long as they appear the same
> >> for a single-threaded program; this obviously breaks threading though.
> > Yes, that can happen.
>
> Can you cite an example with GCC on a given CPU or do you mean because
> the C specification doesn't rule it out then it is possible for some
> compiler somewhere to use this method of access. So in a purity sense
> "it can happen" but in reality an example maybe difficult to find.
>
> Byte accesses are usually done with byte sized load and store
> instructions. It would seemly require more instructions and more work
> to load / shift / mask / store using larger width load/stores than was
> necessary.
I guess the most relevant question is: when would gcc ever use a
read-modify-write sequence to implement a simple assignment to part of
a struct. You're probably right: gcc will probably never do that if
byte-wite memory access instructions are available. Some processors
of course do not have such instructions, in which case gcc must always
use a read-modify-write sequence for assignments to byte fields.
gcc will combine multiple assignments to struct fields into single
assignments (e.g., combine an assignment to two 8-bit fields into a
single 16-bit write), but that isn't going to cause the error case
which matters here.
Ian
