[Bug c/58515] New: Loop optimized away when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58515 Bug ID: 58515 Summary: Loop optimized away when it should not Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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 is incorrect. Older version of GCC I've tried generated proper code. I could not try newer version. To reproduce compile with -O3 the attached file. I found this while fixing the warning that GCC raises when compiling the `fast' function.
[Bug c/58515] Loop optimized away when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58515 Emmanuel Stapf manus at eiffel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Emmanuel Stapf manus at eiffel dot com --- Sorry the test code was not the proper one I intended to use since it seems legitimate that gcc optimizes this away due to the absence of side effects.
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- 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 together that
it fails with:
lisbon [Manu] : gcc -Wall -mlongcall -fPIC -c foo.c
foo.c: In function 'idrf_reset_pos':
foo.c:23: error: unrecognizable insn:
(call_insn 10 9 12 3 (parallel [
(call (mem:SI (symbol_ref:SI (idr_setpos) [flags 0x1]
function_decl 0x48169700 idr_setpos) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 8 [0x8]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 30 30))
(expr_list:REG_DEP_TRUE (use (reg:SI 4 4))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)
foo.c:23: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
where foo.c is simply:
#include stdlib.h
typedef struct idr {
int i_op;
size_t i_size;
char *i_buf;
char *i_ptr;
} IDR;
typedef struct idrs {
IDR i_encode;
IDR i_decode;
} IDRF;
void idr_setpos(IDR *idrs, size_t pos)
{
}
void idrf_reset_pos(IDRF *idrf)
{
idr_setpos(idrf-i_encode, 0);
idr_setpos(idrf-i_decode, 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- 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 --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) It would be nice to reopen the case since it is definitely reproducible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug c/24486] New: gcc generates incorrect assignment because of reordering
Below you will find the C code for which I believe `gcc' generates an incorrect
assignment in `my_buggy_routine' (below) because it computes the destination
address too early. In other word, the assignment:
*(char *)(Current + 9) = my_computation (Current, i);
as the effect of
char * tmp = Current + 9
*tmp = my_computation (Current, i);
but this is incorrect because `Current' was actually modified by
`my_computation' and thus we assign to the wrong location.
I believe 3.x and earlier version of `gcc' were not doing that.
The version of gcc I'm using is the one that comes in Fedora Core 4 running on
a AMD64:
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
The command line I'm using to compile `bug.c' is the following:
gcc -Wall -g bug.c -o bug
There are no errors/warnings triggered by this compilation.
Here is the `bug.c' file:
#include stdio.h
#include stdlib.h
#include string.h
typedef char * REFERENCE;
static REFERENCE * stack [10];
char my_computation (REFERENCE Current, int i) {
*stack[0] = *stack[0] + 10;
return 'a';
}
void my_buggy_routine (REFERENCE Current, int i) {
stack[0] = Current;
*(char *)(Current + 9) = my_computation (Current, i);
}
int main () {
REFERENCE Current;
Current = (REFERENCE) malloc (100);
memset (Current, 0, 10);
my_buggy_routine (Current, 10);
return 0;
}
For reporting the bug, I've used the following command line:
gcc -Wall -g bug.c -o bug -v -save-temps
Which generates the following output
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -E -quiet -v bug.c -mtune=k8
-Wall -fworking-directory -fpch-preprocess -o bug.i
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -mtune=k8 -auxbase bug -g -Wall -version -o bug.s
GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8) (x86_64-redhat-linux)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128087
as -V -Qy -o bug.o bug.s
GNU assembler version 2.15.94.0.2.2 (x86_64-redhat-linux) using BFD version
2.15.94.0.2.2 20041220
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crtn.o
Thanks for looking into that matter.
Regards,
Manu
--
Summary: gcc generates incorrect assignment 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
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- 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. In other words this is a breaking change. Is there an explanation at why this was changed? In my case, I'm doing a moving GC and this will force code generators to always do assignments in 2 steps because of this suprising behavior. Regards, Manu -- manus at eiffel dot com changed: What|Removed |Added CC||manus at eiffel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- 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 gcc 4.0. This includes: - SGI C compiler - Sun C compiler - Borland C - Microsoft C Too bad that gcc 4.0 breaks this. The other things is that it occurs without any optimization. I realize that most of the `unspecified' in the standard is for allowing more optimization, but when you compile without them, it is rather strange that it does this one. Would it make sense to have a new option in `gcc' to say that target is always evaluated after source is? I think that would make transition to gcc 4.0. For now I can only recommend to my users to stick with the 3.x based versions. Regards, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug rtl-optimization/18616] Strange optimization issue
--- 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 this entry. Thanks Manu -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18616
[Bug c/18616] New: Strange optimization issue
= 0;
}
read_int16 (dtype, 1);
read_int16 (nb_gen, 1);
type_array-type_index[dtype] = type_index;
a_conv = type_array-descriptions + type_index;
// Uncomment this line to ensure the condition below is not satisfied.
// printf (%d\n, type_index);
if (!((a_conv-new_type == TYPE_UNDEFINED))) {
exit(0);
}
}
If you comment the `printf' line then the code calls `exit (0)',
if you uncomment it, then it does not call it.
It looks to me that the value of the `rbx' register is incorrect when
there is no `printf' 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 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 madrid.ise 2.6.9-1.667 #1 Tue Nov 2 14:50:10 EST
2004 x86_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18616
[Bug rtl-optimization/18616] Strange optimization issue
--- 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 you have everything you need to see what was incorrectly generated. I've already spend a whole day to figure out where was the bug so I'll be glad to provide you more but I need guidance at what you will find useful or not. Thanks, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18616
[Bug rtl-optimization/18616] Strange optimization issue
--- 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 being replaced by numerical value 0 and 2). I'm trying to reproduce it on a smaller example but I haven't been able to do so yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18616
[Bug rtl-optimization/18616] Strange optimization issue
--- 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
[Bug c/18411] Warning not legitimate
--- 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 generates C code that is compiled most of the time with `gcc'. If people upgrade their `gcc' compiler to 3.4 then the generated code compiles but does not work anymore since it will raise an exception. You said that raising the exception was an acceptable solution for an undefined behavior per the C99 standard. However what you just did is to break existing code that relied on previous implementation of `gcc' (I can tell that we have using this scheme for more than 10 years) and thus this is something for which it might be good to go back to the previous code generation/behavior. If the previous behavior made the inliner crash, then you can either fix it, or consider that a crash is simply a symptom of undefined behavior and therefore you are still compliant to the standard. With best regards, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] New: Warning not legitimate
I'm getting the following compilation warning output:
gcc -c a.c -save-temps
a.c: In function `g':
a.c:8: warning: function called through a non-compatible type
a.c:8: note: if this code is reached, the program will abort
while compiling the following code (content of a.i):
# 1 a.c
# 1 built-in
# 1 command line
# 1 a.c
extern void f();
void g(char a) {
void * fnptr = f;
((void (*) (char)) fnptr) (a);
((void (*) (char)) f)(a);
}
It reports a warning when using `f' but not when using `fnptr'. This is rather
strange and not expected.
Why is it so?
gcc --version is:
gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and was compiled on a AMD64 machine using Linux Fedora Core 3 for x86_64:
uname -a
Linux madrid.ise 2.6.9-1.667 #1 Tue Nov 2 14:50:10 EST 2004 x86_64 x86_64
x86_64 GNU/Linux
Thanks,
Manu
--
Summary: Warning not legitimate
Product: gcc
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] Warning not legitimate
--- 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 (*) (char)) f)(a); but allow: void * fnptr = f; ((void (*) (char)) fnptr)(a); This is rather surprising. Regards, Manu -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] Warning not legitimate
--- 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. */
((void (*) (int)) f)(a); /* Not Ok. */
}
Why `char' does trigger the warning and not `int'? This looks like a bug to
me.
Thanks,
Manu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] Warning not legitimate
--- 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 rather than at run-time, like I did) 2 - make it a warning and generates the code that gcc generated in the past and that has been working for as long as I remember. But definitely don't do: - produces a warning and generate code that will crash your program at run-time. I'm definitely in favor of 2 as it would permit the code I have to continue to work, especially when I know that I provide all the type information to the C compiler so that it can generate the right code. Hopefully someone will listen or convince me otherwise With best regards, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] Warning not legitimate
--- 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 not produce any warning. If you have incompatible types (such as int where you expect a float/double) then I'm ok that you generate a warning (although I would prefer an error since the generated code is incorrect). Or better, if possible, try to fix the inliner issue. Thanks, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
[Bug c/18411] Warning not legitimate
--- 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 in some other module as:
extern void f(char){...}
Then the above code ((void (*) (char)) f)(a); make sense. I'm simply calling
`f' with the right type for the argument thanks to the function cast.
Could you point out where the undefined part is?
Thanks,
Manu
PS: sorry to be so picky on this issue but I feel it is important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
