[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop

[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-13
                 CC|                            |law at redhat dot com
     Ever confirmed|0                           |1

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #0)

> Note that gcc-4.3 initializes summation variable to zero, where gcc-4.2
> initializes summation variable to first array member, saving one loop
> iteration.

Reconfirmed on 4.9.

I'm adding Jeff to CC for his opinon on Andrew's "jump threading used to mess
up the loop" observation from comment #1.
>From gcc-bugs-return-437473-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 13 09:24:22 2013
Return-Path: <gcc-bugs-return-437473-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26287 invoked by alias); 13 Dec 2013 09:24:22 -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 26255 invoked by uid 55); 13 Dec 2013 09:24:19 -0000
From: "ktietz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
Date: Fri, 13 Dec 2013 09:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktietz at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57897-4-2FnIV4UA9J@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57897-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57897-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: 2013-12/txt/msg01128.txt.bz2
Content-length: 504

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW897

--- Comment #11 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Author: ktietz
Date: Fri Dec 13 09:24:16 2013
New Revision: 205957

URL: http://gcc.gnu.org/viewcvs?rev 5957&root=gcc&view=rev
Log:
       PR c++/57897
       * config/i386/i386.c (ix86_option_override_internal): Set for
       x64 target flag_unwind_tables, if flag_asynchronous_unwind_tables
       was explicit set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
Andrew, no.

4.2 didn't muck things up at all.  The 4.2 code is clearly better (unless
you're vectorizing the loop).

What's happening is the IV code changes the loop structure enough that
VRP2/DOM2 are unable to peel the iteration off the loop.  

In gcc-4.2, just prior to VRP2 we have:
  # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

 # BLOCK 3 freq:10000
  # PRED: 3 [90.0%]  (dfs_back,true,exec) 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_3 = PHI <ivtmp.43_5(3), 0(2)>;
  # val_16 = PHI <val_11(3), 0(2)>;
<L0>:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto <L0>; else goto <L2>;
  # SUCC: 3 [90.0%]  (dfs_back,true,exec) 4 [10.0%]  (loop_exit,false,exec)


VRP threads the jump through the backedge for the first iteration of the loop
resulting in:
 # BLOCK 2 freq:1000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  goto <bb 5> (<L8>);
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:9000
  # PRED: 5 [100.0%]  (fallthru) 3 [88.9%]  (true,exec)
  # ivtmp.43_3 = PHI <ivtmp.43_23(5), ivtmp.43_5(3)>;
  # val_16 = PHI <val_22(5), val_11(3)>;
<L0>:;
  D.1880_7 = MEM[symbol: table, index: ivtmp.43_3]{table[i]};
  D.1881_8 = (unsigned char) D.1880_7;
  val.1_9 = (unsigned char) val_16;
  D.1883_10 = val.1_9 + D.1881_8;
  val_11 = (char) D.1883_10;
  ivtmp.43_5 = ivtmp.43_3 + 1;
  if (ivtmp.43_5 != 10) goto <L0>; else goto <L2>;
  # SUCC: 3 [88.9%]  (true,exec) 4 [11.1%]  (loop_exit,false,exec)

  # BLOCK 4 freq:1000
  # PRED: 3 [11.1%]  (loop_exit,false,exec)
  # val_2 = PHI <val_11(3)>;
<L2>:;
  D.1884_13 = (int) val_2;
  return D.1884_13;
  # SUCC: EXIT [100.0%]

  # BLOCK 5 freq:1000
  # PRED: 2 [100.0%]  (fallthru,exec)
  # ivtmp.43_17 = PHI <0(2)>;
  # val_1 = PHI <0(2)>;
<L8>:;
  D.1880_18 = MEM[symbol: table, index: ivtmp.43_17]{table[i]};
  D.1881_19 = (unsigned char) D.1880_18;
  val.1_20 = (unsigned char) val_1;
  D.1883_21 = val.1_20 + D.1881_19;
  val_22 = (char) D.1883_21;
  ivtmp.43_23 = ivtmp.43_17 + 1;
  goto <bb 3> (<L0>);
  # SUCC: 3 [100.0%]  (fallthru)

Which will ultimately compile down to the efficient code where the first
iteration has been peeled off.

If we look at the trunk, DOM2/VRP2 have had the order changed, so if we look at
the code immediately prior to DOM2 we have:

 <bb 2>:
  ivtmp.10_16 = (unsigned long) &table;
  _12 = (unsigned long) &MEM[(void *)&table + 10B];
  goto <bb 4>;

  <bb 3>:

  <bb 4>:
  # val_14 = PHI <val_8(3), 0(2)>
  # ivtmp.10_18 = PHI <ivtmp.10_17(3), ivtmp.10_16(2)>
  _13 = (void *) ivtmp.10_18;
  _4 = MEM[base: _13, offset: 0B];
  _5 = (unsigned char) _4;
  val.0_6 = (unsigned char) val_14;
  _7 = _5 + val.0_6;
  val_8 = (char) _7;
  ivtmp.10_17 = ivtmp.10_18 + 1;
  if (ivtmp.10_17 != _12)
    goto <bb 3>;
  else
    goto <bb 5>;

Note how the test to go back to the top of the loop has changed.  It's no
longer testing a simple integer counter, which threading handled nicely. 
Instead it's a more complex test involving two objects.  And neither DOM2 nor
VRP2 are able to untangle it to get the code we want.

ISTM this  should have a regression marker and attached to the jump threading
meta-bug.  



_

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.4
>From gcc-bugs-return-437761-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 18:41:17 2013
Return-Path: <gcc-bugs-return-437761-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14534 invoked by alias); 16 Dec 2013 18:41:17 -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 14501 invoked by uid 55); 16 Dec 2013 18:41:14 -0000
From: "tejohnson at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/59527] [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build
Date: Mon, 16 Dec 2013 18:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tejohnson at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59527-4-iiko3tHlpk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59527-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59527-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01416.txt.bz2
Content-length: 1185

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527

--- Comment #2 from Teresa Johnson <tejohnson at google dot com> ---
I will take a look and report back. -freorder-blocks-and-partition was
recently enabled by default, which presumably exposed this issue.
Thanks,
Teresa

On Mon, Dec 16, 2013 at 8:21 AM, octoploid at yandex dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
>
> --- Comment #1 from Markus Trippelsdorf <octoploid at yandex dot com> ---
> Created attachment 31447
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31447&action=edit
> unreduced testcase
>
>  % g++ -w -r -nostdlib -fprofile-use -fprofile-correction -march=amdfam10
> -fno-exceptions -std=gnu++0x -O3 test.ii
> In file included from /var/tmp/moz-build-dir/js/src/Unified_cpp_9.cpp:101:0:
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp: In member function
> ‘js::ScriptFrameIter& js::ScriptFrameIter::operator++()’:
> /var/tmp/mozilla-central/js/src/vm/Stack.cpp:717:1: internal compiler error: in
> fixup_reorder_chain, at cfgrtl.c:3739
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>From gcc-bugs-return-437762-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 18:55:55 2013
Return-Path: <gcc-bugs-return-437762-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24505 invoked by alias); 16 Dec 2013 18:55:55 -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 24460 invoked by uid 48); 16 Dec 2013 18:55:52 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
Date: Mon, 16 Dec 2013 18:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59436-4-0CNv8dGvkJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59436-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59436-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: 2013-12/txt/msg01417.txt.bz2
Content-length: 296

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY436

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #11)
> It is PCH related. Stage1 and stage2 cc1plus can compile the same input.
> But stage3 cc1plus fails.

It is very sensitive PCH load address.

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
The tree-ssa-threadupdate.c code seems to want to avoid threading to an empty
loop latch block.  No reason other than it was "useless" was given.  But that's
clearly wrong.  We can easily have a loop where the header branches to either
an empty latch block or to a point outside the loop.  Threading from outside
the loop to the empty latch effectively peels an iteration from the loop.  I
think this was just an oversight from Zdenek when he revamped the code in the
tree-ssa-threadupdate to try and keep the loop structures up-to-date.

Given that we allow threading to non-empty loop latches, threading to an empty
loop latch should "just work".  And fixing that appears to address this
testcase.  Testing in progress overnight.

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|19794                       |

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
So "useless" really means threading from outside to an empty latch means the
entire loop is being peeled.

Reviewing the discussions between Zdenek, Dorit and myself, it was Zdenek's
contention that threading should never peel loops, leaving that to another
pass.  The code to not thread to an empty latch block is a heuristic to avoid
peeling.

What I don't get is why we don't use changes in the loop structure to identify
cases where we're peeling a loop rather than threading to an exit edge (which
we certainly want to allow).  Perhaps there wasn't enough infrastructure for
that in place in 2005..

Regardless of that, it looks like Zdenek's goal was to avoid peeling in DOM and
instead leave that to other passes which can make better estimates about
whether or not peeling is useful.  I'm not 100% convinced that's the best thing
to do, but I don't think it's something we can/should revisit during stage3.

I'm removing this from the jump threading tracker as after reviewing the old
discussion, the threader is roughly doing what it's supposed to do.

Not sure how to best address the PR since this is a case where peeling is
actually quite cheap -- we don't have a good way to estimate when the
duplicated code from peeling for the most part just optimizes away, as it does
in this testcase.

[Bug tree-optimization/34723] [4.7/4.8/4.9 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Priority|P3                          |P2

[Bug tree-optimization/34723] [4.7/4.8/4.9/4.10 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug tree-optimization/34723] [4.8/4.9/5 Regression] Summing variable should be initialized to the first member before the loop

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

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

[Bug tree-optimization/34723] [4.8/4.9/5/6 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug tree-optimization/34723] [4.9/5/6 Regression] Summing variable should be initialized to the first member before the loop

[jakub at gcc dot gnu.org]

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

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

[Bug tree-optimization/34723] [4.9/5/6 Regression] Summing variable should be initialized to the first member before the loop

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug tree-optimization/34723] [9/10/11/12 Regression] Summing variable should be initialized to the first member before the loop

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/34723] [9/10/11/12 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/34723] [9/10/11/12 Regression] Summing variable should be initialized to the first member before the loop

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note GCC 10+ autovectorizes the loop to (which is better than clang, which
produces a lot of shuffles):
        movq    xmm0, QWORD PTR table[rip]
        pxor    xmm1, xmm1
        movdqa  xmm2, xmm0
        psadbw  xmm2, xmm1
        movq    rax, xmm2
        add     al, BYTE PTR table[rip+8]
        add     al, BYTE PTR table[rip+9]
        movsx   eax, al
        ret

[Bug tree-optimization/34723] [10/11/12/13 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/34723] [10/11/12/13 Regression] Summing variable should be initialized to the first member before the loop

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/34723] [11/12/13/14 Regression] Summing variable should be initialized to the first member before the loop

[rguenth at gcc dot gnu.org]

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

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

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

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