This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Weird strict-aliasing break
Hi Thibault,
On Mon, May 30, 2011 at 10:34:40AM +0200, Thibault Castel wrote:
> Hi,
>
> I have a weird warning when compiling my program with g++:
> "dereferencing pointer âNAMEâ does break strict-aliasing rules"
>
> So, I tried to investigate a little bit and find some clues : I do a
> memory mapping from a char buffer to a C struct to have access to
> different datas into the buffer. Pretty casual. But, when I try to
> access one of my inner field, the warning triggers... Huh...
>
> To understand a bit more, I wrote a litte test program outside of my
> project (really huge). See it in attachment. And I don't really
> understand, because the warning is triggered only line 77, not on line
> 55. Only when I try to access the inner fields of a mapped structured
> included into another structure.
>
> I successfully avoid the warning with "__attribute__((__may_alias__))"
> but this "cheat" bother me because :
> - I don't want to fake the compiler
> - I need to compile my huge project both under Linux (gcc/g++) and
> Windows (Visual IDE)
> - This warning is triggered a hundred times in my huge project (old C
> project slowly turning into C++ :/)
>
> I already saw some messages on this list about this warning. But the
> difference here is my program IS working. pFoo->a and pFoo->b have
> correct values.
>
> I tried different scenarios
> - grow or reduce the raw array
> - change the definition order into TData
>
> [...]
>
> Thanks a lot for any clue or explanation
I'm not 100% sure -- however here is my opinion:
- the strict aliasing rules assume that you never access an object
through two pointers of different type "at the same time", so
your code in line 54 violates strict aliasing, too.
- if you violate strict aliasing, that MIGHT introduce problems
(especially during optimization, and if you change values). However,
it might work without any problems.
- gcc warns not about ALL, but only about SOME strict-aliasing
violations. You can adjust the warnings by -Wstrict-aliasing=1 (or
2 or 3). With "-Wstrict-aliasing=2", I also obtain the warning
warn-strict.cpp:54: warning: dereferencing type-punned pointer will break strict-aliasing rules
I think, gcc tries to warn only when it "expects" problems. So
probably gcc is "quite sure" that line 54 does not introduce
problems (for example gcc 4.7 on x86_64 does not warn at all for
your code).
- you can avoid all problems with gcc by using "-fno-strict-aliasing",
which tells gcc not to assume strict aliasing during it's
optimizations: with this option, everything should be safe.
I don't know of any portable way how to avoid this possible problem (except
correcting the code...)
Axel