<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 4, 2013 at 8:51 PM, reed kotler <span dir="ltr"><<a href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure myself enough of how, if at all, volatile is inherited into a class from it's members.<br>
But the following code, boiled down from some complicated android code is essentially.<br>
<br>
This same problem happens for gcc x86 and mips.<br>
<br>
Anyone care to weigh in on a proper reading of the C or C++ standard for this?<br>
<br>
Clang does what not have this problem.<br>
<br>
/* mips-linux-gnu-gcc -S a.c -O3 */<br>
/* gcc -S a.c -O3 */<br>
<br>
union {<br>
        volatile int y;<br>
} i, j;<br>
<br>
void works_as_expected(void) {<br>
        do {<br>
                /* reads j, writes i */<br>
                i.y = j.y;<br>
        } while (1);<br>
}<br>
<br>
void is_this_correct(void) {<br>
        do {<br>
                /* mips: writes j, doesn't reread i */<br></blockquote><div><br></div><div>I assume you meant "writes i, doesn't reread j"?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

                /* x86: rereads j, doesn't write i */<br>
                i = j;<br>
        } while(1);<br>
}</blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>If Clang is getting this wrong, I think it's a Clang bug. </div></div></div></div>