edBy: fejj at novell dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #1 from fejj at novell dot com 2010-01-30 21:11 ---
Created an attachment (id=19760)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19760&action=view)
list.c
this is a small test-case program to illustrate the bug
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #2 from fejj at novell dot com 2010-01-30 21:13 ---
Created an attachment (id=19761)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19761&action=view)
gdb-log.txt
copy & paste of my gdb session
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #5 from fejj at novell dot com 2010-01-30 21:23 ---
the way I compiled it for that gdb session is as follows:
gcc -Wall -g -O2 -o list list.c
If I use -fno-strict-aliasing or use -O0 (or -O1), it works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #6 from fejj at novell dot com 2010-01-30 21:25 ---
This code has been working since at least gcc 2.7 days and works fine with
other compiles (Sun's, Microsoft's, etc).
Seems like this is a very real bug to me.
--
fejj at novell dot com changed:
--- Comment #9 from fejj at novell dot com 2010-01-30 21:33 ---
gcc should do what I've asked it to do.
if I change the cast to:
tail = (Node *) ((char *) &list);
it works, even with -fstrict-aliasing.
In other words, if I trick gcc into not being "smart", it w
--- Comment #12 from fejj at novell dot com 2010-01-30 21:44 ---
I'm not asking for gcc to be a DWIM compiler, I'm asking for it to do EXACTLY
what I've told it to do.
--
fejj at novell dot com changed:
What|Removed
esn't warn about strict aliasing
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fejj at novell dot com
http://g
--- Comment #15 from fejj at novell dot com 2010-01-30 22:11 ---
Since the code works just fine with -O0, -O1 and/or -fno-strict-aliasing (when
using -O2), then it seems to me that gcc is fully capable of doing what I've
asked it to do (therefor DWIM doesn't even enter into th
--- Comment #16 from fejj at novell dot com 2010-01-30 22:13 ---
> You told it to use C type-based aliasing rules to optimize. And exactly this
> is what it is doing.
Richard, no, I didn't. All I asked was -O2 and -O2 never used to enable
strict-aliasing (in fact, I never
--- Comment #18 from fejj at novell dot com 2010-01-30 22:17 ---
Steven: ok, well, it has never mis-compiled that code before 4.4 and so I never
noticed it I guess.
But now it is mis-compiling the code, so it has come to my attention with
sirens blaring.
--
fejj at novell dot com
--- Comment #20 from fejj at novell dot com 2010-01-30 22:22 ---
Just so we are all on the same page (in case I haven't been clear)
This bug ONLY manifests when using -O2+ if I don't also use
-fno-strict-aliasing.
Meaning: if I do gcc -O0 -fstrict-aliasing, things
--- Comment #21 from fejj at novell dot com 2010-01-30 22:25 ---
Steven:
> FWIW the tri-state solution is problematic because...
Fair enough. This is why you're the gcc developer and not me ;-)
However, correct output should be more important than optimized output.
Also, I
--- Comment #24 from fejj at novell dot com 2010-01-30 23:12 ---
Richard: it seems weird to me that gcc's interpretation of the standard differs
depending on optimization level. Shouldn't it be consistent?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #27 from fejj at novell dot com 2010-01-30 23:34 ---
Steven: okay, thanks for the explanation.
My concern is that if I hit a similar case down the road and someone builds
with different optimization flags than I do, that I'd never figure out the
problem.
It was pure
--- Comment #31 from fejj at novell dot com 2010-02-01 13:08 ---
Michael:
I know that tail->value = is clearly going to evil things (if done
before assigning one of the nodes to tail) because only the first sizeof(void*)
bytes are valid memory addresses. However, if you read the c
--- Comment #34 from fejj at novell dot com 2010-02-03 02:16 ---
just an FYI, but if you take my original list.c attachment and uncomment the
second loop (the one that prints the values of each node after the creation
loop), even if you use `gcc -Wall -g -O2 -o list list.c`, the list
17 matches
Mail list logo
