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

[reed kotler]

On 12/04/2013 09:06 PM, Chandler Carruth wrote:
> On Wed, Dec 4, 2013 at 8:51 PM, reed kotler <rkotler at mips.com 
> <mailto: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.
Clang gets this right. :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131204/2584883b/attachment.html>