http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58515
Emmanuel Stapf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: manus at eiffel dot com
Created attachment 30885
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30885&action=edit
To reproduce code generation issue
If you compile the attached code with -O3 the `slow' function bec
--- Comment #7 from manus at eiffel dot com 2008-04-29 04:51 ---
Just adding the version information of gcc:
lisbon [Manu] : gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--- Comment #6 from manus at eiffel dot com 2008-04-28 22:34 ---
I can reproduce this problem with gcc 4.2.3 that comes with Ubuntu 8.04 on
PowerPC with the following command line:
gcc -Wall -mlongcall -fPIC -c foo.c
Removing either `-fPIC' or `-mlongcall' succeeds, it is
--- Comment #4 from manus at eiffel dot com 2005-10-22 17:20 ---
I agree that relying on gcc's behavior might be the wrong thing to do, but when
this is 15 years old code, you can expect that it will still continue to work.
Moreover, it works on all the C compilers I've ever u
--- Comment #2 from manus at eiffel dot com 2005-10-22 16:37 ---
I'm fine that you comply to the standard, but what I was reporting was not an
incoherence with the standard, but with the fact that for the past 15 years
`gcc' has always evaluated the source before evaluating
because of reordering
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: blocker
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manus at eiffel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
--- Additional Comments From manus at eiffel dot com 2004-11-30 01:38
---
It turns out that I had somewhere else a stack corruption that was causing this
behavior. It was strange that adding a printf statement made it work, or that
it was working without optimization.
You can close
--- Additional Comments From manus at eiffel dot com 2004-11-23 02:15
---
I'll try to do my best and will report as soon as I have something more
concrete for you.
Thank you for your attention
Regards,
Manu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18616
--- Additional Comments From manus at eiffel dot com 2004-11-23 01:17
---
Unfortunately I cannot give you the all .i file. However the source code I gave
you is an extract very similar of the .i content corresponding to where the
code generation bug occurs (some upper case macros
--- Additional Comments From manus at eiffel dot com 2004-11-23 00:01
---
Thank you very much for the link to the bug submission page. I had read it and
I provided as much as I could from what is requested. Looks to me that with
the .S output I've included and the actual source
#x27; statement.
Let me know if you need more information.
Thanks,
Manu
--
Summary: Strange optimization issue
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned
--- Additional Comments From manus at eiffel dot com 2004-11-11 20:04
---
Sorry to come back and buzz you again. I just realized that because of this
change in behavior of gcc you broke not just my code, but also the code of the
people using our Eiffel compiler. Indeed our compiler
--- Additional Comments From manus at eiffel dot com 2004-11-10 01:24
---
I believe we do not have the right definition of unspecified behavior. Going
back to my initial post:
extern void f();
void g(char a) {
((void (*) (char)) f)(a);
}
Knowing that actually `f' has been dec
--- Additional Comments From manus at eiffel dot com 2004-11-10 00:59
---
Ok, so why don't you generate the warning only when it makes sense. In my
original case, I was passing a char and tell the C compiler it was a function
pointer expecting a char. In this scenario it shoul
--- Additional Comments From manus at eiffel dot com 2004-11-10 00:42
---
Thanks for your answer. I see that following the ANSI C standard forces you to
do something. But I believe the right thing to do is:
1 - make it a compile time error (better to catch those errors at compile time
--- Additional Comments From manus at eiffel dot com 2004-11-09 23:34
---
Also one thing I forgot to add. Is that if you replace `char' by `int' then
there is no warning at all:
extern void f();
void g(int a) {
void * fnptr = f;
((void (*) (int)) fnptr) (
--- Additional Comments From manus at eiffel dot com 2004-11-09 23:32
---
This is not undefined, I know which feature I'm calling. It is `f'. Moreover I
provide the right function cast which matches how `f' is actually declared.
What strikes me the most is that you
NCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manus at eiffel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
19 matches
Mail list logo
