[cfe-dev] curious "apparent" gcc bug that clang seems to get right

Chandler Carruth chandlerc at google.com
Wed Dec 4 21:06:13 PST 2013


On Wed, Dec 4, 2013 at 8:51 PM, reed kotler <rkotler at mips.com> wrote:

> I'm not sure myself enough of how, if at all, volatile is inherited into a
> class from it's members.
> But the following code, boiled down from some complicated android code is
> essentially.
>
> This same problem happens for gcc x86 and mips.
>
> Anyone care to weigh in on a proper reading of the C or C++ standard for
> this?
>
> Clang does what not have this problem.
>
> /* mips-linux-gnu-gcc -S a.c -O3 */
> /* gcc -S a.c -O3 */
>
> union {
>         volatile int y;
> } i, j;
>
> void works_as_expected(void) {
>         do {
>                 /* reads j, writes i */
>                 i.y = j.y;
>         } while (1);
> }
>
> void is_this_correct(void) {
>         do {
>                 /* mips: writes j, doesn't reread i */
>

I assume you meant "writes i, doesn't reread j"?


>                 /* x86: rereads j, doesn't write i */
>                 i = j;
>         } while(1);
> }



I don't think there is anything to really be gleaned from the standard
here. It's largely up to the implementation how they want to interpret the
meaning of volatile.

That said, I don't think this interpretation is even remotely useful. I
think it's just a bug. I think the useful interpretation would be the
obvious one based on the reading of aggregate implicit copy assignment
which is to perform member-wise assignment. In turn, that would produce the
same code as your first function if implemented correctly.

If Clang is getting this wrong, I think it's a Clang bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131204/a5933461/attachment.html>


More information about the cfe-dev mailing list