Re: An important patch for egcs 1.0.1

Re: An important patch for egcs 1.0.1

[Daniel Egger]

On Thu, 12 Feb 1998, you wrote:

>> Below I have a program that dies under egcs1.0.1+glibc.  There may be =
a=0D
>=09=09=09=09^^^^^^^^^^^^^^^^=0D
=0D
>That is a bad combination.=0D

 I wonder why...

--

Servus,
       Daniel

Re: An important patch for egcs 1.0.1

[H.J. Lu]

> 
> On Thu, 12 Feb 1998, you wrote:
> 
> >> Below I have a program that dies under egcs1.0.1+glibc.  There may be =
> =3D
> a=3D0D
> >=3D09=3D09=3D09=3D09^^^^^^^^^^^^^^^^=3D0D
> =3D0D
> >That is a bad combination.=3D0D
> 
>  I wonder why...
> 

egcs 1.0.1 miscompiles glibc, especially long double.

-- 
H.J. Lu (hjl@gnu.org)

Re: An important patch for egcs 1.0.1

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> egcs 1.0.1 miscompiles glibc, especially long double.

It's not obvious to me that just because 1.0.1 miscompiles glibc 2.x
the long double fix can't wait for 1.1.  If programs that use glibc
are miscompiled, that's much worse (although even then, if only
programs that use long double are affected, I'm not sure).  However,
most users do not compile glibc themselves; on the systems you
mentioned earlier (RedHat 5.0, Debian, SUSE) glibc comes as a
precompiled package.  I myself use RH5.0 and have never built glibc.

I think that one of the strengths of egcs has been and will continue
to be frequent releases, including *major* releases.  So, I'm eager to
see 1.1, with its many improvements; time we spend on 1.0.2 will (to
some extent) delay 1.1.  However, if the fixes are simple, my points
may be moot, and I don't pretend to pass judgement on the fixes
themselves.  So, this is not an argument not to put the fixes in; only
one about how we should determine what fixes are to go in.

    H> -- H.J. Lu (hjl@gnu.org)

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: An important patch for egcs 1.0.1

[Michael Neuffer]

On Sun, 15 Feb 1998, Mark Mitchell wrote:
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
>     H> egcs 1.0.1 miscompiles glibc, especially long double.
> 
> It's not obvious to me that just because 1.0.1 miscompiles glibc 2.x
> the long double fix can't wait for 1.1.  If programs that use glibc
> are miscompiled, that's much worse (although even then, if only
> programs that use long double are affected, I'm not sure).  However,
> most users do not compile glibc themselves; on the systems you
> mentioned earlier (RedHat 5.0, Debian, SUSE) glibc comes as a
> precompiled package.  I myself use RH5.0 and have never built glibc.

I'd consider it a major problem if I could not compile glibc anymore.

It is almost as bad as not beeing able to compile the Linux kernel and
would prompt me to switch back to gcc 2.8 as fast as I can download and
compile it on my different machines.

Mike

Re: An important patch for egcs 1.0.1

[H.J. Lu]

> 
> 
> > It's not obvious to me that just because 1.0.1 miscompiles glibc 2.x
> > the long double fix can't wait for 1.1.
> 
> HJ just sent the patch, and it seems short, and furthermore, he says
> it's been in the snapshots since before egcs-1.0.1.  So why the
> resistance?
> 

It is in now. The patch was actually installed when merging with
gcc 2.8. The ChangeLog entry in my patch was wrong. It should be

Mon Sep 29 08:21:35 1997  Bruno Haible <bruno@linuix.mathematik.uni-karlsruhe.de>
   
	* i386.c (notice_update_cc): Use reg_overlap_mentioned_p.



-- 
H.J. Lu (hjl@gnu.org)

Re: An important patch for egcs 1.0.1

[Joe Buck]

> It's not obvious to me that just because 1.0.1 miscompiles glibc 2.x
> the long double fix can't wait for 1.1.

HJ just sent the patch, and it seems short, and furthermore, he says
it's been in the snapshots since before egcs-1.0.1.  So why the
resistance?

Re: An important patch for egcs 1.0.1

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

    >> It's not obvious to me that just because 1.0.1 miscompiles
    >> glibc 2.x the long double fix can't wait for 1.1.

    Joe> HJ just sent the patch, and it seems short, and furthermore,
    Joe> he says it's been in the snapshots since before egcs-1.0.1.
    Joe> So why the resistance?

I'm afraid I didn't make myself clear.  In the mail you refer to, I
also wrote:

    However, if the fixes are simple, my points may be moot, and I
    don't pretend to pass judgement on the fixes themselves.  So, this
    is not an argument not to put the fixes in; only one about how we
    should determine what fixes are to go in.

I was not, therefore, trying to "resist" any particular fix.  You'll
note that I explicitly express ignorance about the particular patch in
question.

However, I stand by my statement that the bugs we fix for 1.0.2 should
be: 

  truly egregious and horrible bugs that can be fixed with very simple
  changes

The statement you quoted was meant to imply that the mere fact that
glibc cannot be compiled with the egcs release branch does not
immediately imply (in my opinion) that we are not ready for that
release.  If however, you find that bug very disturbing (and obviously
many people do!) and you believe that HJs fixes are simple (and
obviously many people do!), then I think it's clear that the fixes
should go in.  

I really didn't mean to create any controversy, or to criticize any
patches (I haven't even looked at them!).  I simply meant to caution
all of us against spending too much time messing with 1.0.2; releasing
1.1 will fix many more problems and add many more features.  I bet we
all agree; the only question is where to draw the line on 1.0.2.  I
advocate drawing the line soon, even if it means that some programs
will not work.  Again, that's not a specific comment on this
*particular* program (glibc) or the *particular* patch (HJ's long
double repair).

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: An important patch for egcs 1.0.1

[Joe Buck]

> I was not, therefore, trying to "resist" any particular fix.  You'll
> note that I explicitly express ignorance about the particular patch in
> question.
> 
> However, I stand by my statement that the bugs we fix for 1.0.2 should
> be: 
> 
>   truly egregious and horrible bugs that can be fixed with very simple
>   changes

If you'd accept the amendment ", plus embarrassing bugs that we already
have low-risk fixes for", we're in agreement.

Re: An important patch for egcs 1.0.1

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

    >> I was not, therefore, trying to "resist" any particular fix.
    >> You'll note that I explicitly express ignorance about the
    >> particular patch in question.
    >> 
    >> However, I stand by my statement that the bugs we fix for 1.0.2
    >> should be:
    >> 
    >> truly egregious and horrible bugs that can be fixed with very
    >> simple changes

    Joe> If you'd accept the amendment ", plus embarrassing bugs that
    Joe> we already have low-risk fixes for", we're in agreement.

Sure.  

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: An important patch for egcs 1.0.1

[Jeffrey A Law]

  In message < 199802162200.OAA11328@atrus.synopsys.com >you write:
  > 
  > > It's not obvious to me that just because 1.0.1 miscompiles glibc 2.x
  > > the long double fix can't wait for 1.1.
  > 
  > HJ just sent the patch, and it seems short, and furthermore, he says
  > it's been in the snapshots since before egcs-1.0.1.  So why the
  > resistance?
Once HJ notified us that the long double bug was causing glibc2 to be
mis-compiled I extracted the relavent bits from his patch and installed
them on the branch.

jeff

Re: An important patch for egcs 1.0.1

[Daniel Egger]

On Sun, 15 Feb 1998, you wrote:

>egcs 1.0.1 miscompiles glibc, especially long double.

 Sorry, but I can't agree... glibc runs perfectly on my system...
 even compiled with egcs-1.0.1 ... at the moment my libc is compiled
 with the recently received egcs-980214...

--

Servus,
       Daniel

An important patch for egcs 1.0.1

[H.J. Lu]

> 
> H.J. Lu wrote:
> > 
> > This test failed on both egcs 1.0.1 and egcs 1.0.2 under Linux/x86.
> 
> Sorry to do this to you... but I was wondering if you could explain the
> test case... I've been digging into long double's trying to find the
> root cause of a problem in kcalc, so it looks like this test case could
> Below I have a program that dies under egcs1.0.1+glibc.  There may be a
					^^^^^^^^^^^^^^^^

That is a bad combination.

> glibc bug in here, but I think it may also show an egcs bug.  Is this a
> related problem?
> 
> Doug
> -- kilpatds@erols.com
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <math.h>
> 
> int main(int argc, char *argv[])
> {
>     long double ld;
>     long l;
> 
>     modfl(1.0, &ld);
>     l = ld;
>     printf("Long Double: %lf\nLong: %ld\nLong: %X\n", ld, l);
>     if (l > 1)
>         abort();
>     if (l < 0)
>         abort();
>     
>     return EXIT_SUCCESS;
> }

Please include this in egcs 1.0.2. It may fix your bug. At least,
mine is fixed.

BTW, given this bad bug, which is fixed in gcc 2.8.0, we
should make egcs 1.0.2 ASAP. Otherwise, it will be hard for
us to convince the people to use egcs.

Thanks.


----
Fri Dec  5 16:26:03 1997  Bernd Schmidt <crux@ohara.Informatik.RWTH-Aachen.DE>

	* i386.c (notice_update_cc): Remove bogus pentium GCC code.

--- ./../../../import/egcs/gcc/config/i386/i386.c	Fri Dec 19 00:47:13 1997
+++ config/i386/i386.c	Thu Feb 12 10:49:09 1998
@@ -3397,31 +3397,37 @@
 	  if (cc_status.value1
 	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value1))
 	    cc_status.value1 = 0;
+
 	  if (cc_status.value2
 	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value2))
 	    cc_status.value2 = 0;
+
 	  return;
 	}
+
       /* Moving register into memory doesn't alter the cc's.
 	 It may invalidate the RTX's which we remember the cc's came from.  */
       if (GET_CODE (SET_DEST (exp)) == MEM
 	  && (REG_P (SET_SRC (exp))
 	      || GET_RTX_CLASS (GET_CODE (SET_SRC (exp))) == '<'))
 	{
-	  if (cc_status.value1 && GET_CODE (cc_status.value1) == MEM
-	      || reg_mentioned_p (SET_DEST (exp), cc_status.value1))
+	  if (cc_status.value1
+	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value1))
 	    cc_status.value1 = 0;
-	  if (cc_status.value2 && GET_CODE (cc_status.value2) == MEM
-	      || reg_mentioned_p (SET_DEST (exp), cc_status.value2))
+	  if (cc_status.value2
+	      && reg_overlap_mentioned_p (SET_DEST (exp), cc_status.value2))
 	    cc_status.value2 = 0;
+
 	  return;
 	}
+
       /* Function calls clobber the cc's.  */
       else if (GET_CODE (SET_SRC (exp)) == CALL)
 	{
 	  CC_STATUS_INIT;
 	  return;
 	}
+
       /* Tests and compares set the cc's in predictable ways.  */
       else if (SET_DEST (exp) == cc0_rtx)
 	{
@@ -3429,14 +3435,14 @@
 	  cc_status.value1 = SET_SRC (exp);
 	  return;
 	}
+
       /* Certain instructions effect the condition codes. */
       else if (GET_MODE (SET_SRC (exp)) == SImode
 	       || GET_MODE (SET_SRC (exp)) == HImode
 	       || GET_MODE (SET_SRC (exp)) == QImode)
 	switch (GET_CODE (SET_SRC (exp)))
 	  {
-	  case ASHIFTRT: case LSHIFTRT:
-	  case ASHIFT:
+	  case ASHIFTRT: case LSHIFTRT: case ASHIFT:
 	    /* Shifts on the 386 don't set the condition codes if the
 	       shift count is zero. */
 	    if (GET_CODE (XEXP (SET_SRC (exp), 1)) != CONST_INT)
@@ -3444,6 +3450,7 @@
 		CC_STATUS_INIT;
 		break;
 	      }
+
 	    /* We assume that the CONST_INT is non-zero (this rtx would
 	       have been deleted if it were zero. */
 
@@ -3468,6 +3475,7 @@
       if (SET_DEST (XVECEXP (exp, 0, 0)) == pc_rtx)
 	return;
       if (SET_DEST (XVECEXP (exp, 0, 0)) == cc0_rtx)
+
 	{
 	  CC_STATUS_INIT;
           if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
@@ -3481,6 +3489,7 @@
 	    cc_status.value1 = SET_SRC (XVECEXP (exp, 0, 0));
 	  return;
 	}
+
       CC_STATUS_INIT;
     }
   else