------- Comment #15 from fejj at novell dot com 2010-01-30 22:11 -------
Since the code works just fine with -O0, -O1 and/or -fno-strict-aliasing (when
using -O2), then it seems to me that gcc is fully capable of doing what I've
asked it to do (therefor DWIM doesn't even enter into the equation, here).
The fact that it doesn't as soon as -O2 optimizations (or above) are turned on
is what is broken.
I understand that the point of the strict-aliasing functionality in gcc is
trying to do some fancy optimizations that it couldn't do normally and I
respect that - if I was explicitly turning on -fstrict-aliasing, I'd be
inclined to agree with you.
However, this is not the case. gcc is auto-enabling strict-aliasing with -O2
and:
1. it never used to do so
2. it does so without warning (why should I have to explicitly ask it to warn
me about something that it is obviously breaking?)
Here's a solution:
if -fstrict-aliasing is not EXPLICITLY requested on the command line (e.g. it
is auto-enabled by means of -O2), then gcc should, when it encounters code like
in my test case, it should compile that code as if -fno-strict-aliasing had
been turned on (e.g. the old default behavior).
It shouldn't be difficult for you guys to implement because you obviously
already have the ability to detect that type of code (e.g.
-Wstrict-aliasing=2).
So in order to fix this, all you need is a tri-state flag for strict-aliasing
optimizations. It seems like it could be done trivially and it would make me
happy (and a lot of other people happy, from what I can tell from googling).
Please?
--
fejj at novell dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
