for information, gcc-4.2.3 miscompiles musl math

for information, gcc-4.2.3 miscompiles musl math

[u-uy74]

Good to be aware of:
gcc-4.2.3 miscompiles musl math since at least 1.1.6,
tested while targeting i486,
1.0.x seems to have been alright.

The symptom is that sin(larger-than-2*pi) yields large values
like "sin(8.000000) = 21.709544".
Looks like the argument reduction logic has changed in a way
which is not compatible with gcc-4.2.3.

I do not notice any problems while compiling musl with gcc-5.2, nor
have a compelling reason to insist on using gcc-4.2.3 (somebody else
might have though, gcc-4.2.3 is the last one under gpl 2).

Regards,
Rune

Re: for information, gcc-4.2.3 miscompiles musl math

[Rich Felker]

On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> Good to be aware of:
> gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> tested while targeting i486,
> 1.0.x seems to have been alright.
> 
> The symptom is that sin(larger-than-2*pi) yields large values
> like "sin(8.000000) = 21.709544".
> Looks like the argument reduction logic has changed in a way
> which is not compatible with gcc-4.2.3.

Are you using configure or a hand-written config.mak? configure sets
up a big hammer, -ffloat-store, when -fexcess-precision=standard is
not supported (i.e. on old gcc), which hopefully suffices to make this
code work, but it's possible it doesn't always do the job.

> I do not notice any problems while compiling musl with gcc-5.2, nor
> have a compelling reason to insist on using gcc-4.2.3 (somebody else
> might have though, gcc-4.2.3 is the last one under gpl 2).

I thought 4.2.1 was the last.

If you don't want to look into it further yourself I'll see if someone
else interested in old toolchains can or try to get around to it
myself. I really don't want to introduce more hacks for these broken
compilers though. If people really still want to use them, we should
probably just find a cheap way to fix the compiler, like patching it
not to perform any optimizations whatsoever on floating point
expressions.

Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:

> On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > Good to be aware of:
> > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > tested while targeting i486,
> > 1.0.x seems to have been alright.
> > 
> > The symptom is that sin(larger-than-2*pi) yields large values
> > like "sin(8.000000) = 21.709544".
> > Looks like the argument reduction logic has changed in a way
> > which is not compatible with gcc-4.2.3.
> 
> Are you using configure or a hand-written config.mak? configure sets
> up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> not supported (i.e. on old gcc), which hopefully suffices to make this
> code work, but it's possible it doesn't always do the job.
> 

i think this change might be it:
http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30

the new code avoids an extra store,
but then i rely on the evaluation
being in long double.

with -ffloat-store this breaks,
adding extra store rounds at the
wrong place.

i didnt think about old toolchains
when i made that change.

this also affects rounding functions
(but i386 has asm for most of them)

i will think about it if i can change
the code so it does not break with
-ffloat-store.

> > I do not notice any problems while compiling musl with gcc-5.2, nor
> > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > might have though, gcc-4.2.3 is the last one under gpl 2).
> 
> I thought 4.2.1 was the last.
> 
> If you don't want to look into it further yourself I'll see if someone
> else interested in old toolchains can or try to get around to it
> myself. I really don't want to introduce more hacks for these broken
> compilers though. If people really still want to use them, we should
> probably just find a cheap way to fix the compiler, like patching it
> not to perform any optimizations whatsoever on floating point
> expressions.
> 
> Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Rich Felker]

On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:
> 
> > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > > Good to be aware of:
> > > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > > tested while targeting i486,
> > > 1.0.x seems to have been alright.
> > > 
> > > The symptom is that sin(larger-than-2*pi) yields large values
> > > like "sin(8.000000) = 21.709544".
> > > Looks like the argument reduction logic has changed in a way
> > > which is not compatible with gcc-4.2.3.
> > 
> > Are you using configure or a hand-written config.mak? configure sets
> > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > not supported (i.e. on old gcc), which hopefully suffices to make this
> > code work, but it's possible it doesn't always do the job.
> > 
> 
> i think this change might be it:
> http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30
> 
> the new code avoids an extra store,
> but then i rely on the evaluation
> being in long double.
> 
> with -ffloat-store this breaks,
> adding extra store rounds at the
> wrong place.
> 
> i didnt think about old toolchains
> when i made that change.
> 
> this also affects rounding functions
> (but i386 has asm for most of them)
> 
> i will think about it if i can change
> the code so it does not break with
> -ffloat-store.

Alternatively we could see if removing -ffloat-store fixes it and
avoids introducing any horrible bugs. That would be cleaner, wouldn't
it?

Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-11-21 14:49:38 -0500]:

> On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:
> > 
> > > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > > > Good to be aware of:
> > > > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > > > tested while targeting i486,
> > > > 1.0.x seems to have been alright.
> > > > 
> > > > The symptom is that sin(larger-than-2*pi) yields large values
> > > > like "sin(8.000000) = 21.709544".
> > > > Looks like the argument reduction logic has changed in a way
> > > > which is not compatible with gcc-4.2.3.
> > > 
> > > Are you using configure or a hand-written config.mak? configure sets
> > > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > > not supported (i.e. on old gcc), which hopefully suffices to make this
> > > code work, but it's possible it doesn't always do the job.
> > > 
> > 
> > i think this change might be it:
> > http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30
> > 
> > the new code avoids an extra store,
> > but then i rely on the evaluation
> > being in long double.
> > 
> > with -ffloat-store this breaks,
> > adding extra store rounds at the
> > wrong place.
> > 
> > i didnt think about old toolchains
> > when i made that change.
> > 
> > this also affects rounding functions
> > (but i386 has asm for most of them)
> > 
> > i will think about it if i can change
> > the code so it does not break with
> > -ffloat-store.
> 
> Alternatively we could see if removing -ffloat-store fixes it and
> avoids introducing any horrible bugs. That would be cleaner, wouldn't
> it?
> 

i removed all the volatile hacks and i think
those are needed without -ffloat-store or
-fexcess-precision=standard when i do want
the rounding.

i dont know how many places are affected
because i tried to rewrite things to avoid
the need for extra stores.

it might be worth a try but there is no warranty..

Re: for information, gcc-4.2.3 miscompiles musl math

[Rich Felker]

On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:
> 
> > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > > Good to be aware of:
> > > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > > tested while targeting i486,
> > > 1.0.x seems to have been alright.
> > > 
> > > The symptom is that sin(larger-than-2*pi) yields large values
> > > like "sin(8.000000) = 21.709544".
> > > Looks like the argument reduction logic has changed in a way
> > > which is not compatible with gcc-4.2.3.
> > 
> > Are you using configure or a hand-written config.mak? configure sets
> > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > not supported (i.e. on old gcc), which hopefully suffices to make this
> > code work, but it's possible it doesn't always do the job.
> > 
> 
> i think this change might be it:
> http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30
> 
> the new code avoids an extra store,
> but then i rely on the evaluation
> being in long double.
> 
> with -ffloat-store this breaks,
> adding extra store rounds at the
> wrong place.

Hmm, which places does it add the stores around? Could you fix it with
an explicit conversion to double_t? That might be nice to harden
against broken compilers without penalizing correct ones.

Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-11-21 14:51:44 -0500]:
> On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:
> > 
> > > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > > > Good to be aware of:
> > > > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > > > tested while targeting i486,
> > > > 1.0.x seems to have been alright.
> > > > 
> > > > The symptom is that sin(larger-than-2*pi) yields large values
> > > > like "sin(8.000000) = 21.709544".
> > > > Looks like the argument reduction logic has changed in a way
> > > > which is not compatible with gcc-4.2.3.
> > > 
> > > Are you using configure or a hand-written config.mak? configure sets
> > > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > > not supported (i.e. on old gcc), which hopefully suffices to make this
> > > code work, but it's possible it doesn't always do the job.
> > > 
> > 
> > i think this change might be it:
> > http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30
> > 
> > the new code avoids an extra store,
> > but then i rely on the evaluation
> > being in long double.
> > 
> > with -ffloat-store this breaks,
> > adding extra store rounds at the
> > wrong place.
> 
> Hmm, which places does it add the stores around? Could you fix it with
> an explicit conversion to double_t? That might be nice to harden
> against broken compilers without penalizing correct ones.
> 

yeah that might work

i dont have gcc-4.2, can you try:

diff --git a/src/math/__rem_pio2.c b/src/math/__rem_pio2.c
index a40db9f..d403f81 100644
--- a/src/math/__rem_pio2.c
+++ b/src/math/__rem_pio2.c
@@ -118,7 +118,7 @@ int __rem_pio2(double x, double *y)
 	if (ix < 0x413921fb) {  /* |x| ~< 2^20*(pi/2), medium size */
 medium:
 		/* rint(x/(pi/2)), Assume round-to-nearest. */
-		fn = x*invpio2 + toint - toint;
+		fn = (double_t)x*invpio2 + toint - toint;
 		n = (int32_t)fn;
 		r = x - fn*pio2_1;
 		w = fn*pio2_1t;  /* 1st round, good to 85 bits */

Re: for information, gcc-4.2.3 miscompiles musl math

[Rich Felker]

On Sat, Nov 21, 2015 at 09:03:42PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-21 14:51:44 -0500]:
> > On Sat, Nov 21, 2015 at 08:41:32PM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@libc.org> [2015-11-21 14:25:48 -0500]:
> > > 
> > > > On Sat, Nov 21, 2015 at 06:24:18PM +0100, u-uy74@aetey.se wrote:
> > > > > Good to be aware of:
> > > > > gcc-4.2.3 miscompiles musl math since at least 1.1.6,
> > > > > tested while targeting i486,
> > > > > 1.0.x seems to have been alright.
> > > > > 
> > > > > The symptom is that sin(larger-than-2*pi) yields large values
> > > > > like "sin(8.000000) = 21.709544".
> > > > > Looks like the argument reduction logic has changed in a way
> > > > > which is not compatible with gcc-4.2.3.
> > > > 
> > > > Are you using configure or a hand-written config.mak? configure sets
> > > > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > > > not supported (i.e. on old gcc), which hopefully suffices to make this
> > > > code work, but it's possible it doesn't always do the job.
> > > > 
> > > 
> > > i think this change might be it:
> > > http://git.musl-libc.org/cgit/musl/commit/?id=0ce946cf808274c2d6e5419b139e130c8ad4bd30
> > > 
> > > the new code avoids an extra store,
> > > but then i rely on the evaluation
> > > being in long double.
> > > 
> > > with -ffloat-store this breaks,
> > > adding extra store rounds at the
> > > wrong place.
> > 
> > Hmm, which places does it add the stores around? Could you fix it with
> > an explicit conversion to double_t? That might be nice to harden
> > against broken compilers without penalizing correct ones.
> > 
> 
> yeah that might work
> 
> i dont have gcc-4.2, can you try:
> 
> diff --git a/src/math/__rem_pio2.c b/src/math/__rem_pio2.c
> index a40db9f..d403f81 100644
> --- a/src/math/__rem_pio2.c
> +++ b/src/math/__rem_pio2.c
> @@ -118,7 +118,7 @@ int __rem_pio2(double x, double *y)
>  	if (ix < 0x413921fb) {  /* |x| ~< 2^20*(pi/2), medium size */
>  medium:
>  		/* rint(x/(pi/2)), Assume round-to-nearest. */
> -		fn = x*invpio2 + toint - toint;
> +		fn = (double_t)x*invpio2 + toint - toint;
>  		n = (int32_t)fn;
>  		r = x - fn*pio2_1;
>  		w = fn*pio2_1t;  /* 1st round, good to 85 bits */

I just tested with 4.2.1 binaries from Aboriginal Linux and (1) was
able to reproduce the bug, and (2) made it go away with your patch.
Not only did the bogus out-of-range result go away; the new result is
a bit-exact match for modern gcc.

Conceptually, it seems to me that for code that explicitly uses
float_t and double_t in expressions and only converts down to float or
double with stores, -ffloat-store should be just as good (albeit
overly pessimizing) as -fexcess-precision=standard. So IMO this looks
like a really good solution, and might come in handy as hardening
against mistakes in new compilers too. IIRC firm used to do this wrong
and I would not be at all surprised if pcc gets it wrong.

Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Szabolcs Nagy]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

* Rich Felker <dalias@libc.org> [2015-11-21 15:15:51 -0500]:
> I just tested with 4.2.1 binaries from Aboriginal Linux and (1) was
> able to reproduce the bug, and (2) made it go away with your patch.
> Not only did the bogus out-of-range result go away; the new result is
> a bit-exact match for modern gcc.
> 
> Conceptually, it seems to me that for code that explicitly uses
> float_t and double_t in expressions and only converts down to float or
> double with stores, -ffloat-store should be just as good (albeit
> overly pessimizing) as -fexcess-precision=standard. So IMO this looks
> like a really good solution, and might come in handy as hardening
> against mistakes in new compilers too. IIRC firm used to do this wrong
> and I would not be at all surprised if pcc gets it wrong.
> 

i did the changes where i think it was necessary
(hypot has asm implementation on i386 though).

(in most cases the code already uses float_t, double_t
where this would matter.)

[-- Attachment #2: 0001-math-make-ffloat-store-work-on-i386.patch --]
[-- Type: text/x-diff, Size: 2257 bytes --]

From c4cf94d37e2c556a2f77b1debe2fe9ec269fdb3e Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <nsz@port70.net>
Date: Sat, 21 Nov 2015 21:23:30 +0000
Subject: [PATCH] math: make -ffloat-store work on i386

old i386 toolchains don't support -fexcess-precision=standard
and then musl configure defaults to -ffloat-store to avoid
problems because of excess precision.

however there are cases when excess precision must not be rounded
away so -ffloat-store breaks the code.

this patch adds (double_t) casts to double precision arithmetics
when the excess precision is required for correct results.
(without -ffloat-store or on non-i386 targets the generated code
is not changed.)
---
 src/math/__rem_pio2.c  | 2 +-
 src/math/__rem_pio2f.c | 2 +-
 src/math/hypot.c       | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/math/__rem_pio2.c b/src/math/__rem_pio2.c
index a40db9f..d403f81 100644
--- a/src/math/__rem_pio2.c
+++ b/src/math/__rem_pio2.c
@@ -118,7 +118,7 @@ int __rem_pio2(double x, double *y)
 	if (ix < 0x413921fb) {  /* |x| ~< 2^20*(pi/2), medium size */
 medium:
 		/* rint(x/(pi/2)), Assume round-to-nearest. */
-		fn = x*invpio2 + toint - toint;
+		fn = (double_t)x*invpio2 + toint - toint;
 		n = (int32_t)fn;
 		r = x - fn*pio2_1;
 		w = fn*pio2_1t;  /* 1st round, good to 85 bits */
diff --git a/src/math/__rem_pio2f.c b/src/math/__rem_pio2f.c
index f516385..4473c1c 100644
--- a/src/math/__rem_pio2f.c
+++ b/src/math/__rem_pio2f.c
@@ -51,7 +51,7 @@ int __rem_pio2f(float x, double *y)
 	/* 25+53 bit pi is good enough for medium size */
 	if (ix < 0x4dc90fdb) {  /* |x| ~< 2^28*(pi/2), medium size */
 		/* Use a specialized rint() to get fn.  Assume round-to-nearest. */
-		fn = x*invpio2 + toint - toint;
+		fn = (double_t)x*invpio2 + toint - toint;
 		n  = (int32_t)fn;
 		*y = x - fn*pio2_1 - fn*pio2_1t;
 		return n;
diff --git a/src/math/hypot.c b/src/math/hypot.c
index 29ec6a4..6071bf1 100644
--- a/src/math/hypot.c
+++ b/src/math/hypot.c
@@ -12,10 +12,10 @@ static void sq(double_t *hi, double_t *lo, double x)
 {
 	double_t xh, xl, xc;
 
-	xc = x*SPLIT;
+	xc = (double_t)x*SPLIT;
 	xh = x - xc + xc;
 	xl = x - xh;
-	*hi = x*x;
+	*hi = (double_t)x*x;
 	*lo = xh*xh - *hi + 2*xh*xl + xl*xl;
 }
 
-- 
2.4.1

Re: for information, gcc-4.2.3 miscompiles musl math

[u-uy74]

On Sat, Nov 21, 2015 at 09:03:42PM +0100, Szabolcs Nagy wrote:
> > Hmm, which places does it add the stores around? Could you fix it with
> > an explicit conversion to double_t? That might be nice to harden
> > against broken compilers without penalizing correct ones.
> 
> yeah that might work
> 
> i dont have gcc-4.2, can you try:
> 
> diff --git a/src/math/__rem_pio2.c b/src/math/__rem_pio2.c
> index a40db9f..d403f81 100644
> --- a/src/math/__rem_pio2.c
> +++ b/src/math/__rem_pio2.c
> @@ -118,7 +118,7 @@ int __rem_pio2(double x, double *y)
>  	if (ix < 0x413921fb) {  /* |x| ~< 2^20*(pi/2), medium size */
>  medium:
>  		/* rint(x/(pi/2)), Assume round-to-nearest. */
> -		fn = x*invpio2 + toint - toint;
> +		fn = (double_t)x*invpio2 + toint - toint;
>  		n = (int32_t)fn;
>  		r = x - fn*pio2_1;
>  		w = fn*pio2_1t;  /* 1st round, good to 85 bits */

Sure, the result:

sin(8.000000) = 0.989358

Which is the same as produced by musl-1.0.0+, without this patch,
iow the expected "good" value.

Thanks!

Rune

Re: for information, gcc-4.2.3 miscompiles musl math

[u-uy74]

On Sat, Nov 21, 2015 at 02:25:48PM -0500, Rich Felker wrote:
> > like "sin(8.000000) = 21.709544".
> > Looks like the argument reduction logic has changed in a way
> > which is not compatible with gcc-4.2.3.
> 
> Are you using configure or a hand-written config.mak? configure sets
> up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> not supported (i.e. on old gcc), which hopefully suffices to make this
> code work, but it's possible it doesn't always do the job.

I was using configure.

Here are the compilation flags which were used while building with 4.2.3:
(the command line has been run through "fmt" here)

gcc -march=i486 -std=c99 -nostdinc -ffreestanding -ffloat-store
-frounding-math -D_XOPEN_SOURCE=700 -I./arch/i386 -I./src/internal
-I./include  -Os -pipe -fomit-frame-pointer -fno-unwind-tables
-fno-asynchronous-unwind-tables -Wa,--noexecstack -march=i486
-mtune=generic -Werror=implicit-function-declaration -Werror=implicit-int
-Werror=pointer-sign -Werror=pointer-arith -fno-stack-protector  -c -o
src/math/sin.o src/math/sin.c

Yes, -ffloat-store is present but apparently did not suffice.

> > I do not notice any problems while compiling musl with gcc-5.2, nor
> > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > might have though, gcc-4.2.3 is the last one under gpl 2).
> 
> I thought 4.2.1 was the last.

I think Wikipedia says so as well but The Source is the truth. It is
4.2.3 and nothing else. It is also in fact remarkably better than 4.2.1
and I could build with it mostly everything I needed, modulo features
newer than the compiler.

> If you don't want to look into it further yourself I'll see if someone
> else interested in old toolchains can or try to get around to it
> myself. I really don't want to introduce more hacks for these broken
> compilers though. If people really still want to use them, we should

It was not my intention to fix, only to warn. On the other side, I have a
convenient environment to play with multiple versions of everything,
I can run a test if you will want me to.

> probably just find a cheap way to fix the compiler, like patching it
> not to perform any optimizations whatsoever on floating point
> expressions.

This would surely be cleaner from the musl perspective, but also a much
more expensive procedure (rebuild the compiler) than e.g. patching musl.

Anyway, probably a fix is not worth spending any time on, until somebody
explicitly asks for support of 4.2.3.

Nevertheless, thanks for taking this into consideration Rich.

Rune

Re: for information, gcc-4.2.3 miscompiles musl math

[Rich Felker]

On Sat, Nov 21, 2015 at 09:11:22PM +0100, u-uy74@aetey.se wrote:
> On Sat, Nov 21, 2015 at 02:25:48PM -0500, Rich Felker wrote:
> > > like "sin(8.000000) = 21.709544".
> > > Looks like the argument reduction logic has changed in a way
> > > which is not compatible with gcc-4.2.3.
> > 
> > Are you using configure or a hand-written config.mak? configure sets
> > up a big hammer, -ffloat-store, when -fexcess-precision=standard is
> > not supported (i.e. on old gcc), which hopefully suffices to make this
> > code work, but it's possible it doesn't always do the job.
> 
> I was using configure.
> 
> Here are the compilation flags which were used while building with 4.2.3:
> (the command line has been run through "fmt" here)

OK. It looks like we've tracked down the problem anyway and have a
viable fix already, anyway.

> > > I do not notice any problems while compiling musl with gcc-5.2, nor
> > > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > > might have though, gcc-4.2.3 is the last one under gpl 2).
> > 
> > I thought 4.2.1 was the last.
> 
> I think Wikipedia says so as well but The Source is the truth. It is
> 4.2.3 and nothing else. It is also in fact remarkably better than 4.2.1
> and I could build with it mostly everything I needed, modulo features
> newer than the compiler.

This sounds interesting. Do you have any details beyond "remarkably
better"? If you're right and the benefits are significant maybe Rob
could update Aboriginal to this version.

Rich

Re: for information, gcc-4.2.3 miscompiles musl math

[Alexander Monakov]

On Sat, 21 Nov 2015, u-uy74@aetey.se wrote:
> > > I do not notice any problems while compiling musl with gcc-5.2, nor
> > > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > > might have though, gcc-4.2.3 is the last one under gpl 2).
> > 
> > I thought 4.2.1 was the last.
> 
> I think Wikipedia says so as well but The Source is the truth. It is
> 4.2.3 and nothing else.

Are you perhaps concluding that just from the absence of COPYING3 in the
toplevel directory?  The gcc/ subdirectory does contain COPYING3, and
individual *.c files explicitely mention GPLv3 in the copyright notice in the
block comment at the top of the file.  Ditto for 4.2.2.

Alexander

Re: for information, gcc-4.2.3 miscompiles musl math

[u-uy74]

On Sat, Nov 21, 2015 at 11:30:58PM +0300, Alexander Monakov wrote:
> On Sat, 21 Nov 2015, u-uy74@aetey.se wrote:
> > > > might have though, gcc-4.2.3 is the last one under gpl 2).
> > > 
> > > I thought 4.2.1 was the last.
> > 
> > I think Wikipedia says so as well but The Source is the truth. It is
> > 4.2.3 and nothing else.

> Are you perhaps concluding that just from the absence of COPYING3 in the
> toplevel directory?

No.

I concluded this based on the contents of the file COPYING in the toplevel
directory and on the fact that neither NEWS nor ChangeLog there mention
any license changes.

> The gcc/ subdirectory does contain COPYING3, and

Indeed. I have to admit that I missed this fact and as bad as it is,
did not actually search for patterns in the comments.

Better late than never:

Of the gcc-4.2.3 source archive files

11236 ones contain "COPYING[^3]"
 1424 ones contain "COPYING3"

which of course confirms that gcc-4.2.3 is _not_ compatible with gpl2,
anyway not as a whole, because of the 11% gpl3-pollution in its files.

Sorry for making misleading statements about its license and thanks
for clearing the matter Alexander.

Nice that the fix for the float arithmetics applies to Aboriginal.

Rune

Re: for information, gcc-4.2.3 miscompiles musl math

[Isaac Dunham]

On Sat, Nov 21, 2015 at 09:11:22PM +0100, u-uy74@aetey.se wrote:
> On Sat, Nov 21, 2015 at 02:25:48PM -0500, Rich Felker wrote:
> > > I do not notice any problems while compiling musl with gcc-5.2, nor
> > > have a compelling reason to insist on using gcc-4.2.3 (somebody else
> > > might have though, gcc-4.2.3 is the last one under gpl 2).
> > 
> > I thought 4.2.1 was the last.
> 
> I think Wikipedia says so as well but The Source is the truth. It is
> 4.2.3 and nothing else. It is also in fact remarkably better than 4.2.1
> and I could build with it mostly everything I needed, modulo features
> newer than the compiler.

The patch from GCC 4.2.1 to 4.2.2 adds COPYING3 and changes several files
(included in the compilers) to GPL3.

HTH,
Isaac Dunham