public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
@ 2009-04-25 13:29 edwintorok at gmail dot com
2009-04-25 13:39 ` [Bug middle-end/39895] " rguenth at gcc dot gnu dot org
` (11 more replies)
0 siblings, 12 replies; 14+ messages in thread
From: edwintorok at gmail dot com @ 2009-04-25 13:29 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
@ 2009-04-25 13:39 ` rguenth at gcc dot gnu dot org
2009-04-25 13:50 ` edwintorok at gmail dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-04-25 13:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
2009-04-25 13:39 ` [Bug middle-end/39895] " rguenth at gcc dot gnu dot org
@ 2009-04-25 13:50 ` edwintorok at gmail dot com
2009-04-25 14:06 ` rguenther at suse dot de
` (9 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: edwintorok at gmail dot com @ 2009-04-25 13:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
2009-04-25 13:39 ` [Bug middle-end/39895] " rguenth at gcc dot gnu dot org
2009-04-25 13:50 ` edwintorok at gmail dot com
@ 2009-04-25 14:06 ` rguenther at suse dot de
2009-04-25 14:12 ` edwintorok at gmail dot com
` (8 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (2 preceding siblings ...)
2009-04-25 14:06 ` rguenther at suse dot de
@ 2009-04-25 14:12 ` edwintorok at gmail dot com
2009-04-25 14:13 ` rguenther at suse dot de
` (7 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: edwintorok at gmail dot com @ 2009-04-25 14:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (3 preceding siblings ...)
2009-04-25 14:12 ` edwintorok at gmail dot com
@ 2009-04-25 14:13 ` rguenther at suse dot de
2009-04-25 14:17 ` rguenther at suse dot de
` (6 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (4 preceding siblings ...)
2009-04-25 14:13 ` rguenther at suse dot de
@ 2009-04-25 14:17 ` rguenther at suse dot de
2009-04-25 14:19 ` edwintorok at gmail dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (5 preceding siblings ...)
2009-04-25 14:17 ` rguenther at suse dot de
@ 2009-04-25 14:19 ` edwintorok at gmail dot com
2009-04-25 14:20 ` rguenther at suse dot de
` (4 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: edwintorok at gmail dot com @ 2009-04-25 14:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (6 preceding siblings ...)
2009-04-25 14:19 ` edwintorok at gmail dot com
@ 2009-04-25 14:20 ` rguenther at suse dot de
2009-04-25 14:22 ` edwintorok at gmail dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (7 preceding siblings ...)
2009-04-25 14:20 ` rguenther at suse dot de
@ 2009-04-25 14:22 ` edwintorok at gmail dot com
2009-04-25 14:25 ` Andrew Pinski
2009-04-25 14:25 ` pinskia at gmail dot com
` (2 subsequent siblings)
11 siblings, 1 reply; 14+ messages in thread
From: edwintorok at gmail dot com @ 2009-04-25 14:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 14:22 ` edwintorok at gmail dot com
@ 2009-04-25 14:25 ` Andrew Pinski
0 siblings, 0 replies; 14+ messages in thread
From: Andrew Pinski @ 2009-04-25 14:25 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (8 preceding siblings ...)
2009-04-25 14:22 ` edwintorok at gmail dot com
@ 2009-04-25 14:25 ` pinskia at gmail dot com
2009-04-25 14:28 ` rguenther at suse dot de
2009-04-25 14:29 ` rguenther at suse dot de
11 siblings, 0 replies; 14+ messages in thread
From: pinskia at gmail dot com @ 2009-04-25 14:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (9 preceding siblings ...)
2009-04-25 14:25 ` pinskia at gmail dot com
@ 2009-04-25 14:28 ` rguenther at suse dot de
2009-04-25 14:29 ` rguenther at suse dot de
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
2009-04-25 13:29 [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
` (10 preceding siblings ...)
2009-04-25 14:28 ` rguenther at suse dot de
@ 2009-04-25 14:29 ` rguenther at suse dot de
11 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2009-04-25 14:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-04-25 14:29 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-25 13:29 [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
2009-04-25 13:39 ` [Bug middle-end/39895] " rguenth at gcc dot gnu dot org
2009-04-25 13:50 ` edwintorok at gmail dot com
2009-04-25 14:06 ` rguenther at suse dot de
2009-04-25 14:12 ` edwintorok at gmail dot com
2009-04-25 14:13 ` rguenther at suse dot de
2009-04-25 14:17 ` rguenther at suse dot de
2009-04-25 14:19 ` edwintorok at gmail dot com
2009-04-25 14:20 ` rguenther at suse dot de
2009-04-25 14:22 ` edwintorok at gmail dot com
2009-04-25 14:25 ` Andrew Pinski
2009-04-25 14:25 ` pinskia at gmail dot com
2009-04-25 14:28 ` rguenther at suse dot de
2009-04-25 14:29 ` rguenther at suse dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).