Bug 42908 - gcc -O2 -Wall doesn't warn about strict aliasing
Summary: gcc -O2 -Wall doesn't warn about strict aliasing
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Reported: 2010-01-30 21:54 UTC by fejj
Modified: 2021-08-30 03:40 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2010-01-30 21:57:08


Note You need to log in before you can comment on or make changes to this bug.
Description fejj 2010-01-30 21:54:10 UTC
gcc 4.4.1 doesn't warn about strict aliasing that it encounters with -Wall -O2

See bug #42907.

That -Wall did not warn about the code that it ended up miscompiling.

It should at least warn about strict aliasing when gcc is going to break stuff.
Comment 1 Richard Biener 2010-01-30 22:03:52 UTC
$ gcc-4.4 -S t.c -O2 -Wall -Wstrict-aliasing=2
t.c: In function ‘main’:
t.c:15: warning: dereferencing type-punned pointer might break strict-aliasing rules

you need to enable level 2 to get warnings about this.
Comment 2 Steven Bosscher 2010-01-30 22:06:09 UTC
Is this to avoid false positives, because there's only a hazard if the thing is actually dereferenced later on (or if it's cast back to the "correct" type)?
Comment 3 Steven Bosscher 2010-01-30 22:06:44 UTC
"Is this" as in, "is level two not enabled by default..."
Comment 4 Richard Biener 2010-01-30 22:34:48 UTC
(In reply to comment #3)
> "Is this" as in, "is level two not enabled by default..."

Yes.  It's even exactly documented that way.

Comment 5 Andreia Gaita 2010-02-03 16:13:13 UTC
IMHO, it's not good for strict aliasing warnings on level 2 to be optional and not included in -Wall by default. As it stands right now, gcc does not warn you even if it knows your code is 1) breaking the rules, and 2) the assignments that break the rules are going to be touched by optimizations.

Optimizing away an assignment because that assignment breaks a rule is always a potential danger. Now I know that the reasoning to not show those warnings by default is that it can give you false positives, but a false positive in this case is when you *are* breaking the rules, but an optimization *might* or *might not* break your code. IMHO, just because your code might not break doesn't mean the warning is not needed. A developer really needs to know he's breaking the rules here, regardless of whether things blow up or not.