This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Bug in jump.c (jump_optimize)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]