[Bug middle-end/64099] New: [5 Regression] ~15% runtime increase for fatigue.f90.

[Bug middle-end/64099] New: [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

            Bug ID: 64099
           Summary: [5 Regression] ~15% runtime increase for fatigue.f90.
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: hubicka at ucw dot cz, rguenth at gcc dot gnu.org

On x86_64-apple-darwin14, I see a ~15% runtime increase for the polyhedron test
fatigue.f90 on the current trunk (r218134). It is split in two steps. The first
one occurred between r216631 and r216747:

[Book15] lin/test% /opt/gcc/gcc4.10p-216631p3/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.373u 0.001s 0:01.37 100.0%    0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216747p2/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null                                      
                                                                    1.462u
0.002s 0:01.47 99.3%    0+0k 0+1io 40pf+0w

The second one occurred between r217816 and r217833:

[Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null                                      
                                                                    1.435u
0.002s 0:01.44 99.3%    0+0k 0+2io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null                                      
                                                                    1.582u
0.001s 0:01.58 100.0%    0+0k 0+1io 0pf+0w

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-apple-darwin14
   Target Milestone|---                         |5.0

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-11-28
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I don't see this on any of our testers.  What CPU do you have and what default
-march gets used for you?  (thus please show -v output)

Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
is enough.  Does -ftree-loop-linear make a difference for you?

Our testers use -ffast-math -funroll-loops -O3.

Can you bisect the regressions to a single commit?

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #2)
> > I don't see this on any of our testers.  What CPU do you have and what default
> > -march gets used for you?  (thus please show -v output)
> 
> My CPU is a 2.8 GHz Intel Core i7. All the versions reported in comment 0
> have been configured with
> 
> ../p_work/configure --prefix=/opt/gcc/gcc4.10p-#rev.p#patch
> --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
> --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
> --enable-plugin --with-arch=core2 --with-cpu=core2

Ok, so it is -march=core2

> but r216631 for which --enable-checking=release has been omitted. #rev. is
> the revision and #patch is the number of patches required to bootstrap.
> 
> > Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
> > is enough.  
> 
> I know, however I have seen in the past some regressions when -flto is
> added. Since I can afford to double the compile time, I keep it in my
> reference options.
> 
> > Does -ftree-loop-linear make a difference for you?
> 
> AFAICT it does not on fatigue.f90, but I see some (minor) improvements for
> other tests in the suite.
> 
> > Our testers use -ffast-math -funroll-loops -O3.
> 
> Using '-O3 -ffast-math' instead of '-Ofast' almost double the runtime:

Ugh - -Ofast is an alias for -O3 -ffast-math.  Ah, no - it also enables
--param allow-store-data-races=1 ...

> [Book15] lin/test% gfortran -O3 -ffast-math -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.648u 0.002s 0:02.65 99.6%	0+0k 0+3io 38pf+0w
> [Book15] lin/test% gfortran -Ofast -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 1.385u 0.002s 0:01.38 100.0%	0+0k 0+1io 0pf+0w
> [Book15] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.952u 0.002s 0:02.96 99.6%	0+0k 0+0io 40pf+0w
> [Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 1.643u 0.001s 0:01.64 100.0%	0+0k 0+1io 0pf+0w
> 
> (gfortran is 4.9.2 and gfc is 5.0 r218134).
> 
> The runtime increase with '-O3 -ffast-math' is ~0.4s between r217816 and
> r217833
> 
> [Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -O3 -ffast-math
> -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.654u 0.002s 0:02.66 99.6%	0+0k 0+1io 41pf+0w
> [Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -O3 -ffast-math
> -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.962u 0.001s 0:02.97 99.6%	0+0k 0+1io 39pf+0w
> 
> > Can you bisect the regressions to a single commit?
> 
> I can do it for the range r217816-r217833 (the candidates are r217824 and
> r217827, may be r217828 also). As indicated by the p? in my coding scheme, I
> cannot bootstrap in the range r216631-r216747 without at least two patches,
> so bisecting this range will take much longer.
>From gcc-bugs-return-468844-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 28 13:22:20 2014
Return-Path: <gcc-bugs-return-468844-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18691 invoked by alias); 28 Nov 2014 13:22:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18648 invoked by uid 48); 28 Nov 2014 13:22:15 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.
Date: Fri, 28 Nov 2014 13:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64099-4-r6pSvdDo2y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64099-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64099-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg03316.txt.bz2
Content-length: 555

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd099

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Ugh - -Ofast is an alias for -O3 -ffast-math.  Ah, no - it also enables
> --param allow-store-data-races=1 ...

-Ofast
Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It
also enables optimizations that are not valid for all standard-compliant
programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens
and -fstack-arrays.

My guess is that -fstack-arrays makes the difference.

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> My guess is that -fstack-arrays makes the difference.

Confirmed:

[Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90 -fno-stack-arrays
[Book15] lin/test% time a.out > /dev/null
2.982u 0.001s 0:02.98 100.0%    0+0k 0+1io 0pf+0w

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The second runtime increase (with '-Ofast', the only one with '-O3
-ffast-math') is due to r217827

[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
[Book15] lin/test% time a.out > /dev/null
1.498u 0.001s 0:01.49 100.0%    0+0k 0+1io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.622u 0.001s 0:01.62 100.0%    0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.663u 0.002s 0:02.66 100.0%    0+0k 0+2io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.964u 0.001s 0:02.96 100.0%    0+0k 0+1io 0pf+0w

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The first runtime increase (with '-Ofast') is due to r216728:

[Book15] lin/test% /opt/gcc/gcc4.10p-216727p2/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.380u 0.001s 0:01.38 100.0%    0+0k 0+1io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216728p2/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.500u 0.001s 0:01.50 100.0%    0+0k 0+2io 0pf+0w

I also confirm it for the test fatigue2.f90 of the pb11 test suite:

[Book15] lin/test% /opt/gcc/gcc4.10p-216727p2/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
28.473u 0.005s 0:28.48 99.9%    0+0k 0+3io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216728p2/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
30.699u 0.006s 0:30.71 99.9%    0+0k 0+1io 40pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
30.840u 0.006s 0:30.84 100.0%    0+0k 0+4io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
33.387u 0.005s 0:33.39 99.9%    0+0k 0+2io 0pf+0w

[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
54.750u 0.013s 0:54.77 99.9%    0+0k 0+6io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
62.117u 0.039s 1:02.18 99.9%    0+0k 1+6io 53pf+0w

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can confirm a regression of ~7% vs. 4.9 with -Ofast -fwhole-program on
x86_64-linux (otherwise default -march/tune).  perf isn't too useful
(everything is inlined into MAIN__ it seems).

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
For r217826 vs. r217827 the assembly differences show a larger stack frame
while the optimized dump differences are net positive (more memory CSE happens
and loads get removed - which might increase register pressure enough).

For r216727 vs. r216728 the order of functions output changes, there are no
real changes in the optimized dumps.


Both rev. changes cause operand order to be swapped for some instructions
which can, given TER, result in significant scheduling differences in
the RTL expansion.


One thing is for example that the reassoc pass produces non-canonical
operand order but its operand order might be more optimal in practice
(the canonical order is just canonicalization for commutative operands).
As we deal with single-use chains there we might consider "swapping"
SSA names (swap SSA_NAME_VERSION) to preserve its ordering over a
fold_stmt call.  No, doing that doesn't make a significant difference :/
For reference:

Index: gcc/tree-ssa-reassoc.c
===================================================================
--- gcc/tree-ssa-reassoc.c      (revision 217827)
+++ gcc/tree-ssa-reassoc.c      (working copy)
@@ -3602,6 +3602,16 @@ rewrite_expr_tree (gimple stmt, unsigned
          update_stmt (stmt);
        }

+      if (commutative_tree_code (gimple_assign_rhs_code (stmt))
+         && tree_swap_operands_p (new_rhs1, oe->op, true))
+       {
+         gcc_assert (TREE_CODE (new_rhs1) == SSA_NAME
+                     && TREE_CODE (oe->op) == SSA_NAME);
+         std::swap (SSA_NAME_VERSION (new_rhs1), SSA_NAME_VERSION (oe->op));
+         std::swap (ssa_name (SSA_NAME_VERSION (new_rhs1)),
+                    ssa_name (SSA_NAME_VERSION (oe->op)));
+       }
+
       if (dump_file && (dump_flags & TDF_DETAILS))
        {
          fprintf (dump_file, " into ");

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Now that PR64434 was fixed I wonder if fatigue is fast again.

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Now that PR64434 was fixed I wonder if fatigue is fast again.

Unfortunately no.

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at redhat dot com

[Bug middle-end/64099] [5/6 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The timing increase disappears if the code is compiled with
-fno-tree-dominator-opts.

[Bug middle-end/64099] [5/6 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 35319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35319&action=edit
Reduced version with most I/Os removed.

Run time can be tuned by changing the value of number_of_sample_points. With
the current value (50) run time is ~6s when the test is compiled with -Ofast
-fwhole-program -fno-tree-dominator-opts and ~7s without
-fno-tree-dominator-opts (2.8Ghz Core i7).

[Bug middle-end/64099] [5/6 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 35320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35320&action=edit
Reduced version with most I/Os removed and generalized_hookes_law inlined
manually.

The subroutine perdida is fully inlined when this test is compiled with -Ofast.

[Bug middle-end/64099] [5/6 Regression] ~15% runtime increase for fatigue.f90.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug middle-end/64099] [5/6 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug middle-end/64099] [9/10/11/12 Regression] ~15% runtime increase for fatigue.f90.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug middle-end/64099] [9/10/11/12 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug middle-end/64099] [10/11/12/13 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug middle-end/64099] [10/11/12/13 Regression] ~15% runtime increase for fatigue.f90.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug middle-end/64099] [11/12/13/14 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.