This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Bug in jump.c (jump_optimize)
- To: bregor at anusf dot anu dot edu dot au (Roger W. Brown)
- Subject: Bug in jump.c (jump_optimize)
- From: hjl at lucon dot org (H.J. Lu)
- Date: Thu, 12 Mar 1998 15:24:55 -0800 (PST)
- Cc: michaelh at ongaonga dot chch dot cri dot nz, egcs at cygnus dot com
>
>
>
> Dear HJ,
>
> If you can spare the time, I'd be grateful if you
> would perform a quick test of egcs gcc.
>
> I'd would like to know if you can compile r_tanh.c,
> with any recent egcs-gcc, built with either glibc-2.0.6
> or glibc-2.1 I find that:
>
> gcc -c -I./ -O2 -march=pentiumpro r_tanh.c
>
> fails with: Internal compiler error: program cc1 got fatal signal 6
>
> ( the -I path must lead to f2c.h, r_tanh.c is in the egcs source tree )
>
> I'm concerned that others don't seem to be able to reproduce the
> bug; while I see it, both on my "hand maintained" PPro system and
> on a "squeaky clean" RedHat (glibc-2.0.?) Pentium installation.
>
> The problem has been in all egcs branches for sometime. I traced
> the change to the egcs-980129 ->> egcs-980205 transition, and it
> has been bad ever since. The symptoms are removed (I didn't say
> "problem fixed" !) by reversing the patch below. I could write
> more about the illegal-instruction encountered etc - and will,
> should you like to hear about it.
>
> Regards,
>
> Roger Brown
>
>
> P.S. I see the problem under all manner of egcs builds, including
> the very plain sequence:
>
> untar a fresh source snapshot
> ./configure
> make bootstrap
>
>
> ======================================================================
> diff -Nrc3p egcs-980129/gcc/jump.c egcs-980205/gcc/jump.c
> *** egcs-980129/gcc/jump.c Sat Jan 17 12:20:09 1998
> --- egcs-980205/gcc/jump.c Tue Feb 3 13:19:59 1998
> *************** jump_optimize (f, cross_jump, noop_moves
> *** 771,776 ****
> --- 771,778 ----
> && rtx_equal_p (SET_DEST (temp4), temp1)
> && (GET_CODE (SET_SRC (temp4)) == REG
> || GET_CODE (SET_SRC (temp4)) == SUBREG
> + || (GET_CODE (SET_SRC (temp4)) == MEM
> + && RTX_UNCHANGING_P (SET_SRC (temp4)))
> || CONSTANT_P (SET_SRC (temp4)))
> && (REG_NOTES (temp2) == 0
> || ((REG_NOTE_KIND (REG_NOTES (temp2)) == REG_EQUAL
> *************** jump_optimize (f, cross_jump, noop_moves
> *** 907,912 ****
> --- 909,916 ----
> && rtx_equal_p (SET_DEST (temp4), temp1)
> && (GET_CODE (SET_SRC (temp4)) == REG
> || GET_CODE (SET_SRC (temp4)) == SUBREG
> + || (GET_CODE (SET_SRC (temp4)) == MEM
> + && RTX_UNCHANGING_P (SET_SRC (temp4)))
> || CONSTANT_P (SET_SRC (temp4)))
> && (REG_NOTES (temp3) == 0
> || ((REG_NOTE_KIND (REG_NOTES (temp3)) == REG_EQUAL
> *************** jump_optimize (f, cross_jump, noop_moves
> *** 1153,1161 ****
> && (! SMALL_REGISTER_CLASSES
> || REGNO (temp1) >= FIRST_PSEUDO_REGISTER)
> && (GET_CODE (temp2 = SET_SRC (PATTERN (temp))) == REG
> || GET_CODE (temp2) == SUBREG
> /* ??? How about floating point constants? */
> ! || GET_CODE (temp2) == CONST_INT)
> /* Allow either form, but prefer the former if both apply.
> There is no point in using the old value of TEMP1 if
> it is a register, since cse will alias them. It can
> --- 1157,1166 ----
> && (! SMALL_REGISTER_CLASSES
> || REGNO (temp1) >= FIRST_PSEUDO_REGISTER)
> && (GET_CODE (temp2 = SET_SRC (PATTERN (temp))) == REG
> + || (GET_CODE (temp2) == MEM && RTX_UNCHANGING_P (temp2))
> || GET_CODE (temp2) == SUBREG
> /* ??? How about floating point constants? */
> ! || CONSTANT_P (temp2))
> /* Allow either form, but prefer the former if both apply.
> There is no point in using the old value of TEMP1 if
> it is a register, since cse will alias them. It can
>
>
I believe the bug is introduced by this patch:
Mon Feb 2 02:08:04 1998 Michael P. Hayes <michaelh@ongaonga.chch.cri.nz>
* jump.c (jump_optimize): Allow conditional loading of floating point
constants and constants from memory. Reinstalled modified_in_p tests.
On x86, 0.0 and 1.0 are 2 special floating point constansts among
others. They can be pushed onto the floating point resgister stack.
They are not in memory nor in resgister. When the floating point
constants are enabled for conditional move, gcc will try to
load (cc0) onto the floating point resgister stack. It certainly
won't work. We need to fix i386.md to handle those special
floating point constansts.
Thanks.
H.J.
--
H.J. Lu (hjl@gnu.org)