[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

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*?


-- 
           Summary: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3
                    behaves like -Wstrict-aliasing=2 in gcc-4.3
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-25 13:38 -------
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).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2009-04-25 13:38:51
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

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

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #3 from rguenther at suse dot de  2009-04-25 14:06 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #5 from rguenther at suse dot de  2009-04-25 14:12 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #6 from rguenther at suse dot de  2009-04-25 14:17 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

------- Comment #7 from edwintorok at gmail dot com  2009-04-25 14:18 -------
(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? :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #8 from rguenther at suse dot de  2009-04-25 14:20 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

Re: [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[Andrew Pinski]

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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[pinskia at gmail dot com]

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

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #11 from rguenther at suse dot de  2009-04-25 14:28 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

------- Comment #12 from rguenther at suse dot de  2009-04-25 14:29 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895