GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Richard Biener]

Status
======

GCC 8 is in regression and documentation fixes stage now similar as if
trunk was a release branch.

We're still in pretty bad shape regression-wise.  Please also take
the opportunity to check the state of your favorite host/target
combination to make sure building and testing works appropriately.


Quality Data
============

Priority          #   Change from last report
--------        ---   -----------------------
P1               36   +  27
P2              133   -   1
P3               57   -  51
P4		158   -   3
P5		 27
--------        ---   -----------------------
Total P1-P3     226   -  25
Total		411   -  28


Previous Report
===============

https://gcc.gnu.org/ml/gcc/2018-01/msg00033.html

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Segher Boessenkool]

On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> We're still in pretty bad shape regression-wise.  Please also take
> the opportunity to check the state of your favorite host/target
> combination to make sure building and testing works appropriately.

I tested building Linux (the kernel) for all supported architectures.
Everything builds (with my usual tweaks, link with libgcc etc.);
except x86_64 and sh have more problems in the kernel, and mips has
an ICE.  I'll open a PR for that one.


Segher

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Joseph Myers]

On Tue, 16 Jan 2018, Segher Boessenkool wrote:

> On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> > We're still in pretty bad shape regression-wise.  Please also take
> > the opportunity to check the state of your favorite host/target
> > combination to make sure building and testing works appropriately.
> 
> I tested building Linux (the kernel) for all supported architectures.
> Everything builds (with my usual tweaks, link with libgcc etc.);
> except x86_64 and sh have more problems in the kernel, and mips has
> an ICE.  I'll open a PR for that one.

And all glibc architectures compile (and compile the testsuite) OK except 
for the sh4eb ICE reported in bug 83760 (and the longstanding coldfire 
issue, bug 68467).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Andrew Roberts]

Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0 
snapshot, it still is working fine with 7.2.0.
I've added bug: 83903

x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building 
with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems.

I observe isl was updated to 0.18 in the download_prerequisites script. 
Are the other's going to get updated before the 8.0.0 release?

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Richard Biener]

On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts <andrewm.roberts@sky.com> wrote:
> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
> snapshot, it still is working fine with 7.2.0.
> I've added bug: 83903
>
> x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building
> with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems.
>
> I observe isl was updated to 0.18 in the download_prerequisites script. Are
> the other's going to get updated before the 8.0.0 release?

Now that mpc 1.1.0 was released we could update the versions if we get
sufficient
"positives" from people testing with newer releases.

Richard.

>

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Segher Boessenkool]

On Tue, Jan 16, 2018 at 06:50:07AM -0600, Segher Boessenkool wrote:
> On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> > We're still in pretty bad shape regression-wise.  Please also take
> > the opportunity to check the state of your favorite host/target
> > combination to make sure building and testing works appropriately.
> 
> I tested building Linux (the kernel) for all supported architectures.
> Everything builds (with my usual tweaks, link with libgcc etc.);
> except x86_64 and sh have more problems in the kernel, and mips has
> an ICE.  I'll open a PR for that one.

I messed up this testing, accidentally tested trunk instead.  Whoops :-/

For 7, mips works just dandy.  Rest is the same (i.e. all works, x86_64
and sh have problems in the kernel code itself, not our problem).


Segher

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Rainer Orth]

Hi Richard,

> On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts <andrewm.roberts@sky.com> wrote:
>> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
>> snapshot, it still is working fine with 7.2.0.
>> I've added bug: 83903
>>
>> x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building
>> with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems.
>>
>> I observe isl was updated to 0.18 in the download_prerequisites script. Are
>> the other's going to get updated before the 8.0.0 release?
>
> Now that mpc 1.1.0 was released we could update the versions if we get
> sufficient
> "positives" from people testing with newer releases.

I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results:

* The gmp reuse test enters an infinite loop on 32-bit sparc.

* The mpfr trint test FAILs on sparcv9.  The failure vanishes with
  --disable-thread-safe.

* Many mpfr tests FAIL on amd64.  Again, they vanish with
  --disable-thread-safe.

I have not yet tried building gcc with those versions yet.

Beside, IMO we need to make sure that trunk and all open branches can be
built with that version set; having to maintain two different sets isn't
an option.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Andrew Roberts]

It might be worth checking what MPFR is linking with in the test suite. 
I seemed to see it
linking with the system libs when built in tree, rather than the in tree 
ones.
This seems a regression in the MPFR test suite compared with 3.1.6

Andrew

On 26/01/18 14:22, Rainer Orth wrote:
>
> I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
> target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results:
>
> * The gmp reuse test enters an infinite loop on 32-bit sparc.
>
> * The mpfr trint test FAILs on sparcv9.  The failure vanishes with
>    --disable-thread-safe.
>
> * Many mpfr tests FAIL on amd64.  Again, they vanish with
>    --disable-thread-safe.
>
> I have not yet tried building gcc with those versions yet.
>
> Beside, IMO we need to make sure that trunk and all open branches can be
> built with that version set; having to maintain two different sets isn't
> an option.
>
> 	Rainer
>

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Rainer Orth]

Hi Andrew,

> It might be worth checking what MPFR is linking with in the test suite. I
> seemed to see it
> linking with the system libs when built in tree, rather than the in tree
> ones.

that's certainly not the case on Solaris 10: unlike Solaris 11, there are
no bundled gmp/mpfr/mpc present.

> This seems a regression in the MPFR test suite compared with 3.1.6

It depends: without --disable-thread-safe (which is equivalent to
3.1.6), the tests PASS.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Rainer Orth]

Hi Richard,

>> Now that mpc 1.1.0 was released we could update the versions if we get
>> sufficient
>> "positives" from people testing with newer releases.
>
> I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
> target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results:
>
> * The gmp reuse test enters an infinite loop on 32-bit sparc.
>
> * The mpfr trint test FAILs on sparcv9.  The failure vanishes with
>   --disable-thread-safe.
>
> * Many mpfr tests FAIL on amd64.  Again, they vanish with
>   --disable-thread-safe.
>
> I have not yet tried building gcc with those versions yet.
>
> Beside, IMO we need to make sure that trunk and all open branches can be
> built with that version set; having to maintain two different sets isn't
> an option.

prompted by Ian's patch that needed mpfr 3.0.0+, I've now completed the
tests, with mpfr built with --disable-thread-safe to avoid most of the
failures above.  Bootstrapped mainline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, both 32 and 64-bit, and gcc-6 branch on
i386-pc-solaris2.10 and sparc-sun-solaris2.10.

No regressions in all cases, so the new versions are an option with the
proviso of prominently documenting the need for --disable-thread-safe
(or fixing the bugs in time ;-).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Matthias Klose]

On 17.01.2018 09:19, Richard Biener wrote:
> On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts <andrewm.roberts@sky.com> wrote:
>> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
>> snapshot, it still is working fine with 7.2.0.
>> I've added bug: 83903
>>
>> x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building
>> with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems.
>>
>> I observe isl was updated to 0.18 in the download_prerequisites script. Are
>> the other's going to get updated before the 8.0.0 release?
> 
> Now that mpc 1.1.0 was released we could update the versions if we get
> sufficient
> "positives" from people testing with newer releases.

I have seen some issues with mpfr 4.0.0 on 32bit platforms, however not in GCC
itself yet.  These are all fixed in 4.0.1 rc2, so maybe document 4.0.1 instead
of 4.0.0 once it is released.

Matthias

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 10:49:48 +0100, Matthias Klose wrote:
> I have seen some issues with mpfr 4.0.0 on 32bit platforms, however
> not in GCC itself yet. These are all fixed in 4.0.1 rc2, so maybe
> document 4.0.1 instead of 4.0.0 once it is released.

The issues were also present on 64-bit platforms and were due to
a bug in mpfr_div_ui, which has always been present, since 1999.
With MPFR 4.0.0, they are also visible with mpfr_div just because
mpfr_div now uses mpfr_div_ui in some simple cases. I don't think
that GCC could be affected because AFAIK, a failure can only occur
when the input and output precisions are different, or is this
possible with GCC?

Now, I've just found a "regression" when comparing Sipe results with
MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
(float) or 2 (double) that is incorrect, 3 (long double) being OK.
Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
are affected. I'll try to find a simple test case for a bug report.
I suspect that the regression comes from the fact this is a new
machine + the use (as in the past) of -march=native.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:14:38 +0100, Vincent Lefevre wrote:
> Now, I've just found a "regression" when comparing Sipe results with
> MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
> (float) or 2 (double) that is incorrect, 3 (long double) being OK.
> Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
> machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
> are affected. I'll try to find a simple test case for a bug report.
> I suspect that the regression comes from the fact this is a new
> machine + the use (as in the past) of -march=native.

Well, if I add -std=c99 or -std=c11, the failure disappears. The
reason is that GCC generates a FMA (indeed, this new machine has
a FMA), but this occurs across different C statements. So, maybe
not a bug, but a bad feature, IMHO.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Joseph Myers]

On Tue, 6 Feb 2018, Vincent Lefevre wrote:

> The issues were also present on 64-bit platforms and were due to
> a bug in mpfr_div_ui, which has always been present, since 1999.
> With MPFR 4.0.0, they are also visible with mpfr_div just because
> mpfr_div now uses mpfr_div_ui in some simple cases. I don't think
> that GCC could be affected because AFAIK, a failure can only occur
> when the input and output precisions are different, or is this
> possible with GCC?

GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of 
libm functions with constant arguments (input and output precisions should 
always be the same, since GCC doesn't yet support built-in functions for 
the TS 18661-1 narrowing functions such as fsqrtl), and for correctly 
rounding conversions of decimal strings to binary floating point.  The + - 
* / operations are handled directly in real.c without use of MPFR.  Of 
course MPFR functions called might use mpfr_div indirectly.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Joseph Myers]

On Tue, 6 Feb 2018, Vincent Lefevre wrote:

> Well, if I add -std=c99 or -std=c11, the failure disappears. The
> reason is that GCC generates a FMA (indeed, this new machine has
> a FMA), but this occurs across different C statements. So, maybe
> not a bug, but a bad feature, IMHO.

Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to 
disable it between statements (which currently actually disables all 
contraction, as the FMA generation doesn't know what was originally a 
single source expression).  The default in the absence of such -std 
options is -ffp-contract=fast (allowing contraction including between 
different statements).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:32:30 +0000, Joseph Myers wrote:
> GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of 
> libm functions with constant arguments (input and output precisions should 
> always be the same, since GCC doesn't yet support built-in functions for 
> the TS 18661-1 narrowing functions such as fsqrtl), and for correctly 
> rounding conversions of decimal strings to binary floating point.  The + - 
> * / operations are handled directly in real.c without use of MPFR.  Of 
> course MPFR functions called might use mpfr_div indirectly.

Yes, it might be possible to get an error via a call to mpfr_div
inside MPFR. And perhaps mpfr_div_ui too (with any MPFR version).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:34:23 +0000, Joseph Myers wrote:
> Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to 
> disable it between statements (which currently actually disables all 
> contraction, as the FMA generation doesn't know what was originally a 
> single source expression).  The default in the absence of such -std 
> options is -ffp-contract=fast (allowing contraction including between 
> different statements).

An environment variable to specify default GCC options would be very
useful. It is too easy to forget such an option.

Note: In the long term, -std=c99 or -std=c11 is better, as if one day,
GCC supports the STDC FP_CONTRACT pragma, contraction could be partly
enabled.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)