public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Problem on i386 with -fpic -fomit-frame-pointer
@ 1998-08-28  5:22 Bernd Schmidt
  1998-10-08 11:45 ` Jeffrey A Law
  0 siblings, 1 reply; 12+ messages in thread
From: Bernd Schmidt @ 1998-08-28  5:22 UTC (permalink / raw)
  To: egcs; +Cc: hjl

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;
 


^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: Problem on i386 with -fpic -fomit-frame-pointer
@ 1998-10-15  6:29 N8TM
  0 siblings, 0 replies; 12+ messages in thread
From: N8TM @ 1998-10-15  6:29 UTC (permalink / raw)
  To: bcurrie, rth; +Cc: law, crux, egcs, hjl

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.

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-10-15  6:29 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-28  5:22 Problem on i386 with -fpic -fomit-frame-pointer Bernd Schmidt
1998-10-08 11:45 ` Jeffrey A Law
1998-10-08 12:10   ` Bernd Schmidt
1998-10-08 13:13     ` H.J. Lu
1998-10-11  0:26     ` Jeffrey A Law
1998-10-13 19:22       ` Richard Henderson
1998-10-14 18:58         ` Bill Currie
1998-10-14 18:58           ` Richard Henderson
1998-10-14 21:17             ` Bill Currie
1998-10-08 21:41   ` Richard Henderson
1998-10-08 21:41     ` Jeffrey A Law
1998-10-15  6:29 N8TM

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).