gcc 2.95.3 and pre-2.95.4 bug: ICE on good code with -march=i686 -mno-ieee-fp

[Jakub Bogusz <qboosh at pld dot org dot pl>]

Summary: bug in gcc 2.95.3 and pre-2.95.4 (I tried CVS snapshot from
gcc-2_95-branch taken on 20010823)
(gcc 3.0.1 doesn't have this bug)

Float comparison with 0 causes SIG11 and ICE when compiling with
-march=i686 -mno-ieee-fp.


Details:

Test case is very simple (no headers, no defines - so no need to use
preprocessor):

int main()
{ float A=0;
  int b;
  b=(A==0);
}

second variant:

int main()
{ float A=0;
  A=(A==0);
}

ICE occurs only when both -march=i686 -mno-ieee-fp are used (internally:
TARGET_CMOVE must be true, TARGET_IEEE_FP must be false).


After loading core to gdb (variables printed after looking into
notice_update_cc() source code):

Core was generated by `/usr/lib/gcc-lib/i686-pld-linux/2.95.4/cc1 /tmp/ccjVHfm0.i -quiet -dumpbase c.c'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x081b54ac in stack_regs_mentioned_p (pat=0x0) at ../../gcc/reg-stack.c:416
416       if (STACK_REG_P (pat))

(gdb) bt
#0  0x081b54ac in stack_regs_mentioned_p (pat=0x0) at ../../gcc/reg-stack.c:416
#1  0x081f2efe in notice_update_cc (exp=0x828d1b0) at ../../gcc/config/i386/i386.c:3764
#2  0x081af059 in final_scan_insn (insn=0x828d1b8, file=0x829cfd8, optimize=0, prescan=0,
    nopeepholes=0) at ../../gcc/final.c:2879
#3  0x081addfd in final (first=0x828ccf8, file=0x829cfd8, optimize=0, prescan=0)
    at ../../gcc/final.c:2020
#4  0x0804dbcc in rest_of_compilation (decl=0x82957a0) at ../../gcc/toplev.c:4393
#5  0x08210290 in finish_function (nested=0) at ../../gcc/c-decl.c:7270
#6  0x081fc2aa in yyparse () at c-parse.y:324
#7  0x0804b9a4 in compile_file (name=0xbffffce7 "/tmp/ccjVHfm0.i") at ../../gcc/toplev.c:3264
#8  0x0804f74b in main (argc=9, argv=0xbffffb84) at ../../gcc/toplev.c:5448
#9  0x40040871 in __libc_start_main () from /lib/libc.so.6

(gdb) f 1
#1  0x081f2efe in notice_update_cc (exp=0x828d1b0) at ../../gcc/config/i386/i386.c:3764
3764                  if (TARGET_CMOVE && stack_regs_mentioned_p

(gdb) p *exp
$1 = {code = PARALLEL, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil = 0,
  in_struct = 0, used = 1, integrated = 0, frame_related = 0, fld = {{rtwint = 136892836,
      rtint = 136892836, rtstr = 0x828d1a4 "\002", rtx = 0x828d1a4, rtvec = 0x828d1a4,
      rttype = 136892836, rt_addr_diff_vec_flags = {min_align = 164, base_after_vec = 1,
        min_after_vec = 0, max_after_vec = 0, min_after_base = 0, max_after_base = 1,
        offset_unsigned = 0, 3, scale = 40}, rtbit = 0x828d1a4, rttree = 0x828d1a4,
      bb = 0x828d1a4}}}

(gdb) p exp->fld[0].rtvec->elem[0].rtx
$2 = (struct rtx_def *) 0x828d198

(gdb) p exp->fld[0].rtvec->elem[0].rtx[0]
$3 = {code = SET, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil = 0, in_struct = 0,
  used = 1, integrated = 0, frame_related = 0, fld = {{rtwint = 136778664, rtint = 136778664,
      rtstr = 0x82713a8 ">", rtx = 0x82713a8, rtvec = 0x82713a8, rttype = 136778664,
      rt_addr_diff_vec_flags = {min_align = 168, base_after_vec = 1, min_after_vec = 1,
        max_after_vec = 0, min_after_base = 0, max_after_base = 1, offset_unsigned = 0, 0,
        scale = 39}, rtbit = 0x82713a8, rttree = 0x82713a8, bb = 0x82713a8}}}

(gdb) p exp->fld[0].rtvec->elem[0].rtx[0].fld[1].rtx
$4 = (struct rtx_def *) 0x828b08c

(gdb) p exp->fld[0].rtvec->elem[0].rtx[0].fld[1].rtx[0]
$5 = {code = REG, mode = SFmode, jump = 0, call = 0, unchanging = 0, volatil = 0, in_struct = 0,
  used = 0, integrated = 0, frame_related = 0, fld = {{rtwint = 8, rtint = 8,
      rtstr = 0x8 <Address 0x8 out of bounds>, rtx = 0x8, rtvec = 0x8, rttype = DImode,
      rt_addr_diff_vec_flags = {min_align = 8, base_after_vec = 0, min_after_vec = 0,
        max_after_vec = 0, min_after_base = 0, max_after_base = 0, offset_unsigned = 0, 0,
        scale = 0}, rtbit = 0x8, rttree = 0x8, bb = 0x8}}}

(gdb) p exp->fld[0].rtvec->elem[0].rtx[0].fld[1].rtx[0].fld[1].rtx
$6 = (struct rtx_def *) 0x0


I tested that the only function using TARGET_IEEE_FP, called on
test case is gen_seq (or gen_beq in second variant).
In both variants i386_compare_gen points to gen_tstsf_cc function.
(all functions are in insn-emit.c, generated from i386.md)

I am not familiar with gcc internals and don't know the language i386.md
is written in - so this is all I could check for now.



Other information as specified in bug reporting instructions:

GCC version:
gcc version 2.95.3 20010315 (release)
or
gcc version 2.95.4 20010319 (prerelease)   (in fact it was taken from
                                            gcc-2_95-branch on 20010823)

System type:
i686-pld-linux

Command line:
gcc test.c -march=i686 -mno-ieee-fp
or (since preprocessor is not needed):
/usr/lib/gcc-lib/i686-pld-linux/2.95.4/cc1 test.c -march=i686 -mno-ieee-fp

ICE/SEGV doesn't occur with -march=i[345]86 or -mieee-fp.


Compiler output:
gcc: Internal compiler error: program cc1 got fatal signal 11

cc1 output:
 mainSegmentation fault (core dumped)


gcc was configured with:

CFLAGS="-O2 -march=i686" \
CXXFLAGS="-O2 -march=i686" \
TEXCONFIG=false ../configure \
        --prefix=/usr \
        --infodir=/usr/share/info \
        --enable-shared \
        --enable-threads=posix \
        --enable-haifa \
        --with-gnu-as \
        --with-gnu-ld \
        --with-gxx-include-dir="\$\{prefix\}/include/g++" \
        --disable-nls \
	i686-pld-linux


-- 
Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/
PLD Team        http://www.pld.org.pl/
int main()
{ float A=0;
  int b;
  b=(A==0);
}