Bug 39895 - gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
Summary: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-alias...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2009-04-25 13:29 UTC by Török Edwin
Modified: 2009-04-25 14:22 UTC (History)
2 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2009-04-25 13:38:51


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Török Edwin 2009-04-25 13:29:36 UTC
Considering this code:
void dummy(void *x);
union union_t {
    unsigned un;
    char c;
} __attribute__((packed));

unsigned foo()
{
    char x[4];
    dummy(x);
    return ((union union_t*)x)->un;
}

unsigned bar(char *x)
{
    return ((union union_t*)x)->un;
}

With gcc-4.4 -Wstrict-aliasing=1 is the only one that does *not* give a warning, levels 2 and 3 do give warnings:
$ gcc-4.4 -Wstrict-aliasing p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing 
rules
$ gcc-4.4 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing rules
$ gcc-4.4 -Wstrict-aliasing=1 p.c -O2 -c

However in the case of gcc-4.3, -Wstrict-aliasing=2 is the only one that gives warnings, levels 1 and 3 give no warning:
$ gcc-4.3 -Wstrict-aliasing p.c -O2 -c
$ gcc-4.3 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer might break strict-aliasing rules
$ gcc-4.3 -Wstrict-aliasing=1 p.c -O2 -c


According to the gcc manpage -Wstrict-aliasing=3 should have the fewest false positives and false negatives, yet with gcc-4.4 -Wstrict-aliasing=3 gives a warning that is not given at -Wstrict-aliasing=1 (the one that is supposed to have many false positives).

This only happens if 'x' is allocated on the stack, gcc-4.4 is perfectly happy if it is a char* argument to the function.

I've also tried the 'Casting through a union (1)' described at http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html but that too gives warnings by default.

Conclusion is that with gcc-4.4 -O2 -Wall there is no way to read/store from a stack allocated variable through a union, using a different type member of the union without raising a warning. 

Is there another recommended way in gcc-4.4 to cast from uint8_t* to uint32_t*?
Comment 1 Richard Biener 2009-04-25 13:38:51 UTC
Casting through a union (2)

describes an invalid way of doing type-punning.

The only conforming and portable way is

unsigned bar(char *x)
{
    unsigned un;
    memcpy (&un, x, sizeof (un));
    return un;
}

I have no opinion on the different levels of warnings (I think this case
should be unconditionally).
Comment 2 Török Edwin 2009-04-25 13:49:59 UTC
(In reply to comment #1)
> Casting through a union (2)
> 
> describes an invalid way of doing type-punning.

There is also a citation from C99 on that page:
"An object shall have its stored value accessed only by an lvalue expression that has one of the following types:

    * a type compatible with the effective type of the object,
    * a qualified version of a type compatible with the effective type of the object,
    * a type that is the signed or unsigned type corresponding to the effective type of the object,
    * a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
    * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
    * a character type."

I'm casting to a union that has both types as members, why doesn't that fit under the 5th case in the above quote?

Also there is a warning for foo(), but there is no warning for bar(), but I think they are exactly the same things wrt to violating or not the aliasing rules.

> 
> The only conforming and portable way is
> 
> unsigned bar(char *x)
> {
>     unsigned un;
>     memcpy (&un, x, sizeof (un));
>     return un;
> }

That may be too slow for me, I'll go with a static inline function that takes a void* instead of a macro that does the cast.

> 
> I have no opinion on the different levels of warnings (I think this case
> should be unconditionally).
> 

Comment 3 rguenther@suse.de 2009-04-25 14:06:40 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> 
> 
> ------- Comment #2 from edwintorok at gmail dot com  2009-04-25 13:49 -------
> (In reply to comment #1)
> > Casting through a union (2)
> > 
> > describes an invalid way of doing type-punning.
> 
> There is also a citation from C99 on that page:
> "An object shall have its stored value accessed only by an lvalue expression
> that has one of the following types:
> 
>     * a type compatible with the effective type of the object,
>     * a qualified version of a type compatible with the effective type of the
> object,
>     * a type that is the signed or unsigned type corresponding to the effective
> type of the object,
>     * a type that is the signed or unsigned type corresponding to a qualified
> version of the effective type of the object,
>     * an aggregate or union type that includes one of the aforementioned types
> among its members (including, recursively, a member of a subaggregate or
> contained union), or
>     * a character type."
> 
> I'm casting to a union that has both types as members, why doesn't that fit
> under the 5th case in the above quote?

Because it is certainly backwards.

> Also there is a warning for foo(), but there is no warning for bar(), but I
> think they are exactly the same things wrt to violating or not the aliasing
> rules.
> 
> > 
> > The only conforming and portable way is
> > 
> > unsigned bar(char *x)
> > {
> >     unsigned un;
> >     memcpy (&un, x, sizeof (un));
> >     return un;
> > }
> 
> That may be too slow for me, I'll go with a static inline function that takes a
> void* instead of a macro that does the cast.

The above is properly optimized.  Why do you think that an inline
function taking void * would fix anything?

Richard.
Comment 4 Török Edwin 2009-04-25 14:12:10 UTC
(In reply to comment #3)
> 
> The above is properly optimized.  Why do you think that an inline
> function taking void * would fix anything?

I can't know if memcpy will be inlined, it may just be a function call on certain systems, with certain compilers.
The inline function should be a more portable way of expressing what I need, and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already knows I gave my pointer to a function taking void*, so anything could happen with it, right?
Comment 5 rguenther@suse.de 2009-04-25 14:12:51 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, Richard Guenther wrote:

> On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:
> 
> > 
> > 
> > ------- Comment #2 from edwintorok at gmail dot com  2009-04-25 13:49 -------
> > (In reply to comment #1)
> > > Casting through a union (2)
> > > 
> > > describes an invalid way of doing type-punning.
> > 
> > There is also a citation from C99 on that page:
> > "An object shall have its stored value accessed only by an lvalue expression
> > that has one of the following types:
> > 
> >     * a type compatible with the effective type of the object,
> >     * a qualified version of a type compatible with the effective type of the
> > object,
> >     * a type that is the signed or unsigned type corresponding to the effective
> > type of the object,
> >     * a type that is the signed or unsigned type corresponding to a qualified
> > version of the effective type of the object,
> >     * an aggregate or union type that includes one of the aforementioned types
> > among its members (including, recursively, a member of a subaggregate or
> > contained union), or
> >     * a character type."
> > 
> > I'm casting to a union that has both types as members, why doesn't that fit
> > under the 5th case in the above quote?
> 
> Because it is certainly backwards.

Or rather, this refers to a compatible type to the type that was used
to store the value, so it doesn't apply to type-punning.

Richard.
Comment 6 rguenther@suse.de 2009-04-25 14:17:04 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> ------- Comment #4 from edwintorok at gmail dot com  2009-04-25 14:12 -------
> (In reply to comment #3)
> > 
> > The above is properly optimized.  Why do you think that an inline
> > function taking void * would fix anything?
> 
> I can't know if memcpy will be inlined, it may just be a function call on
> certain systems, with certain compilers.
> The inline function should be a more portable way of expressing what I need,
> and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already knows
> I gave my pointer to a function taking void*, so anything could happen with it,
> right?

No, not if it is inlined (and if not you can as well use memcpy).

You can also do (GCC extension)

union union_t {
    unsigned un;
    char c[4];
};

unsigned bar(char *x)
{
  union union_t u;
  u.c[0] = x[0];
  u.c[1] = x[1];
  u.c[2] = x[2];
  u.c[3] = x[3];
  return u.un;
}

but that will even generate worse code with GCC than the
memcpy (it's even horrible code).

Richard.
Comment 7 Török Edwin 2009-04-25 14:18:49 UTC
(In reply to comment #5)
> > > "An object shall have its stored value accessed only by an lvalue expression
> > > that has one of the following types:
> > > 
> > >     * a type compatible with the effective type of the object,
> > >     * a qualified version of a type compatible with the effective type of the
> > > object,
> > >     * a type that is the signed or unsigned type corresponding to the effective
> > > type of the object,
> > >     * a type that is the signed or unsigned type corresponding to a qualified
> > > version of the effective type of the object,
> > >     * an aggregate or union type that includes one of the aforementioned types
> > > among its members (including, recursively, a member of a subaggregate or
> > > contained union), or
> > >     * a character type."
> > > 
> > > I'm casting to a union that has both types as members, why doesn't that fit
> > > under the 5th case in the above quote?
> > 
> > Because it is certainly backwards.
> 
> Or rather, this refers to a compatible type to the type that was used
> to store the value, so it doesn't apply to type-punning.
> 

Yes, the union has a compatibly type to the one used to store the value (it has a char member), hence the union can be used to access the value. I use a different member to access the value, but isn't that what unions are for? :)
Comment 8 rguenther@suse.de 2009-04-25 14:20:47 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> > > >     * an aggregate or union type that includes one of the aforementioned types
> > > > among its members (including, recursively, a member of a subaggregate or
> > > > contained union), or
> > > >     * a character type."
> > > > 
> > > > I'm casting to a union that has both types as members, why doesn't that fit
> > > > under the 5th case in the above quote?
> > > 
> > > Because it is certainly backwards.
> > 
> > Or rather, this refers to a compatible type to the type that was used
> > to store the value, so it doesn't apply to type-punning.
> > 
> 
> Yes, the union has a compatibly type to the one used to store the value (it has
> a char member), hence the union can be used to access the value. I use a
> different member to access the value, but isn't that what unions are for? :)

No, unions are for what in modula or ada are discriminated records, not
for type-punning.  "Manual OO", like the GCC tree union.

Richard.
Comment 9 Török Edwin 2009-04-25 14:22:24 UTC
(In reply to comment #6)
> No, not if it is inlined (and if not you can as well use memcpy).
> 
> You can also do (GCC extension)
> 
> union union_t {
>     unsigned un;
>     char c[4];
> };
> 
> unsigned bar(char *x)
> {
>   union union_t u;
>   u.c[0] = x[0];
>   u.c[1] = x[1];
>   u.c[2] = x[2];
>   u.c[3] = x[3];
>   return u.un;
> }
> 
> but that will even generate worse code with GCC than the
> memcpy (it's even horrible code).

Hmm, looks like the only way out is for me to put #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
Either that or add a configure rule to add -fno-strict-aliasing.
Comment 10 pinskia@gmail.com 2009-04-25 14:25:19 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and 
	-Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:

> Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> Either that or add a configure rule to add -fno-strict-aliasing.

GCC has been able to optimize memcpy since at least 3.0.0 so using:
#if (__GNUC__ >=3)

Should be good enough (undefined macros are substituted with 0 in #if's).

-- Pinski
Comment 11 rguenther@suse.de 2009-04-25 14:28:27 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> ------- Comment #9 from edwintorok at gmail dot com  2009-04-25 14:22 -------
> (In reply to comment #6)
> > No, not if it is inlined (and if not you can as well use memcpy).
> > 
> > You can also do (GCC extension)
> > 
> > union union_t {
> >     unsigned un;
> >     char c[4];
> > };
> > 
> > unsigned bar(char *x)
> > {
> >   union union_t u;
> >   u.c[0] = x[0];
> >   u.c[1] = x[1];
> >   u.c[2] = x[2];
> >   u.c[3] = x[3];
> >   return u.un;
> > }
> > 
> > but that will even generate worse code with GCC than the
> > memcpy (it's even horrible code).
> 
> Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> Either that or add a configure rule to add -fno-strict-aliasing.

Another GCC extension is the following (this is what GCC 4.4 makes
out of the memcpy very early during optimization)

typedef unsigned __attribute__((may_alias,aligned(1))) my_unsigned;

unsigned bar(char *x)
{
    return *(my_unsigned *)x;
}

That should work with even ancient GCC (I checked 3.3)

Richard.
Comment 12 rguenther@suse.de 2009-04-25 14:29:22 UTC
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, pinskia at gmail dot com wrote:

> ------- Comment #10 from pinskia at gmail dot com  2009-04-25 14:25 -------
> Subject: Re:  gcc-4.4 -Wstrict-aliasing and 
>         -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
> 
> On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com
> <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> > Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> > (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> > Either that or add a configure rule to add -fno-strict-aliasing.
> 
> GCC has been able to optimize memcpy since at least 3.0.0 so using:
> #if (__GNUC__ >=3)
>
> Should be good enough (undefined macros are substituted with 0 in #if's).

Not on the tree level though.  At least 4.3 doesn't optimize it there
which may indeed pessimize optimization.

Richard.