Re: Re: Weird strict-aliasing break

Re: Re: Weird strict-aliasing break

[Thibault Castel]

> From: Axel Freyn <axel-freyn@gmx.de>
> To: gcc-help@gcc.gnu.org
> Date: Mon, 30 May 2011 11:19:54 +0200
> Subject: 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.
>

I assume that too, so I didn't understand why it didn't complain about
this line.

>  - if you violate strict aliasing, that MIGHT introduce problems
>   (especially during optimization, and if you change values). However,
>   it might work without any problems.
>

Yes, and here, I don't have any problem because it's only a memory
mapping (as we all did in C in the past to read system structs for
example)


>  - 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 tried that too, but it's another warning on another line.
This new warning is triggered on line 54 and 76 and my warning is
always triggered only on line 77 (where the pointer is dereferenced)
and not on line 55 :/

>   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).

That's because of this behavior on new version of gcc I post this
thread here. I don't know if it's gcc-related or code-related.
(Don't misunderstand : my code BREAKS strict aliasing rules, but the
two pieces of code (line 55 and line 77) don't have the same behavior,
and I don't understand why)

>  - 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.

But it's also written (I don't remember where, I'm trying to find the
source) that gcc behavior is undefined when -O2 flag and
-fno-strict-aliasing flag are used together.
I forgot to say that my warning is not triggered with -O0 but appears
only in -O2.

> I don't know of any portable way how to avoid this possible problem (except
> correcting the code...)

I want to correct the code, but I don't know how ! I really don't like
the __attribute__ directive

>
> Axel

Thanks ;)

Re: Re: Weird strict-aliasing break

[Jonathan Wakely]

On 30 May 2011 13:25, Thibault Castel wrote:
>
> But it's also written (I don't remember where, I'm trying to find the
> source) that gcc behavior is undefined when -O2 flag and
> -fno-strict-aliasing flag are used together.

I don't think that's true.

Re: Re: Weird strict-aliasing break

[Thibault Castel]

> ---------- Message transféré ----------
> From: Steffen Dettmer <steffen.dettmer@googlemail.com>
> To: gcc-help@gcc.gnu.org
> Date: Mon, 30 May 2011 13:59:51 +0200
> Subject: Re: Weird strict-aliasing break
> On Mon, May 30, 2011 Thibault Castel <thibault.castel@gmail.com> wrote:
>> 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...
>
> Beside that this may have other disadvantages, such as depending
> on byte order, padding and alighnment issues, in general you
> cannot assume that constructions like:
>
> struct s {
>   int a; // or int32_t
> };
> char buffer[];
>
> struct s *p = buffer;   p->a;
> struct s *p = buffer+1; p->a;
>
> this even may crash (we had such problems on some ARM CPUs).
>

Yes, we have some ARM CPUs as targets but specific code (with such
aligment adaptations) are used. The code I provided is x86 targeted
only ;)

> I think better here is using memcpy, but still "you have to know
> what you are doing".

No, because I don't want to copy anything. I just need to access
fields for reading and extracting data. I don't write into it. It's
really just a memory mapping.

>
> I think the only 100% correct way is proper deserialisation, maybe this way:
>
> struct s *p = new struct s;
> p->a =
>      (int)(buffer[0]) * 0x1000000 +
>      (int)(buffer[1]) * 0x0010000 +
>      (int)(buffer[2]) * 0x0000100 +
>      (int)(buffer[3]);
>
> A better workaround for the alignment probably could be something like:
>
> struct s {
>   int a; // or int32_t
> };
> char buffer[];
>
> union x {
>    struct s;
>    char buffer[1];
> }
>
>> I successfully avoid the warning with "__attribute__((__may_alias__))"
>> but this "cheat" bother me because :
> - you might have a case where it breaks things
>  (such as optimization changes behavior)
>
> I hope some expert corrects me where I'm wrong.

I don't like this directive. If I can avoid it, it would be great.

>
> oki,
>
> Steffen

Thanks