Bug 41838 - Incorrect "dereferencing pointer '<anonymous>' does break strict-aliasing rules"
Summary: Incorrect "dereferencing pointer '<anonymous>' does break strict-aliasing rules"
Status: UNCONFIRMED
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
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-26 23:03 UTC by Jeffrey Yasskin
Modified: 2012-01-28 05:40 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
File with incorrect strict-aliasing warning (298 bytes, text/plain)
2009-10-26 23:04 UTC, Jeffrey Yasskin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Yasskin 2009-10-26 23:03:15 UTC
The attached Triple.i, when compiled with `g++ -c -O2 -Wstrict-aliasing Triple.i`, returns:

Triple.i: In function 'void setOSName(const StringRef&)':
Triple.i:9: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules
Triple.i:9: note: initialized from here

Line 9 is:
if (LHSKind == TwineKind) return static_cast<const Twine *>(LHS)->LHSKind;
I believe the warning is incorrect since when LHSKind == TwineKind, LHS is only assigned a Twine*. There's no aliasing through the void*. (And in this subprogram, LHSKind is in fact never ==TwineKind.)

The warning goes away if I delete the __builtin_expect.

$ g++ -v
Using built-in specs.
Target: i386-apple-darwin9
Configured with: ../gcc-4.4.1/configure --prefix=/opt/local --build=i386-apple-darwin9 --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.4.1 (GCC)
Comment 1 Jeffrey Yasskin 2009-10-26 23:04:27 UTC
Created attachment 18908 [details]
File with incorrect strict-aliasing warning
Comment 2 Andrew Pinski 2009-10-26 23:42:53 UTC
> There's no aliasing through the void*.

This is not true.  In fact aliasing is not about what the type of the pointers are but what the dynamic type of what the pointer points to and the access type.

But that is not the issue here though.  
Comment 3 Andrew Pinski 2010-08-12 23:27:09 UTC
Works on the trunk.