On Fri, 8 Nov 2019, Bill Schmidt wrote:
> On 11/7/19 5:48 AM, Matthias Klose wrote:
> > On 05.11.19 13:45, Richard Biener wrote:
> >>
> >> The first release candidate for GCC 7.5 is available from
> >>
> >> https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
> >>
> >> and shortly its mirrors. It has been generated from SVN revision 277823.
> >>
> >> I have so far bootstrapped and tested the release candidate on
> >> {x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
> >> and report any issues to bugzilla.
> >>
> >> If all goes well, I'd like to release 7.5 on Thursday, November 14th.
> >
> > With a distribution build (Ubuntu) on amd64, i386, armhf, arm64, ppc64el and
> > s390x, I don't see any regressions in the GCC testsuite (compared to 7.4.0),
> > except for two issues on ppc64el:
> >
> > FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
> > Excess errors:
> > /build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
> > warning: format '%d' expects argument of type 'int', but argument 2 has type
> > 'size_t {aka long unsigned int}' [-Wformat=]
> >
> > is a new test, and only caused by default hardening settings.
> >
> > PASS: gcc.dg/vect/slp-perm-4.c execution test
> > FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1
> > loops" 1
> > PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps requires
> > scalar epilogue loop" 0
> > FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
> > stmts using SLP" 1
>
>
> I finally bisected this to r275208:
>
>
> 2019-08-30 Richard Biener <rguent...@suse.de <mailto:rguenther%40suse.de>>
>
> Backport from mainline
> 2019-05-27 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR tree-optimization/90637
> * tree-ssa-sink.c (statement_sink_location): Honor the
> computed sink location for single-uses.
>
> * gcc.dg/gomp/pr90637.c: New testcase.
>
> 2019-06-21 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR tree-optimization/90930
> * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
> flag on new stmts to avoid re-processing them.
>
> 2019-05-15 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR c/90474
> * c-common.c (c_common_mark_addressable_vec): Also mark
> a COMPOUND_LITERAL_EXPR_DECL addressable similar to
> c_mark_addressable.
>
> 2019-04-25 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR middle-end/90194
> * match.pd: Add pattern to simplify view-conversion of an
> empty constructor.
>
> * g++.dg/torture/pr90194.C: New testcase.
>
> 2019-04-24 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR middle-end/90213
> * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
> by size and BITS_PER_UNIT on poly-wide-ints.
>
> 2019-04-15 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR tree-optimization/90071
> * tree-ssa-reassoc.c (init_range_entry): Do not pick up
> abnormal operands from def stmts.
>
> * gcc.dg/torture/pr90071.c: New testcase.
>
> 2019-03-13 Richard Biener <rguent...@suse.de
> <mailto:rguenther%40suse.de>>
>
> PR middle-end/89677
> * tree-scalar-evolution.c (simplify_peeled_chrec): Do not
> throw FP expressions at tree-affine.
>
> * gcc.dg/torture/pr89677.c: New testcase.
>
>
> This looks rather familiar, actually. I seem to recall an SLP degradation
> from a change to tree-ssa-sink.c on trunk this release. Richi, could there be
> a missing backport here?
Not sure - it's reassoc that messes up things here and a
--param tree-reassoc-width=1 "fixes" the failure. For PR90930 I
restricted this to the last pass instance (but only on trunk).
Does it also fail on the GCC 8 and 9 branches? Ah, on GCC 8 at least
the default target setting for this seems to be 1 (it's non-FP,
maybe you changed that), with explicit --param tree-reassoc-width={2,3,4}
it also fails the same way.
It's a bit late to try thinking about backporting this change
but I'll now consider it for GCC 9 at least.
So IMHO a latent issue, somehow the rev. triggered "inconsistent"
reassoc for the testcase. I'm going to leave it as-is for GCC 7.5
(with the testsuite regression).
Are you fine with that? An explicit --param tree-reassoc-width=1
on the testcase also would work for me if you prefer that.
Thanks,
Richard.
