Assignee: unassigned at gcc dot gnu.org
Reporter: manus at eiffel dot com
Created attachment 30885
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30885action=edit
To reproduce code generation issue
If you compile the attached code with -O3 the `slow' function becomes a no-op
which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58515
Emmanuel Stapf manus at eiffel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- 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 when used
--- 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
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
--- 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 the target
--- 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 used except
--- 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
Version: 3.4.2
Status: UNCONFIRMED
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
GCC host triplet: Linux
--- 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 code
--- 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 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-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
: 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
--- 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 reject:
((void
--- 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) (a); /* Ok
--- 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-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 should
--- 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 declared
19 matches
Mail list logo
