[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-21 08:29 --- (In reply to comment #16) (In reply to comment #15) ... I cannot reproduce the problem. I can send you either the compiler binaries (hosts: cygwin/linux i386/linux x64/darwin x64) or the configuration options to build the binutils and the compiler for the arm-eabi target, if you want to. Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I'll see what I can do then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #20 from mikpe at it dot uu dot se 2010-06-21 10:44 --- (In reply to comment #19) Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I don't know if you can build the c++ frontend without libstdc++, but the latter seem to require a libc, so I had to do a 4-step build with newlib: Common options for binutils, gcc, and newlib: --target=arm-unknown-eabi --prefix=/../cross-arm-eabi Initial C-only gcc: --enable-languages=c --disable-libssp Use that to build and install newlib. Final gcc with c++: --enable-languages=c,c++ --with-newlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #21 from mikpe at it dot uu dot se 2010-06-21 11:18 --- (In reply to comment #20) (In reply to comment #19) Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I don't know if you can build the c++ frontend without libstdc++, ... You can. Just build gcc with --target=arm-unknown-eabi --enable-languages=c,c++ --disable-libstdc++-v3 --disable-libssp. No newlib needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #14 from eblot dot ml at gmail dot com 2010-06-20 13:53 --- (In reply to comment #10) I'd suggest generating all dumps, going through them and looking where and why the if statement disappears and how the switch statement evolved before being removed by switch conversion. Let me know how to proceed if you need more dumps. BTW, should not this bug be updated to a confirmed state? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-06-20 16:50 --- (In reply to comment #14) Let me know how to proceed if you need more dumps. Well, at this point I'd generate all tree dumps with -fdump-tree-all and start looking through them. You can tar-gzip them and attach them here too and then I can have a look too but this really seems it is not a bug in anything I wrote so my potential to help you is very much limited, especially since I cannot reproduce the problem. BTW, should not this bug be updated to a confirmed state? I have not seen the bug, I only trust you something wrong is happening under some circumstances (that I even cannot define). So I definitely cannot confirm it either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #16 from eblot dot ml at gmail dot com 2010-06-20 16:57 --- (In reply to comment #15) ... I cannot reproduce the problem. I can send you either the compiler binaries (hosts: cygwin/linux i386/linux x64/darwin x64) or the configuration options to build the binutils and the compiler for the arm-eabi target, if you want to. I'll attach the requested tree dumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #17 from eblot dot ml at gmail dot com 2010-06-20 17:02 --- Created an attachment (id=20947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20947action=view) File output with -fdump-tree-all option switch Here are the requested tree dumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #18 from mikpe at it dot uu dot se 2010-06-20 18:26 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. You need to build a cross to arm-eabi not arm-linux-gnueabi to see the bug. The two ABIs apparently have different data layout rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #6 from eblot dot ml at gmail dot com 2010-06-17 09:20 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. The generated assembly has all four elements in the initialization of CSWTCH.2 and the intermediate tree dumps from the cross compiler are not really different from the ones from a native x86_64 compiler. I think this might be due to the ABI differences between the official ARM ABI (AAPCS) and the Linux variant, which is slightly different. I'd bet the way the enumerations are handled (variable size with AAPCS, fixed, integer-native size with ARM Linux) is the 'culprit' here. See http://www.codesourcery.com/sgpp/lite/arm/arm_gnu_linux_abi.pdf The enumeration used in this bug report is coded as a byte with AAPCS, whereas it should be coded as a 32-bit value with Linux ARM ABI. This might explain why you cannot reproduce the issue with a Linux-target cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #7 from eblot dot ml at gmail dot com 2010-06-17 09:34 ---
(In reply to comment #5)
Could you please first try to reproduce the bug with the
-fno-tree-switch-conversion swithch?
Using GCC 4.5.0 (tarball)
With -fno-tree-switch-conversion switch option switch, the bug does not appear.
Here is the assembly code:
.cpu arm926ej-s
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file gcc-44328.c
.text
.align 2
.global _Z9open_filePKc8OpenMode
.type _Z9open_filePKc8OpenMode, %function
_Z9open_filePKc8OpenMode:
.fnstart
.LFB0:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r1, #2
moveq r1, #3
beq .L2
movhi r1, #75
bls .L8
.L2:
b open
.L8:
cmp r1, #1
moveq r1, #74
movne r1, #1
b .L2
.LFE0:
.cantunwind
.fnend
.size _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode
.ident GCC: 4.5.0
If that helps, the bug is indeed
in the lookup table generation and then I would like you to provide
the dump files generated by switches -fdump-tree-tailr1-slim
-fdump-tree-switchconv
tailr1:
;; Function void open_file(const char*, OpenMode) (_Z9open_filePKc8OpenMode)
void open_file(const char*, OpenMode) (const char * filename, const OpenMode
rw)
{
int mode;
bb 2:
switch (rw_3(D)) default: L1, case 1: L5, case 2: L2, case 3: L3
L1:
goto bb 6 (L5);
L2:
goto bb 6 (L5);
L3:
# mode_1 = PHI 74(2), 1(3), 3(4), 75(5)
L5:
open (filename_9(D), mode_1);
return;
}
switchconv:
;; Function void open_file(const char*, OpenMode) (_Z9open_filePKc8OpenMode)
beginning to process the following SWITCH statement (gcc-44328.c:20) : ---
switch (rw_3(D)) default: L1, case 1: L5, case 2: L2, case 3: L3
Removing basic block 3
Removing basic block 5
Removing basic block 4
Removing basic block 9
Switch converted
Symbols to be put in SSA form
{ .MEM }
Incremental SSA update started at block: 0
Number of blocks in CFG: 10
Number of blocks to update: 5 ( 50%)
void open_file(const char*, OpenMode) (const char * filename, const OpenMode
rw)
{
char csui.2;
const OpenMode csti.0;
int mode;
bb 2:
csui.2_6 = (char) rw_3(D);
csui.2_5 = csui.2_6 + 255;
if (csui.2_5 = 2)
goto bb 8 (L7);
else
goto bb 7 (L6);
L6:
mode_4 = 1;
goto bb 6 (L8);
L7:
csti.0_8 = rw_3(D) + 255;
mode_7 = CSWTCH.1[csti.0_8];
# mode_1 = PHI mode_7(8), mode_4(7)
L8:
L5:
open (filename_9(D), mode_1);
return;
}
Let me know if you still need me to apply your patch or if the above info is
enough to understand the issue. I'll need some extra time to rebuild the
compiler.
Thanks for your help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
Re: [Bug c++/44328] switch/case optimization produces an invalid lookup table index
I bet it could be reproduced on any target with -fshort-enums. On Jun 17, 2010, at 2:20 AM, eblot dot ml at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from eblot dot ml at gmail dot com 2010-06-17 09:20 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. The generated assembly has all four elements in the initialization of CSWTCH.2 and the intermediate tree dumps from the cross compiler are not really different from the ones from a native x86_64 compiler. I think this might be due to the ABI differences between the official ARM ABI (AAPCS) and the Linux variant, which is slightly different. I'd bet the way the enumerations are handled (variable size with AAPCS, fixed, integer-native size with ARM Linux) is the 'culprit' here. See http://www.codesourcery.com/sgpp/lite/arm/arm_gnu_linux_abi.pdf The enumeration used in this bug report is coded as a byte with AAPCS, whereas it should be coded as a 32-bit value with Linux ARM ABI. This might explain why you cannot reproduce the issue with a Linux-target cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #8 from pinskia at gmail dot com 2010-06-17 09:37 --- Subject: Re: switch/case optimization produces an invalid lookup table index I bet it could be reproduced on any target with -fshort-enums. On Jun 17, 2010, at 2:20 AM, eblot dot ml at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from eblot dot ml at gmail dot com 2010-06-17 09:20 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. The generated assembly has all four elements in the initialization of CSWTCH.2 and the intermediate tree dumps from the cross compiler are not really different from the ones from a native x86_64 compiler. I think this might be due to the ABI differences between the official ARM ABI (AAPCS) and the Linux variant, which is slightly different. I'd bet the way the enumerations are handled (variable size with AAPCS, fixed, integer-native size with ARM Linux) is the 'culprit' here. See http://www.codesourcery.com/sgpp/lite/arm/arm_gnu_linux_abi.pdf The enumeration used in this bug report is coded as a byte with AAPCS, whereas it should be coded as a 32-bit value with Linux ARM ABI. This might explain why you cannot reproduce the issue with a Linux-target cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-06-17 14:02 --- (In reply to comment #8) Subject: Re: switch/case optimization produces an invalid lookup table index I bet it could be reproduced on any target with -fshort-enums. Unfortunately no, this switch does not trigger the bug either on my cross compiler or on any of the native compilers I have tried. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-06-17 15:00
---
(In reply to comment #7)
(In reply to comment #5)
Could you please first try to reproduce the bug with the
-fno-tree-switch-conversion swithch?
Using GCC 4.5.0 (tarball)
With -fno-tree-switch-conversion switch option switch, the bug does not
appear.
Really? See below...
tailr1:
;; Function void open_file(const char*, OpenMode) (_Z9open_filePKc8OpenMode)
void open_file(const char*, OpenMode) (const char * filename, const OpenMode
rw)
{
int mode;
bb 2:
switch (rw_3(D)) default: L1, case 1: L5, case 2: L2, case 3: L3
L1:
goto bb 6 (L5);
L2:
goto bb 6 (L5);
L3:
# mode_1 = PHI 74(2), 1(3), 3(4), 75(5)
This already looks wrong. The default branch and the branch for
rw == 0 somehow got merged, which does not look correct to me (or at
least not obviously correct, it seems that the compiler thinks rw can
never be 0 or 3). For this input, the code and the lookup table
produced by the switch conversion pass is exactly what it is supposed
to be. The pass simply puts the three non-default values to the
lookup table and uses the default one if rw is out of bounds.
For the record, my cross (and native) compiler produces the following
PHI node after the switch:
# modeD.1758_1 = PHI 0(2), 74(3), 1(4), 3(5), 75(6)
You can see that the value zero is already missing in yours (I assume
the C compiler works because it gets this correct, possibly among
other things).
switchconv:
void open_file(const char*, OpenMode) (const char * filename, const OpenMode
rw)
{
char csui.2;
When I use -fshort-enums my dumps specifically state unsigned char.
But I assume that char is actually unsigned here by default.
const OpenMode csti.0;
int mode;
bb 2:
csui.2_6 = (char) rw_3(D);
csui.2_5 = csui.2_6 + 255;
if (csui.2_5 = 2)
goto bb 8 (L7);
else
goto bb 7 (L6);
L6:
mode_4 = 1;
goto bb 6 (L8);
L7:
csti.0_8 = rw_3(D) + 255;
mode_7 = CSWTCH.1[csti.0_8];
# mode_1 = PHI mode_7(8), mode_4(7)
L8:
L5:
open (filename_9(D), mode_1);
return;
}
So if rw is zero, csui.2_5 is 255 and mode will be assigned the value
1. I assume this is not what you see happening.
I am not sure if I understand the assembly snippets above 100%
correctly but it seems that the C++ ones do not have any branching in
them which can't be correct. This and the weird missing case in the
original gimple switch statement make me think that the front-end
provides some weird information about the enum type.
I'd suggest generating all dumps, going through them and looking where
and why the if statement disappears and how the switch statement
evolved before being removed by switch conversion. Then we will have
to figure out why this is happening.
Let me know if you still need me to apply your patch or if the above info is
enough to understand the issue. I'll need some extra time to rebuild the
compiler.
No, that is not necessary any longer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #11 from eblot dot ml at gmail dot com 2010-06-17 16:34 --- (In reply to comment #10) With -fno-tree-switch-conversion switch option switch, the bug does not appear. Really? See below... Below is the dump WITHOUT the `-fno-tree-switch-conversion` I did not understand from your previous post that you wanted me to combine the `-fno-tree-switch-conversion` with the dump features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-17 16:37 --- (In reply to comment #11) (In reply to comment #10) With -fno-tree-switch-conversion switch option switch, the bug does not appear. Really? See below... Below is the dump WITHOUT the `-fno-tree-switch-conversion` I did not understand from your previous post that you wanted me to combine the `-fno-tree-switch-conversion` with the dump features. Yes, do not use the option to generate the dumps. However I don't see any dumps below :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #13 from eblot dot ml at gmail dot com 2010-06-17 16:41 --- (In reply to comment #10) When I use -fshort-enums my dumps specifically state unsigned char. But I assume that char is actually unsigned here by default. AAPCS specifies the following (7.1.1) C/C++ type: Machine type char : unsigned byte unsigned char : unsigned byte signed char : signed byte (In reply to comment #12) However I don't see any dumps below :-) My mistake, I meant above ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-15 15:08 ---
Unfortunately I don't see this happening on the x86_64-linux -
arm-linux-gnueabi cross compiler I built for myself. The generated
assembly has all four elements in the initialization of CSWTCH.2 and
the intermediate tree dumps from the cross compiler are not really
different from the ones from a native x86_64 compiler.
Could you please first try to reproduce the bug with the
-fno-tree-switch-conversion swithch? If that helps, the bug is indeed
in the lookup table generation and then I would like you to provide
the dump files generated by switches -fdump-tree-tailr1-slim
-fdump-tree-switchconv
It would be great if you could do that with a gcc (4.5 or trunk)
patched with the following hunk but maybe we will be able to see
something interesting even without it.
Thanks.
Index: gcc/tree-switch-conversion.c
===
--- gcc/tree-switch-conversion.c(revision 160709)
+++ gcc/tree-switch-conversion.c(working copy)
@@ -517,6 +517,13 @@
array_type = build_array_type (value_type, arr_index_type);
ctor = build_constructor (array_type, info.constructors[num]);
TREE_CONSTANT (ctor) = true;
+ if (dump_file)
+ {
+ fprintf (dump_file, \n\nCONSTRUCTOR %i:\n, num);
+
+ print_node (dump_file, , ctor, 0);
+ fprintf (dump_file, \n);
+ }
decl = build_decl (loc, VAR_DECL, NULL_TREE, array_type);
TREE_STATIC (decl) = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #4 from eblot dot ml at gmail dot com 2010-06-04 23:41 --- (fixing up description) -- eblot dot ml at gmail dot com changed: What|Removed |Added Summary|switch/case optimization|switch/case optimization |produces an invalid jump|produces an invalid lookup |table index |table index http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
