[Bug c++/44328] New: switch/case optimization produces an invalid jump table index

[Bug c++/44328] New: switch/case optimization produces an invalid jump table index

[eblot dot ml at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9744 bytes --]

Notes: 
 1. the same issue occurs on x86 and x86_64 linux hosts, with a GCC
cross-compiler of the same version is built with the same options
 2. the same issue occurs with GCC cross compiler 4.4.3 (same build options,
without the MPC host library)

I'm afraid I failed to understand something obvious, as this "bug" seems so
weird that I can't really believe it is an actual compiler bug. Please let me
know if/where I'm wrong.

I first encountered this "bug" while compiling the eCos 3.0+ kernel for an
ARM926 target.
The issue appends within the fopen.cxx source file (fopen() implementation):
the 'mode' parameter is converted from a char string - such as "r" - into a
fcntl enumerated value - O_RDONLY in this case, through two switch/case
statements

When built with -O0 or-01, the compiler does not emit a jump table for the
switch/case and the produced 'mode' integer value is the expected one.
When build with -O2 or -O3, the compiler does emit a jump table, but the jump
table is invalid: the net result is that for the '0' case value, the jump table
index points to an address that is outside the jump table, and the value
returned from the jump table is random.

When the -Wtype-limits option switch is used, the compiler does emit a warning,
but I failed to understand the reason for this warning.

I shrinked down the 'fopen.cxx' code to a single, simple function and the
assembly code contains the same invalid statement as it is in the original
file, the type-limits warning is also the same.
The source code does not rely on any other file (no header file).

//------------- C source ----------------------------------------------

#define O_RDONLY     (1<<0)
#define O_WRONLY     (1<<1)
#define O_RDWR       (O_RDONLY|O_WRONLY)
#define O_CREAT      (1<<3)
#define O_TRUNC      (1<<6)

typedef enum {
    OM_READ = 0,
    OM_WRITE,
    OM_READWRITE_NOCREATE,
    OM_READWRITE_CREATE
} OpenMode;

extern "C" int open(const char *name, int mode);

void open_file(const char *filename, const OpenMode rw)
{
    int mode = 0;

    switch( rw )
    {
    case OM_WRITE:
        mode = O_WRONLY|O_CREAT|O_TRUNC;
        break;
    case OM_READ:
        mode = O_RDONLY;
        break;
    case OM_READWRITE_NOCREATE:
        mode = O_RDWR;
        break;
    case OM_READWRITE_CREATE:
        mode = O_RDWR|O_CREAT|O_TRUNC;
        break;
    }

    open( filename, mode );
}
// ----------------- end of C code ------------------------------------

The above C code is built with the following command:
arm-eabi-gcc -c -O2 -mcpu=arm926ej-s -fno-rtti -fno-exceptions -Wtype-limits \
 -o fopen.o fopen.cxx 

The compiler emits the following warning:
fopen.cxx: In function ‘void open_file(const char*, OpenMode)’:
fopen.cxx:16:6: warning: comparison always true due to limited range of data
type

The disassemble code looks like the following:

//------------- ASM ---------------------------------------------------
fopen.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <_Z9open_filePKc8OpenMode>:
   0:   e59f300c        ldr     r3, [pc, #12]   ; 14
<_Z9open_filePKc8OpenMode+0x14>
   4:   e2411001        sub     r1, r1, #1
   8:   e20110ff        and     r1, r1, #255    ; 0xff
   c:   e7931101        ldr     r1, [r3, r1, lsl #2]
  10:   eafffffe        b       0 <open>
  14:   00000000        andeq   r0, r0, r0

Disassembly of section .rodata:

00000000 <CSWTCH.1>:
   0:   0000004a        andeq   r0, r0, r10, asr #32
   4:   00000003        andeq   r0, r0, r3
   8:   0000004b        andeq   r0, r0, r11, asr #32
//------------- end of ASM --------------------------------------------

The jump table should contain 4 entries. It is only 3 entry wide.
There's no entry for 'case OM_READ'.
Nevertheless, the compiler shifts the index (sub r1, r1, #1), as if the
switch() value were starting from 1, rather than from 0.
When switch (OM_READ) is executed, r1 is decremented from 0 to 0xffffffff,
then masked to a single byte 0xff, following the ARM AAPCS variable-width
enumerated types.
This new index is used to access the jump table, but index 0xff is out of the 
jump table.

Notes:
 * If OpenMode enum is forced to start from 1 -rather than 0-, the emitted code
   is valid (4-entry jump table):
     OM_READ = 1
 * If OpenMode enum is simply added another entry, the emitted code changes 
   and becomes valid (4-entry jump table):
     OM_READWRITE_CREATE,
     OM_DUMMY,
 * If mode is not initialized to a default value, but mode is assigned the
   same value (0) within a 'default', emitted code is valid:
     int mode;
     //
     default: mode = 0; break;

The compiler has been built with the following options:
$> arm-eabi-gcc -c -O2 -mcpu=arm926ej-s -fno-rtti -fno-exceptions -o fopen.o
fopen.cxx -Wtype-limits -v
Using built-in specs.
COLLECT_GCC=arm-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/4.5.0/lto-wrapper
Target: arm-eabi
Configured with: ../configure
--prefix=/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0 --target=arm-eabi
--disable-shared --with-gnu-as --with-gnu-ld --with-newlib --enable-softfloat
--disable-bigendian --disable-fpu --disable-underscore --enable-multilibs
--with-float=soft --enable-interwork --enable-lto
--with-multilib-list=interwork --with-abi=aapcs --enable-languages=c,c++
--disable-__cxa_atexit --with-gmp=/usr/local/homebrew/Cellar/gmp/5.0.1
--with-mpfr=/usr/local/homebrew/Cellar/mpfr/2.4.2
--with-mpc=/usr/local/homebrew/Cellar/libmpc/0.8.1
--with-ppl=/usr/local/homebrew/Cellar/ppl/0.10.2
--with-cloog=/usr/local/homebrew/Cellar/cloog-ppl/0.15.7
--with-libelf=/usr/local/homebrew/Cellar/libelf/0.8.13
--with-gxx-include-dir=/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/arm-eabi/include
--disable-debug 
Thread model: single
gcc version 4.5.0
COLLECT_GCC_OPTIONS='-c' '-O2' '-mcpu=arm926ej-s' '-fno-rtti' '-fno-exceptions'
'-o' 'fopen.o' '-Wextra' '-save-temps' '-v' '-mfloat-abi=soft' '-mabi=aapcs'

/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/4.5.0/cc1plus
-E -quiet -v -D__USES_INITFINI__ fopen.cxx -mcpu=arm926ej-s -mfloat-abi=soft
-mabi=aapcs -Wextra -fno-rtti -fno-exceptions -O2 -fpch-preprocess -o fopen.ii
ignoring nonexistent directory
"/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/../../../../arm-eabi/sys-include"
ignoring duplicate directory
"/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/../../../../arm-eabi/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/arm-eabi/include
 /usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/arm-eabi/include/arm-eabi
 /usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/arm-eabi/include/backward
 /usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/include

/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-c' '-O2' '-mcpu=arm926ej-s' '-fno-rtti' '-fno-exceptions'
'-o' 'fopen.o' '-Wextra' '-save-temps' '-v' '-mfloat-abi=soft' '-mabi=aapcs'

/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/4.5.0/cc1plus
-fpreprocessed fopen.ii -quiet -dumpbase fopen.cxx -mcpu=arm926ej-s
-mfloat-abi=soft -mabi=aapcs -auxbase-strip fopen.o -O2 -Wextra -version
-fno-rtti -fno-exceptions -o fopen.s
GNU C++ version 4.5.0 (arm-eabi)
        compiled by GNU C version 4.2.1 (Apple Inc. build 5659), GMP version
5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ version 4.5.0 (arm-eabi)
        compiled by GNU C version 4.2.1 (Apple Inc. build 5659), GMP version
5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dc4afb9bd29f2a2942808dba7d87c9cb
fopen.cxx: In function ‘void open_file(const char*, OpenMode)’:
fopen.cxx:17:6: warning: comparison always true due to limited range of data
type
COLLECT_GCC_OPTIONS='-c' '-O2' '-mcpu=arm926ej-s' '-fno-rtti' '-fno-exceptions'
'-o' 'fopen.o' '-Wextra' '-save-temps' '-v' '-mfloat-abi=soft' '-mabi=aapcs'

/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/../../../../arm-eabi/bin/as
-v -mcpu=arm926ej-s -mfloat-abi=soft -meabi=5 -o fopen.o fopen.s
GNU assembler version 2.20.1 (arm-eabi) using BFD version (GNU Binutils)
2.20.1.20100303
COMPILER_PATH=/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/4.5.0/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/4.5.0/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/libexec/gcc/arm-eabi/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/../../../../arm-eabi/bin/
LIBRARY_PATH=/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/:/usr/local/homebrew/Cellar/gcc-arm-ecos/4.5.0/lib/gcc/arm-eabi/4.5.0/../../../../arm-eabi/lib/
COLLECT_GCC_OPTIONS='-c' '-O2' '-mcpu=arm926ej-s' '-fno-rtti' '-fno-exceptions'
'-o' 'fopen.o' '-Wextra' '-save-temps' '-v' '-mfloat-abi=soft' '-mabi=aapcs'


-- 
           Summary: switch/case optimization produces an invalid jump table
                    index
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eblot dot ml at gmail dot com
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: arm-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug c++/44328] switch/case optimization produces an invalid jump table index

[eblot dot ml at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]



------- Comment #1 from eblot dot ml at gmail dot com  2010-05-30 10:36 -------
Update: This is a C++ only bug, the same code in C language does not exhibit
the bug:


# --- Building as C language ---
$> arm-eabi-gcc -c -O2 -mcpu=arm926ej-s -o fopen.o -x c fopen.c -Wextra
-save-temps && cat fopen.s
        .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   "fopen.c"
        .text
        .align  2
        .global open_file
        .type   open_file, %function
open_file:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        cmp     r1, #3
        ldrls   r3, .L4
        movhi   r1, #0
        ldrls   r1, [r3, r1, asl #2]
        b       open
.L5:
        .align  2
.L4:
        .word   .LANCHOR0
        .size   open_file, .-open_file
        .section        .rodata
        .align  2
        .set    .LANCHOR0,. + 0
        .type   CSWTCH.1, %object
        .size   CSWTCH.1, 16
CSWTCH.1:
        .word   1
        .word   74
        .word   3
        .word   75
        .ident  "GCC: 4.5.0"

# --- Building as C++ language ---
arm-eabi-gcc -c -O2 -mcpu=arm926ej-s -o fopen.o -x c++ fopen.c -Wextra
-save-temps && cat fopen.s
fopen.c: In function ‘void open_file(const char*, OpenMode)’:
fopen.c:16:6: warning: comparison always true due to limited range of data type
        .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   "fopen.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.
        ldr     r3, .L2
        sub     r1, r1, #1
        and     r1, r1, #255
        ldr     r1, [r3, r1, asl #2]
        b       _Z4openPKci
.L3:
        .align  2
.L2:
        .word   .LANCHOR0
.LFE0:
        .cantunwind
        .fnend
        .size   _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode
        .section        .rodata
        .align  2
        .set    .LANCHOR0,. + 0
        .type   CSWTCH.1, %object
        .size   CSWTCH.1, 12
CSWTCH.1:
        .word   74
        .word   3
        .word   75
        .ident  "GCC: 4.5.0"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug c++/44328] switch/case optimization produces an invalid jump table index

[mikpe at it dot uu dot se]

------- Comment #2 from mikpe at it dot uu dot se  2010-05-30 14:50 -------
I can confirm this wrong-code when gcc 4.4/4.5 targets arm-unknown-eabi.
However, a 4.4/4.5 running natively on arm-unknown-linux-gnueabi does not
exhibit this behaviour.  There there's no 'comparison always true' warning, and
the generated code contains conditional instructions where the arm-unknown-eabi
gcc emitted unconditional instructions.

This is what 4.5-20100527 generates for me on arm-unknown-linux-gnueabi:

        sub     r1, r1, #1
        cmp     r1, #2
        ldrls   r3, .L4
        movhi   r1, #1
        ldrls   r1, [r3, r1, asl #2]
        b       open
.L5:
        .align  2
.L4:
        .word   .LANCHOR0
        .size   _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode
        .section        .rodata
        .align  2
.LANCHOR0 = . + 0
        .type   CSWTCH.2, %object
        .size   CSWTCH.2, 12
CSWTCH.2:
        .word   74
        .word   3
        .word   75

My guess is that the subtract+compare is done in a too narrow mode, resulting
in the warning and subsequent omission of the conditionals.

Also, it's not a jump table but a lookup table.


-- 

mikpe at it dot uu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug c++/44328] switch/case optimization produces an invalid jump table index

[eblot dot ml at gmail dot com]

------- Comment #3 from eblot dot ml at gmail dot com  2010-05-30 17:36 -------
> I can confirm this wrong-code when gcc 4.4/4.5 targets arm-unknown-eabi.
> However, a 4.4/4.5 running natively on arm-unknown-linux-gnueabi does not
exhibit this behaviour. 

IIRC, Linux ABI does not follow the ARM AAPCS that uses variable-width
enumeration.
On Linux, enumerated values are stored as a native integer value, whatever the
enumerated values. With AAPCS/ATPCS, if the enumerated values can be stored as
a byte, a byte is used: --with-abi=aapcs
I don't know if the issue is related to this ABI discrepancy.

> Also, it's not a jump table but a lookup table.
Sorry, my mistake.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug c++/44328] switch/case optimization produces an invalid lookup table index

[eblot dot ml at gmail dot com]

------- 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

[Bug c++/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[Bug c++/44328] switch/case optimization produces an invalid lookup table index

[pinskia at gmail dot com]

------- 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-bugzilla@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

Re: [Bug c++/44328] switch/case optimization produces an invalid lookup table index

[Andrew Pinski]

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-bugzilla@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

[jamborm at gcc dot gnu dot org]

------- 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

[jamborm at gcc dot gnu dot org]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[jamborm at gcc dot gnu dot org]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[jamborm at gcc dot gnu dot org]

------- 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

[eblot dot ml at gmail dot com]

------- 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

[eblot dot ml at gmail dot com]

------- 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=20947&action=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

[mikpe at it dot uu dot se]

------- 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

[jamborm at gcc dot gnu dot org]

------- 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

[mikpe at it dot uu dot se]

------- 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

[mikpe at it dot uu dot se]

------- 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 tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ramana at gcc dot gnu dot org]

------- Comment #22 from ramana at gcc dot gnu dot org  2010-07-05 13:43 -------
With trunk as of a couple of days back - the testcase when compiled with
-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp for EABI generates the following
code for C++ but not for C.

Notice the removal of the check of the condition for being out of range 

Z9open_filePKc8OpenMode:
        @ Function supports interworking.
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        stmfd   sp!, {r3, lr}
        ldr     r3, .L2
        ldr     r1, [r3, r1, asl #2]
        bl      open
        ldmfd   sp!, {r3, lr}
        bx      lr
.L3:
        .align  2
.L2:
        .word   .LANCHOR0
        .size   _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode
        .section        .rodata
        .align  2
        .set    .LANCHOR0,. + 0
        .type   CSWTCH.1, %object
        .size   CSWTCH.1, 16
CSWTCH.1:
        .word   1
        .word   74
        .word   3
        .word   75
        .ident  "GCC: (GNU) 4.6.0 20100702 (experimental)"



Same file compiled in "C".


open_file:
        @ Function supports interworking.
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        cmp     r1, #3
        stmfd   sp!, {r3, lr}
        ldrls   r3, .L4
        movhi   r1, #0
        ldrls   r1, [r3, r1, asl #2]
        bl      open
        ldmfd   sp!, {r3, lr}
        bx      lr
.L5:
        .align  2
.L4:
        .word   .LANCHOR0
        .size   open_file, .-open_file
        .section        .rodata
        .align  2
        .set    .LANCHOR0,. + 0
        .type   CSWTCH.1, %object
        .size   CSWTCH.1, 16
CSWTCH.1:
        .word   1
        .word   74
        .word   3
        .word   75
        .ident  "GCC: (GNU) 4.6.0 20100702 (experimental)"


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |tree-optimization
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.0
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-05 13:43:01
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jifl-bugzilla at jifvik dot org]

------- Comment #23 from jifl-bugzilla at jifvik dot org  2010-07-24 22:23 -------
I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.


-- 

jifl-bugzilla at jifvik dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl-bugzilla at jifvik dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ian dot bolton at arm dot com]

------- Comment #24 from ian dot bolton at arm dot com  2010-08-02 12:23 -------
(In reply to comment #23)
> I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
> 

I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
I do get the warning and incorrect code in latest 4.5 branch (4.5.1 -
20100727).


-- 

ian dot bolton at arm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian dot bolton at arm dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ian dot bolton at arm dot com]

------- Comment #25 from ian dot bolton at arm dot com  2010-08-02 13:33 -------
(In reply to comment #24)
> (In reply to comment #23)
> > I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
> > 
> 
> I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
> I do get the warning and incorrect code in latest 4.5 branch (4.5.1 -
> 20100727).
> 

And trunk, as of 20100727 (4.6.0), is also OK (no warning and correct code).

I am configuring with:

--target=arm-unknown-eabi --with-cpu=cortex-a9 --enable-languages=c,c++

And building with:

-c -O2 -mcpu=arm926ej-s -x c++ ~/pr44328.cpp -Wextra -save-temps -S


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ian dot bolton at arm dot com]

------- Comment #26 from ian dot bolton at arm dot com  2010-08-03 17:09 -------
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
> > > 
> > 
> > I get no warning and correct code in latest 4.4 branch (4.4.5 - 20100727), but
> > I do get the warning and incorrect code in latest 4.5 branch (4.5.1 -
> > 20100727).
> > 
> 
> And trunk, as of 20100727 (4.6.0), is also OK (no warning and correct code).
> 
> I am configuring with:
> 
> --target=arm-unknown-eabi --with-cpu=cortex-a9 --enable-languages=c,c++
> 
> And building with:
> 
> -c -O2 -mcpu=arm926ej-s -x c++ ~/pr44328.cpp -Wextra -save-temps -S
> 

My mistake.  I had incorrectly invoked the linux target compiler when doing my
4.4 testing. :-(

I actually DO get the warning and incorrect code with latest 4.4 branch and 4.5
branch.

Trunk does work correctly though, because the gimple pass keeps the default
case and the case 0 distinct nowadays (unless you specify -fstrict-enums),
whereas 4.4 and 4.5 both merge the default case in with the case 0 due to the
fact that the switch enumerates all possible values of the OpenMode.

Here is key line from the 004t.gimple dump for 4.4 and 4.5 (and 4.6 with
-fstrict-enums):

  switch (D.1763) <default: <D.1759>, case 0: <D.1759>, case 1: <D.1758>, case
2: <D.1760>, case 3: <D.1761>>

See how default and case 0 both go to the same place.

Here is the equivalent line from 004t.gimple from 4.6 (without -fstrict-enums):

  switch (D.1766) <default: <D.1767>, case 0: <D.1759>, case 1: <D.1758>, case
2: <D.1760>, case 3: <D.1761>>

See how default and case 0 go to different places.

This therefore explains why 4.6 works with the reporter's commandline args.

I am fairly sure the actual bug is in tree-switch-conversion.c, and I feel a
bug fix is imminent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

------- Comment #27 from jamborm at gcc dot gnu dot org  2010-09-01 11:10 -------
As far as I understand it, this is fixed with
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00577.html


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

------- Comment #28 from jamborm at gcc dot gnu dot org  2010-09-01 11:23 -------
Hm, no, I was too quick pruning my inbox.  The patch apparently has
not been applied to the 4.5 branch.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

------- Comment #29 from jamborm at gcc dot gnu dot org  2010-09-01 11:24 -------
I'll do that, hopefully sooner rather than later.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
                   |dot org                     |org
             Status|REOPENED                    |ASSIGNED
   Last reconfirmed|2010-07-05 13:43:01         |2010-09-01 11:24:15
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ibolton at gcc dot gnu dot org]

------- Comment #30 from ibolton at gcc dot gnu dot org  2010-09-01 11:25 -------
(In reply to comment #28)
> Hm, no, I was too quick pruning my inbox.  The patch apparently has
> not been applied to the 4.5 branch.
> 

It's on its way.  I've been testing in conjunction with a couple of other
backports and ran into some issues unrelated to this patch.  I'm hoping to be
ready to apply to 4.5 tomorrow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jamborm at gcc dot gnu dot org]

------- Comment #31 from jamborm at gcc dot gnu dot org  2010-09-01 11:32 -------
(In reply to comment #30)
> (In reply to comment #28)
> > Hm, no, I was too quick pruning my inbox.  The patch apparently has
> > not been applied to the 4.5 branch.
> > 
> 
> It's on its way.  I've been testing in conjunction with a couple of other
> backports and ran into some issues unrelated to this patch.  I'm hoping to be
> ready to apply to 4.5 tomorrow.
> 

OK, reassigning to you then.  Please do not forget to add a hunk
adding the new dependence of tree-switch-conversion.o in Makefile.in.

Thanks.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jamborm at gcc dot gnu dot  |ibolton at gcc dot gnu dot
                   |org                         |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jifl-bugzilla at jifvik dot org]

------- Comment #32 from jifl-bugzilla at jifvik dot org  2010-09-01 11:47 -------
I don't know if there are plans for more releases in the 4.4 series, but can it
be applied to the 4.4 branch too?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[jakub at gcc dot gnu dot org]

------- Comment #33 from jakub at gcc dot gnu dot org  2010-09-01 11:50 -------
Yes, 4.4.5 and maybe 4.4.6 is planned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ibolton at gcc dot gnu dot org]

------- Comment #34 from ibolton at gcc dot gnu dot org  2010-09-02 13:10 -------
(In reply to comment #33)
> Yes, 4.4.5 and maybe 4.4.6 is planned.
> 

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #28)
> > > Hm, no, I was too quick pruning my inbox.  The patch apparently has
> > > not been applied to the 4.5 branch.
> > > 
> > 
> > It's on its way.  I've been testing in conjunction with a couple of other
> > backports and ran into some issues unrelated to this patch.  I'm hoping to be
> > ready to apply to 4.5 tomorrow.
> > 
> 
> OK, reassigning to you then.  Please do not forget to add a hunk
> adding the new dependence of tree-switch-conversion.o in Makefile.in.
> 
> Thanks.
> 

I have just committed the backport to 4.5 branch.

I will start on the 4.4 backport now, but I will need to do the usual testing
before it is ready ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ibolton at gcc dot gnu dot org]

------- Comment #35 from ibolton at gcc dot gnu dot org  2010-09-07 09:27 -------
(In reply to comment #32)
> I don't know if there are plans for more releases in the 4.4 series, but can it
> be applied to the 4.4 branch too?
> 

The backport for 4.4 is ready.  I am just waiting for approval on the mailing
list, although it is probably "obvious".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[ibolton at gcc dot gnu dot org]

------- Comment #36 from ibolton at gcc dot gnu dot org  2010-09-09 15:37 -------
Fixed in 4.4, 4.5 and trunk.


-- 

ibolton at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328

[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328