Problem on i386 with -fpic -fomit-frame-pointer

Problem on i386 with -fpic -fomit-frame-pointer

[Bernd Schmidt]

With the reload patch I sent in on Monday, gcc miscompiled the file e_hypotl.c
from glibc-2.0.95. The problem appears to be in i386.md, in the mov[sdx]f
patterns. I believe the following change is incomplete:

Sun Jul 26 01:11:12 1998  H.J. Lu  (hjl@gnu.org)

        * i386.h (CONST_DOUBLE_OK_FOR_LETTER_P): Return 0 when eliminating
        the frame pointer and compiling PIC code and reload has not completed.

If using -fomit-frame-pointer together with -fPIC, this will not accept any
floating point constants, and reload will substitute memory references for
them.  However, the expander patterns have not been updated together with
this patch, they still assume that certain constants are valid.  The result
was that in the file that was miscompiled, a load instruction using the PIC
register was emitted, but during reload the variable
current_function_uses_pic_offset_table remains set to zero. This causes
incorrect register elimination offsets, which in turn causes some of the
generated store instructions to write data outside the stack frame and
clobber one of the callee-saved registers.

Bernd


	* i386.md (movsf, movdf, movxf): Accept no constants if -fPIC and
	-fomit-frame-pointer.

diff -u -r1.1.1.28 i386.md
--- i386.md	1998/08/05 12:00:31	1.1.1.28
+++ i386.md	1998/08/28 10:07:09
@@ -1230,14 +1230,15 @@
       operands[1] = force_reg (SFmode, operands[1]);
     }
 
-  /* If we are loading a floating point constant that isn't 0 or 1
-     into a register, indicate we need the pic register loaded.  This could
-     be optimized into stores of constants if the target eventually moves
-     to memory, but better safe than sorry.  */
+  /* If we are loading a floating point constant that isn't 0 or 1 into a
+     register, indicate we need the pic register loaded.  This could be
+     optimized into stores of constants if the target eventually moves to
+     memory, but better safe than sorry.  */
   else if ((reload_in_progress | reload_completed) == 0
       && GET_CODE (operands[0]) != MEM
       && GET_CODE (operands[1]) == CONST_DOUBLE
-      && !standard_80387_constant_p (operands[1]))
+      && ((flag_pic && flag_omit_frame_pointer)
+	  || ! standard_80387_constant_p (operands[1])))
     {
       rtx insn, note, fp_const;
 
@@ -1385,7 +1386,8 @@
   else if ((reload_in_progress | reload_completed) == 0
       && GET_CODE (operands[0]) != MEM
       && GET_CODE (operands[1]) == CONST_DOUBLE
-      && !standard_80387_constant_p (operands[1]))
+      && ((flag_pic && flag_omit_frame_pointer)
+	  || ! standard_80387_constant_p (operands[1])))
     {
       rtx insn, note, fp_const;
 
@@ -1527,14 +1529,15 @@
       operands[1] = force_reg (XFmode, operands[1]);
     }
 
-  /* If we are loading a floating point constant that isn't 0 or 1
-     into a register, indicate we need the pic register loaded.  This could
-     be optimized into stores of constants if the target eventually moves
-     to memory, but better safe than sorry.  */
+  /* If we are loading a floating point constant that isn't 0 or 1 into a
+     register, indicate we need the pic register loaded.  This could be
+     optimized into stores of constants if the target eventually moves to
+     memory, but better safe than sorry.  */
   else if ((reload_in_progress | reload_completed) == 0
       && GET_CODE (operands[0]) != MEM
       && GET_CODE (operands[1]) == CONST_DOUBLE
-      && !standard_80387_constant_p (operands[1]))
+      && ((flag_pic && flag_omit_frame_pointer)
+	  || ! standard_80387_constant_p (operands[1])))
     {
       rtx insn, note, fp_const;
 

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Jeffrey A Law]

  In message <Pine.GSO.4.02A.9808281343230.8679-100000@matlock.informatik.rwth-
aachen.de>you write:
  > With the reload patch I sent in on Monday, gcc miscompiled the file e_hypot
  > l.c
  > from glibc-2.0.95. The problem appears to be in i386.md, in the mov[sdx]f
  > patterns. I believe the following change is incomplete:
  > 
  > Sun Jul 26 01:11:12 1998  H.J. Lu  (hjl@gnu.org)
  > 
  >         * i386.h (CONST_DOUBLE_OK_FOR_LETTER_P): Return 0 when eliminating
  >         the frame pointer and compiling PIC code and reload has not complet
  > ed.
  > 
  > If using -fomit-frame-pointer together with -fPIC, this will not accept any
  > floating point constants, and reload will substitute memory references for
  > them.  However, the expander patterns have not been updated together with
  > this patch, they still assume that certain constants are valid.  The result
  > was that in the file that was miscompiled, a load instruction using the PIC
  > register was emitted, but during reload the variable
  > current_function_uses_pic_offset_table remains set to zero. This causes
  > incorrect register elimination offsets, which in turn causes some of the
  > generated store instructions to write data outside the stack frame and
  > clobber one of the callee-saved registers.
  > 
  > Bernd
  > 
  > 
  > 	* i386.md (movsf, movdf, movxf): Accept no constants if -fPIC and
  > 	-fomit-frame-pointer.
Did this problem get fixed?  I know rth did some work on the movsf, movdf and
movxf patterns for the x86, but I don't know if they were supposed to solve
this problem or not.

jeff

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Bernd Schmidt]

>   > With the reload patch I sent in on Monday, gcc miscompiled the file e_hypot
>   > l.c
>   > from glibc-2.0.95. The problem appears to be in i386.md, in the mov[sdx]f
>   > patterns. I believe the following change is incomplete:
>   > 
>   > Sun Jul 26 01:11:12 1998  H.J. Lu  (hjl@gnu.org)
>   > 
>   >         * i386.h (CONST_DOUBLE_OK_FOR_LETTER_P): Return 0 when eliminating
>   >         the frame pointer and compiling PIC code and reload has not complet
>   > ed.
>   > 
>   > If using -fomit-frame-pointer together with -fPIC, this will not accept any
>   > floating point constants, and reload will substitute memory references for
>   > them.  However, the expander patterns have not been updated together with
>   > this patch, they still assume that certain constants are valid.  The result
>   > was that in the file that was miscompiled, a load instruction using the PIC
>   > register was emitted, but during reload the variable
>   > current_function_uses_pic_offset_table remains set to zero. This causes
>   > incorrect register elimination offsets, which in turn causes some of the
>   > generated store instructions to write data outside the stack frame and
>   > clobber one of the callee-saved registers.
>   > 
>   > Bernd
>   > 
>   > 
>   > 	* i386.md (movsf, movdf, movxf): Accept no constants if -fPIC and
>   > 	-fomit-frame-pointer.
> Did this problem get fixed?  I know rth did some work on the movsf, movdf and
> movxf patterns for the x86, but I don't know if they were supposed to solve
> this problem or not.

I'm not entirely certain about what is going on.  We are definitely having
some weird problems still.  First of all, I'd like to see the original test
case that led to the Jul 26 change, if someone still has it.

These are the current definitions which are relevant to the issue.  HJ's
change modified CONST_DOUBLE_OK_FOR_LETTER_P, and was followed by
several changes by Richard Henderson and me in PREFERRED_RELOAD_CLASS.

============
/* Similar, but for floating constants, and defining letters G and H.
   Here VALUE is the CONST_DOUBLE rtx itself.  We allow constants even if
   TARGET_387 isn't set, because the stack register converter may need to
   load 0.0 into the function value register.

   We disallow these constants when -fomit-frame-pointer and compiling
   PIC code since reload might need to force the constant to memory.
   Forcing the constant to memory changes the elimination offsets after
   the point where they must stay constant.

   However, we must allow them after reload as completed as reg-stack.c
   will create insns which use these constants.  */

#define CONST_DOUBLE_OK_FOR_LETTER_P(VALUE, C)  \
  (((reload_completed || !flag_pic || !flag_omit_frame_pointer) && (C) == 'G') \
   ? standard_80387_constant_p (VALUE) : 0)

/* Given an rtx X being reloaded into a reg required to be
   in class CLASS, return the class of reg to actually use.
   In general this is just CLASS; but on some machines
   in some cases it is preferable to use a more restrictive class.
   On the 80386 series, we prevent floating constants from being
   reloaded into floating registers (since no move-insn can do that)
   and we ensure that QImodes aren't reloaded into the esi or edi reg.  */

/* Put float CONST_DOUBLE in the constant pool instead of fp regs.
   QImode must go into class Q_REGS.
   Narrow ALL_REGS to GENERAL_REGS.  This supports allowing movsf and
   movdf to do mem-to-mem moves through integer regs. */

#define PREFERRED_RELOAD_CLASS(X,CLASS)					\
  (GET_CODE (X) == CONST_DOUBLE && GET_MODE (X) != VOIDmode		\
   ? (standard_80387_constant_p (X)					\
      ? reg_class_subset_p (CLASS, FLOAT_REGS) ? CLASS : FLOAT_REGS	\
      : NO_REGS)							\
   : GET_MODE (X) == QImode && ! reg_class_subset_p (CLASS, Q_REGS) ? Q_REGS \
   : ((CLASS) == ALL_REGS						\
      && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) ? GENERAL_REGS	\
   : (CLASS))
============

We are currently having problems with the code in reload1.c that checks
reload insns which were emitted for asm statements for validity.  The
CONST_DOUBLE_OK_FOR_LETTER_P macro will reject standard 387 constants at
the time, because reload_completed is still zero, and we'll abort
occasionally for (perfectly valid) reload insns which load constant
values into a FLOAT_REG.  These didn't occur previously, presumably
because until recently, PREFERRED_RELOAD_CLASS returned VOIDmode for all
CONST_DOUBLES.
That we're now creating such insns might in fact be good news, because
that means we might be able to undo HJ's change: if reload no longer
needs to put standard 387 constants into the constant pool, the original
motivation for the change is probably gone.  But I'm not sure, since I
don't have the original test case.

Bernd

Re: Problem on i386 with -fpic -fomit-frame-pointer

[H.J. Lu]

> > Did this problem get fixed?  I know rth did some work on the movsf, movdf and
> > movxf patterns for the x86, but I don't know if they were supposed to solve
> > this problem or not.
> 
> I'm not entirely certain about what is going on.  We are definitely having
> some weird problems still.  First of all, I'd like to see the original test
> case that led to the Jul 26 change, if someone still has it.
> 

I am enclosing a mail archive with 3 message inside. You can find
more on that topic from the egcs mailing list archive. Just check
for topics with "-fpic -fomit-frame-pointer". The first one is from
June.


H.J.
----
begin 600 pic.gz
M'XL("&70'#8"`W!I8P#M._UWVL:R/T=_Q82X`1(D)/&-0VX(L1-Z<>QCDUO>
M:5HLI!52+22>)&+\FO[O=V;U@2#8."'MZ>FSCPW2[NSL?.W,[.[XV/=F8/WF
MP,7"A1_Q3U5`J;352KN&#ZU64[A83'YC>MB&<]:&K@O+9AU$<V[KH+D&/GDS
M.Q1-7YLQ<>[9;LA\F"RFPM!KPTQS39\9KP+1L'UV%;HLE`Q6@I.H77KG.4X0
M,MM]=15(`7,DS=&U$+\-)KS!AS9152*2B#*B9D6;*#=D&0IG;X9%H:>WX3?/
M<E^9S`XM2?=F)7"TZU?ZS=1=!-$[F^J!B(0%F5:A[XKG;.[<B$3M"Z72D%N2
MBO-(%:75:%2E9KU9JZFO`BU<^*YD)>1*R,A+,$ETN9@72'G)@1;&DBP!4BQ'
M%,LPGPDC\42S'>:WX6AP`C]_8GY@>P@I5>%LH-;@[.V9^HMPTC\Y$O\3];5!
MD62AYZ%<W5`<WLQ1*"%;AN6YH]GN(>B6Y@<L['RX$+L7O7Y_!>IK;F`R7SQR
M=<^PW6D;&A,[3/L'S)V&5ANIE%7@/\)%B'P&J.A307@)\!*BSWX(@>5=!W#C
M+4#S&806`\]U;O"#P;7E`4-&(/1M%,/L!LD+0ET+&+3%H@3OF,\B/';`1Z+<
MYPX+60HG"7RFH:6Y:`;P^L,PUA9R+E4T&H=ZF]Z4(/2\=@3<)SO#\<B7@QU3
M71=5J2DI!'SZ[QCH``9OQN<?WH_/NL-WG3*.=H(RZK[LV),R#:%ON]:LXX.[
M6)8C#-.9=L6@U\L.F&OZE39E^*('$5AY8KN$@^:Y'Z!X`>*IB@O&]42VU-D\
M1/4&N$;0GG3]J]!L6W/B:25>EILS@,Z6\Z^:PN-41:0%T?``1#1O0W_^'-&8
MG@\FQ!"'8*`%Z&@&N?.%ZW)+.S!SA_AQ"!])]6";\#,<_`L>=T"&7P[)#-QH
MR#$M!^,03)O0N&0I*1)"CN^J*BGUAEJBA5!5&U72K;"F<&X=9!P2#'U\L.P@
MX1E-=&4<DB"\'OY4`IL;],(Q8,)PYB6:+?)")H=S*!+TP=(^,9C[WMP+L%.%
MP',6D3#1YPD!KA\:H<&5LS"F:,D>&':@31RV73<DK[-^#^<7WDD_2H(HBC%]
M^"0\L5T=\3#(\48K)PCCL>VB33)`H2P(+79`(7X>CY?%PR]`A$T0X7<!P&=3
M.R`2THY/FK-`%SP>(SP*W`T/D0`3E/@3L$<+9@3H.5J(VAF/!?(.A9SI&([*
M'CUZ]`38KTOH@/IK80G/P/&F:H$5BQ_=CV&.PT+.G"V<1S_\$(0%I4@#,G!K
M8$&8@JVU^RZZK)#/A=^W3[/4K75\BTEV6E2#?L=H=3E3^!S(R9>@11!!R<"W
M(=<)<U"(95@LX?N"OR>B+!*,S)N61=31$X9LF%RF?`@\[Y`5']XIY4#7'';+
ME"O\*0D;%."L7.T4L))IB1`G8-GV94K<'U\:6X"VO</8-D'0V!+[N<7D=C"-
M<7,7RURD^_*F>\$NWC9!]N4-\=W"VUZLA0SC*"9)\$)WM""`X\%I=_@R#J_+
M%]%KY!5T]%SA1L]32%T$1SY'NGTH\$XH\&%+R6>:`P5<"B582O9,F]++879R
M/7)-NNZ3Y1VGV622`\F@5-LUM5UK_1VR22TL$4FK;#*A[4_*)AM2K55M522U
M*E?4JM12*[(B?VLZ*4?I9)U(EIM_TW2RV:HVMZ:3^'OJPHF'^;Q2(X885P'J
MH])&-2C5$AG.*V>!QBIY_A2N?0]U)B19Z#N[E$U**:VDV*_Q-!)XODEA5KNO
M24D1GB1/0%0S.Z`E0@D)3&YVH,`\50ML=-7.382(39808-I@4,I!>6X08H9%
M>#W4BV\;F/),;K(L/,+H-\?E]0,+YL5LQP"-U5_C]M'<0\@?<(YLZWR!B8PW
M8S#5_`GF<CR+F2PE^`GMUL/.B`64RC8.2G%BER;G*?,F>D,I.Q'/FN+\"%-R
MSM05)EO();J>$*X]_PI-(DVA"*#54%14-,F/'M5:A,K2HEU`@)0D:L!?2HM*
MM,'PT9]HY*<(!R9&\6:!YXQ(F+/*DF*58>28/N8YX7?8I]R^11$P:0.>O<%@
M`04R55SW9*A%@2=QCWGZ'%C"$Y0+T4ZV&5C,<9`6W;(QH2Q@1FDL],B\WK[_
M@-V:CWFE$T!54HL2#44BER&E(BG#0>09>%8;8RIQ2Z,\%C-/;@''_<%1"5WY
M#(T-T1"C-S@"=3)AN"PB65PF-.:!!SQMXA$NGHV'Z`K@,K`XICR2@EA.-(,$
MR->I*-?%V)DK@&Z26'A!4O!TIKDOB?8+U)[.@)RS'GJ8B%^CKB_+%M)71L@R
MN4O:7Y31*"4EGN-H:?-=7,SJM8WR>N9ZX3/*S6GE7/MVB!X&%B[V(SY1SY-L
M@SG3;1,U&:'A(B=QHN[<$%U9T,96ASLEF'G(1_3CHMEAA\A_XJ^-QUT_.!Q_
M&@W<;OG7HB_2+XKJBA$'4:>*DLIT)EL\ZL.54,_V)7NS"&FK^D4?&I1`VA[W
MCR\ZN8/?\>N/G)!Y:>>$*0O)B8]1])WC+BKPC>!XE$9F6TS;#\+Q7$,?@$.5
MG$#N$OO):QS0#EDP/('OU;A'S1UDL.8PVX_0P-.G4;]HP@'VE&,HW.EQ`6-W
M8:U=%).P]+)LL$]E=X$:5E\^58HX@$R/C\.8`Y>WC"/@2PZUHJU"%.$2XLTI
M%H"L)`@=;S9M(?Y8(5C)YP[>N$%M,L8;17'NHQ<5:3+1\$C#E)7<R6-&)9<[
M,5U&)/,]<:3LQ`ARP@XN/G^^4X-"3!#MOSOT(<19YO!H-'QS>M+MOW_3/^]D
M<!,P[B_\<!UD;4@G]67;H)/IUDA:J1KS8^0U]!:Z!:(VPT52P=]:J]6"@P,I
M:M^0;"J$QZ2MS("L#N.QAXD.B,8Q;^KPSX3S3'L[)A6_#O@)1?ZG[OG[_ONW
M;4"O!'3FY/GDKT)[AL\8J@()`+.@`".\S^V/>C'LY5,4.71'(68*U$%N_^,E
MGRM?HE,##$>311@=05#G,<6X#RA(.[19($E2+J$(1>3/-KA-6$0G@0*979$-
MC@-+EAL5-64[9F0)8A[R.N;TG$34[]7*6><36<3`)C^8H?C"![`OP$G+&(`4
M(NL)=+(_J3=<;^ZD.D,>\@E,/M58[B#CHG)T6"3J6WFX^'?_[`Q5DD62+_`)
M-0>I-6Z(MB`,BIM<\>%Q@"49K"$@6RP28W3FDP_*OX[*Y3R\>`'YBW?=\_'1
MZ7$>$Y@UPH5>K\-/S%Y'88X2(7ZZ1G&6LB$>[X0GV\`F"]LQ5H`3S;@%D/+2
M+4B/1KVCLV'_]/U%9^/$3^@=#[IOJ7GK.6$KS@L/"BL41<"@:/C:CJ&5NX8^
M2<<B-5\Q,Q\\>#/HO\:QR2'C2#@[/T5D_!#PXKQWT3DH\)9V!\-E,8V;W8N3
M;%=03++:D8`KK@UQ5U$8/4I/+9.VK2>7T=%E='8Y>I2<7=[O\!+G#&8T)U&%
M4PH1+>V4VM&C@T*O5Z1#7'S@XBK"P0N$C,Y:VVFND(&D4^-UB:4CVH`3KF`]
M.'B5S([?D4PY'0XF:6T.>'Y2I/7W3`KP3]>E9_2%GXE0\!77/*6,FH1["!Q,
MWI'&\G"5+NV#`FDE%C>Z9^Y$^8ADM="R6WE6[MCENBHKU9J"^]CU=02X\\0T
M#0&JU6S7Y\^KQ1OY7LP*S?S:PHU<53X*[P68&;5@@7Y2Q-Q[SF,%?(:IS^:X
MIG&3U$X`/OZ<A^)F6.'1GD+]"DTV#4DPB9\@3^XB2MYQQZ.NXSI<1?T$CTZ>
M)!'-UFF!(G?,:\)>FUA]4T/I,'2_":>R9M3DEEJMZ_K$,-2:TJ@KDX92K[;J
M5:W!5%CEHQEEQ*XP#G>ZMW##3NYRT!MW!X,.X'=O^#]G1_C4??^V`]<ZISDC
MZ<OH%(O[:I[^LO]%G[U"EHNT!=MXP)@YM5W-@<#^/](9CB]1,%KX/AVF1ZU9
M9(]S40*T);K$2^2NX!*#[!5;4AS?&%HRX^\963)4KRX%7M@>Y@A,FTG6RRU7
M!2,!G2NF\AX_@XO.]$:XFFC[CQ.D1WCTDBM!+FJ,C_+HA;F&<TA#XG/`U:D?
M"ICV^T5X3HW)D+B1#@&CN?E542&9%S>]!5622U#A0"N\G$1^5JA%1XAWN@FE
MKJBR2FXB*Y1U+Y'VW.HD5BKX)_J(F+OM+D)O*;HLM^1)LS*I-K6JT:H9<FVB
M5?3:1)5U!=)(L[^'2,2<=1!\"[S#0608V/0/./R;_4-RI'>'?XA!]O(/*8YO
M]`^9\??T#QFJMWJ"[W1K./J&:\/1U@N0T==<'([N>7,XNNWJ<'3?N\/1YN7A
MZ.MN#T=?>WTXVN_^</3E!>+=\HZO$$???H<XRGCNC>NHT5]QC3BZXZYM!^]T
MDSBZSU7B_AQ^^V6BO`>'_#YQ=(\+Q:]F\/M<*8Z^ZYWBCC1!;F*4:Z[[QO4T
M(>VY-4U8>>)_8IH0<[<]36@JQJ2NJ:8Z472%M1BKR+5FA;44M=%L5.O*JGAH
M_S0A$7,V38B.PW?D"1D.-O,$&K]?HF#MS!.L_=,$:[\LP?K:),&*<P33-9@)
MX][1Z&S\3GB"+^2;DO=1[(K2]MAYI0W):QR&OO`/X^,!^H/H.78%N/[GZ,QL
MO1UM0W@C>B2$!!]#/^X,^+--S^BO<`T6?'0%]@P*=A%^AS^X]^/@\38D<C6_
M)T[%9X<9H&1;L@%DSP[7,-$$Z&,.M[,0,YJZLXBOV'M%&&*R,42C9P[C0]OQ
M&`J1)R0/MC?J-=^Y-@!EA)D%CR4A"HM>>.@,(\^YIH$7431Y>8LFXE@3ZR)^
MNUL;R9`=^DAP[=!(BNU6G6P-.W!GV$$D-W-&QKXA!="S77SP4\#(DD:]7?&E
M55W%%^NV\&+MBB[6/SFX6+?$EKIIULQ6C>E*U625JEDQ)I5JO6(T*ZV*4:]#
M<L'YG4*+M7Y"17>I]PDLUM;SJ5;UWF&%7\JLKET$?B\B9XJAAIBX\Y*C.BA*
MN])JRY6-8J@N.G7?]A;!/0I7,K6JLE0IHU)Y==1ZQ1(4?L1W^(E9#BO&U4]#
MVL`A#:OJIX28S>JG^U0W(0)<'U6Y6I.E;K<KUZJMVJO?KAUM(AT?]8?OI-[I
M25+4M*(EK6:B>A^J9I+;-;FMUD#[6U8S-1J5;=5,5(LD#*VT!&DOY7F\8BE3
M3\0K,FYX!0M=.9)#PRT`^<QKU"XP#=V3AR"^Q(F@.F7LG$4%,[B"[!E:,@8G
MW%Y@4$",4<&)SQQ/,R3H9RDH"1OP]I=#D!*T>".J&6DU6A)TH^H4N@(5KNDZ
MA"IN4D11Y0IQ#@GGZ4Z'<Z#%M5%):TF@\8;GYD.X<KUK\H]G_5Y4#&)X*-"X
MEH6/3FNK)/C@FIX?+FA2%%LLR5(T_\+5Z3*,I(,[\@77%"YW5`XSA+A:`-T,
M!@DX4.HE*L)*6^>+P(K+K9(F$@I(`[4BT$=[!9H69B4MFF$@RO';P>GK[F!\
M>GQ\<30<#[NO!T?CYS]+(@W_I<1'"*\7X::^B/^`],X9UB9TH?*7T]4/4>PL
M2/6!LN&&86GN-+JI3J2*MA"53&'(6SAA::4=JJ6:L8"2U<6<:NHQH#)7=[R`
M,[:JOJ)K.3M$6^XC,U0Z9[M7&#E!!6V.TZ"ULX#NH4U[R;'C*FH+@B+!&VXP
MM,YNL[:X[AZ2)>;Y@BI!C[-QBY6$WE\N[NVVB/Z6#)]7-F;_92'Z?P7B#)U'
MB3L;6LE+6C0F0Q^"OH`[!O[?-)G_./C_4:,6Q5C<5#[4J$&CTKJK1JWVU35J
M#X5H#X5H#X5H#X5H]R]$4Q2Y57LH1/N[%*(]U*'MJD-[J#O;L^[LSZTVNV^9
MF5)7%*7Y4&:V5YF9V=2::LTT#59KL(E9DYELF,PT=$W&%DRC__PR,\I@]RDS
MJ[0>RLSN*C,KEV&?2C,<_D\H-5/4^D.IV3>7FE6,B=%H-IC:4JN:;$R8K$X:
M6F6BU.JRHM3-/[_4K+9?J5GMH=3LH=3LH=3LH=3LH=3LH=3LH=3LH=1L_U*S
254T`/P%+:P+^"WNSU1MO3P``
`
end

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Jeffrey A Law]

  In message < 19981008213426.B13335@dot.cygnus.com >you write:
  > I think CONST_DOUBLE_OK_FOR_LETTER_P is probably wrong.  One of the
  > problems I'd fixed during the mov*f changes was to correct the fact
  > that PREFERRED_RELOAD_CLASS for those special constants was NO_REGS,
  > which was what was causing reload to drop things to memory in the
  > first place.  
  > 
  > Which was the offending file?  e_hypot.c?
e_hypotl.c according to Bernd's message.

jeff

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Richard Henderson]

On Thu, Oct 08, 1998 at 06:14:19AM -0600, Jeffrey A Law wrote:
>   >  * i386.h (CONST_DOUBLE_OK_FOR_LETTER_P): Return 0 when eliminating
>   >  the frame pointer and compiling PIC code and reload has not completed.
> Did this problem get fixed?  I know rth did some work on the movsf, movdf and
> movxf patterns for the x86, but I don't know if they were supposed to solve
> this problem or not.

I think CONST_DOUBLE_OK_FOR_LETTER_P is probably wrong.  One of the
problems I'd fixed during the mov*f changes was to correct the fact
that PREFERRED_RELOAD_CLASS for those special constants was NO_REGS,
which was what was causing reload to drop things to memory in the
first place.  

Which was the offending file?  e_hypot.c?


r~

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Jeffrey A Law]

  In message <Pine.SOL.3.90.981008144357.2965E-100000@matula.informatik.rwth-aa
chen.de>you write:
  > I'm not entirely certain about what is going on.  We are definitely having
  > some weird problems still.  First of all, I'd like to see the original test
  > case that led to the Jul 26 change, if someone still has it.
http://www.cygnus.com/ml/egcs-bugs/1998-Jun/0345.html

There are random messages about this bug in egcs, egcs-bugs and egcs-patches
in June and July.

  > That we're now creating such insns might in fact be good news, because
  > that means we might be able to undo HJ's change: if reload no longer
  > needs to put standard 387 constants into the constant pool, the original
  > motivation for the change is probably gone.  But I'm not sure, since I
  > don't have the original test case.
I suspect there probably are still cases where reload is going to try to put
those constants in the constant pool.

That's generally what reload does with a constant when it gets confused.  It
just drops it into memory and loads it into an appropriate register.

jeff

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Richard Henderson]

On Sun, Oct 11, 1998 at 01:24:50AM -0600, Jeffrey A Law wrote:
> I suspect there probably are still cases where reload is going to try to put
> those constants in the constant pool.
> 
> That's generally what reload does with a constant when it gets confused.  It
> just drops it into memory and loads it into an appropriate register.

It shouldn't.  One of the changes Bernd and I iterated on a bit ago
was to get reload to actually emit the instructions that generate
these constants.  And aside from 0.0 and 1.0, everything else should
have been dropped to memory during rtl generation.

A question might be -- if something somewhere is still wrong, or
breaks in the future, how to be sure that reload will abort rather
than silently generate bad code in this instance.


r~

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Bill Currie]

Richard Henderson wrote:
> It shouldn't.  One of the changes Bernd and I iterated on a bit ago
> was to get reload to actually emit the instructions that generate
> these constants.  And aside from 0.0 and 1.0, everything else should
> have been dropped to memory during rtl generation.

What about PI and e (log2(e)?) and any other constants that are
available in hardware?  Yes, I know there's the problem of recognising
them (ie they have to be specified `exactly' (for the representation)). 
I can't remember them all, but I know the Intel FPU has a few other
usefull constants.

Bill
-- 
Leave others their otherness

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Richard Henderson]

On Thu, Oct 15, 1998 at 09:54:29AM +1300, Bill Currie wrote:
> What about PI and e (log2(e)?) and any other constants that are
> available in hardware?

We do not attempt to recognize them, primarily because the
actual fpu constants are long double constants, and would
not be appropriate for substitution for the other precisions.


r~

Re: Problem on i386 with -fpic -fomit-frame-pointer

[Bill Currie]

Richard Henderson wrote:
> We do not attempt to recognize them, primarily because the
> actual fpu constants are long double constants, and would
> not be appropriate for substitution for the other precisions.

Fair enough, but isn't M_PI specified as a long double in math.h
(3.14159265358979323846 for Sun).  Wouldn't this cause problems for
either float or double (or long double if I got the size/type of M_PI
wrong)?  If not, where's the error in my thinking?  Or is it a `don't do
that [unless you know what you're doing]' issue (like trying to compare
x==0.1)?

Bill
-- 
Leave others their otherness

Re: Problem on i386 with -fpic -fomit-frame-pointer

[N8TM]

In a message dated 10/15/98 2:43:58 AM Pacific Daylight Time,
bcurrie@tssc.co.nz writes:

> What about PI and e (log2(e)?) and any other constants that are
>  available in hardware?  Yes, I know there's the problem of recognising
>  them (ie they have to be specified `exactly' (for the representation)). 
>  I can't remember them all, but I know the Intel FPU has a few other
>  usefull constants.
When I first used gcc, on a Sun 3/60, I modified the constant recognition
function so that it used the internal constant if it was within 1 +-
DBL_EPSILON or FLT_EPSILON, as the case might be, of matching.  Pedantically
speaking, this isn't correct, but I found the results quite satisfactory, as
it was really better to have the occasional boost in precision.