------- Comment #29 from emn13+gcc at nerbonne dot org 2010-02-01 10:16 ------- What's particularly unfortunate about this instance is the fact that gcc fails to warn you about the erroneous code, despite the obvious signs and despite -Wall.
Line 15 is obviously potentially problematic, but it doesn't show up as such even when -Wall is used. This means that any improvement in the optimizer which causes it break similarly invalid code may be terribly hard to debug - the code violates the spec, but there's just no hint that it's wrong (and worse, it works fine when compiled with less optmization, such as for debugging). And additional factor here is that it's statically determinable that this code will violate aliasing rules; line 15 creates an alias, and the next usage of the variable is a write. I realize that perhaps such read/write dependency analysis isn't available at the time that warnings are normally output (I have no idea about gcc innards), but that means that gcc is being presented with code that raises a red flag (line 15), knowably violates the spec (line 22), and yet doesn't even issue a warning even when compiled with -Wall. That's bound to make a gcc-users life hard, particularly as there's a bunch of old c code lying around that's probably not entirely up-to-spec. So, the OP's code is clearly at fault, but that doesn't necessarily mean gcc couldn't do more to prevent this kind of error. -- emn13+gcc at nerbonne dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emn13+gcc at nerbonne dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907