* Re: An important patch for egcs 1.0.1
@ 1998-02-15 13:42 Daniel Egger
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Egger @ 1998-02-15 13:42 UTC (permalink / raw)
To: H.J. Lu; +Cc: egcs, libc-linux
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 @ 1998-02-15 11:33 Daniel Egger 1998-02-15 11:41 ` H.J. Lu 0 siblings, 1 reply; 12+ messages in thread From: Daniel Egger @ 1998-02-15 11:33 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, GNU C Library 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-15 11:33 Daniel Egger @ 1998-02-15 11:41 ` H.J. Lu 1998-02-15 13:42 ` Mark Mitchell 0 siblings, 1 reply; 12+ messages in thread From: H.J. Lu @ 1998-02-15 11:41 UTC (permalink / raw) To: Daniel.Egger; +Cc: egcs, libc-linux > > 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-15 11:41 ` H.J. Lu @ 1998-02-15 13:42 ` Mark Mitchell 1998-02-15 17:27 ` Michael Neuffer 1998-02-16 14:21 ` Joe Buck 0 siblings, 2 replies; 12+ messages in thread From: Mark Mitchell @ 1998-02-15 13:42 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-15 13:42 ` Mark Mitchell @ 1998-02-15 17:27 ` Michael Neuffer 1998-02-16 14:21 ` Joe Buck 1 sibling, 0 replies; 12+ messages in thread From: Michael Neuffer @ 1998-02-15 17:27 UTC (permalink / raw) To: Mark Mitchell; +Cc: H.J. Lu, egcs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-15 13:42 ` Mark Mitchell 1998-02-15 17:27 ` Michael Neuffer @ 1998-02-16 14:21 ` Joe Buck 1998-02-16 14:21 ` H.J. Lu ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: Joe Buck @ 1998-02-16 14:21 UTC (permalink / raw) To: mmitchell; +Cc: hjl, egcs > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-16 14:21 ` Joe Buck @ 1998-02-16 14:21 ` H.J. Lu 1998-02-16 16:56 ` Mark Mitchell 1998-02-16 21:16 ` Jeffrey A Law 2 siblings, 0 replies; 12+ messages in thread From: H.J. Lu @ 1998-02-16 14:21 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > > > 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-16 14:21 ` Joe Buck 1998-02-16 14:21 ` H.J. Lu @ 1998-02-16 16:56 ` Mark Mitchell 1998-02-16 18:19 ` Joe Buck 1998-02-16 21:16 ` Jeffrey A Law 2 siblings, 1 reply; 12+ messages in thread From: Mark Mitchell @ 1998-02-16 16:56 UTC (permalink / raw) To: Joe Buck; +Cc: hjl, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-16 16:56 ` Mark Mitchell @ 1998-02-16 18:19 ` Joe Buck 1998-02-16 18:43 ` Mark Mitchell 0 siblings, 1 reply; 12+ messages in thread From: Joe Buck @ 1998-02-16 18:19 UTC (permalink / raw) To: mmitchell; +Cc: jbuck, hjl, egcs > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-16 18:19 ` Joe Buck @ 1998-02-16 18:43 ` Mark Mitchell 0 siblings, 0 replies; 12+ messages in thread From: Mark Mitchell @ 1998-02-16 18:43 UTC (permalink / raw) To: Joe Buck; +Cc: hjl, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: An important patch for egcs 1.0.1 1998-02-16 14:21 ` Joe Buck 1998-02-16 14:21 ` H.J. Lu 1998-02-16 16:56 ` Mark Mitchell @ 1998-02-16 21:16 ` Jeffrey A Law 2 siblings, 0 replies; 12+ messages in thread From: Jeffrey A Law @ 1998-02-16 21:16 UTC (permalink / raw) To: Joe Buck; +Cc: mmitchell, hjl, egcs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <34E2AFA6.F4E316C@erols.com>]
* An important patch for egcs 1.0.1 [not found] <34E2AFA6.F4E316C@erols.com> @ 1998-02-12 20:07 ` H.J. Lu 0 siblings, 0 replies; 12+ messages in thread From: H.J. Lu @ 1998-02-12 20:07 UTC (permalink / raw) To: Douglas Kilpatrick; +Cc: egcs, GNU C Library > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-02-16 21:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-02-15 13:42 An important patch for egcs 1.0.1 Daniel Egger -- strict thread matches above, loose matches on Subject: below -- 1998-02-15 11:33 Daniel Egger 1998-02-15 11:41 ` H.J. Lu 1998-02-15 13:42 ` Mark Mitchell 1998-02-15 17:27 ` Michael Neuffer 1998-02-16 14:21 ` Joe Buck 1998-02-16 14:21 ` H.J. Lu 1998-02-16 16:56 ` Mark Mitchell 1998-02-16 18:19 ` Joe Buck 1998-02-16 18:43 ` Mark Mitchell 1998-02-16 21:16 ` Jeffrey A Law [not found] <34E2AFA6.F4E316C@erols.com> 1998-02-12 20:07 ` H.J. Lu
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).