[Bug tree-optimization/39612] [4.3/4.4/4.5/4.6 Regression] LIM inserts loads from uninitialized local memory

[Bug tree-optimization/39612] [4.3/4.4/4.5/4.6 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.5                       |4.4.6

[Bug tree-optimization/39612] [4.3/4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.6                       |4.4.7

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.7.0

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-16 13:28:56 UTC ---
Re-confirmed on trunk with the testcase in comment #4 and -Os:

> ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
t.c: In function 'f2':
t.c:4:11: warning: 'inter[0]' is used uninitialized in this function
[-Wuninitialized]
t.c:4:11: warning: 'inter[1]' is used uninitialized in this function
[-Wuninitialized]

There is also a store data-race introduced by LIM when the loop header
is not copied.  I suppose the real fix is to disable SM if the loop
header is not copied.

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rakdver at gcc dot gnu.org]

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

--- Comment #12 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-16 16:25:05 UTC ---
(In reply to comment #11)
> Re-confirmed on trunk with the testcase in comment #4 and -Os:
> 
> > ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
> t.c: In function 'f2':
> t.c:4:11: warning: 'inter[0]' is used uninitialized in this function
> [-Wuninitialized]
> t.c:4:11: warning: 'inter[1]' is used uninitialized in this function
> [-Wuninitialized]
> 
> There is also a store data-race introduced by LIM when the loop header
> is not copied.  I suppose the real fix is to disable SM if the loop
> header is not copied.

I do not think this is the right way.  Disabling a valid (and fairly important)
optimization in order to silence a warning seems a bit extreme. I am not sure
what you mean by "a store data-race".

Also, the warning is at least morally right.  If R <= 1, the original code will
pass inter to foo uninitialized, which probably is not intended.  So, the right
thing to do could be issuing "may be used uninitialized" warning instead of "is
used uninitialized" one.

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-17 10:01:04 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > Re-confirmed on trunk with the testcase in comment #4 and -Os:
> > 
> > > ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
> > t.c: In function 'f2':
> > t.c:4:11: warning: 'inter[0]' is used uninitialized in this function
> > [-Wuninitialized]
> > t.c:4:11: warning: 'inter[1]' is used uninitialized in this function
> > [-Wuninitialized]
> > 
> > There is also a store data-race introduced by LIM when the loop header
> > is not copied.  I suppose the real fix is to disable SM if the loop
> > header is not copied.
> 
> I do not think this is the right way.  Disabling a valid (and fairly important)
> optimization in order to silence a warning seems a bit extreme. I am not sure
> what you mean by "a store data-race".
>
> Also, the warning is at least morally right.  If R <= 1, the original code will
> pass inter to foo uninitialized, which probably is not intended.  So, the right
> thing to do could be issuing "may be used uninitialized" warning instead of "is
> used uninitialized" one.

Yes, but the point is that without the loop header copy we insert the
loads and stores from/to inter in a path that is executed even when
R <= 1 and thus the loop is not executed at all, and we warn about
the inserted loads - not about the final one.  Modified testcase:

void foo (int *);
void
f2 (int R)
{
  int i, inter[3];

  for (i = 1; i < R; i++)
    {
      inter[0] = 1;
      inter[1] = 1;
      inter[2] = 1;
    }

  foo (inter);
}

For the store data-race consider

int inter[3];
void
f2 (int R)
{
  int i;

  for (i = 1; i < R; i++)
    {
      inter[0] = 1;
      inter[1] = 1;
      inter[2] = 1;
    }
}

where inter is protected by a mutex, but only if R > 1.  We still
insert loads/stores on paths that are executed when the loop is not
entered:

f2 (int R)
{
  int inter_I_lsm.5;
  int inter_I_lsm.4;
  int inter_I_lsm.3;
  int i;

<bb 2>:
  inter_I_lsm.3_10 = inter[0];
  inter_I_lsm.4_11 = inter[1];
  inter_I_lsm.5_12 = inter[2];
  goto <bb 4>;

<bb 3>:
  inter_I_lsm.3_13 = 1;
  inter_I_lsm.4_14 = 1;
  inter_I_lsm.5_15 = 1;
  i_4 = i_1 + 1;

<bb 4>:
  # i_1 = PHI <1(2), i_4(3)>
  # inter_I_lsm.3_9 = PHI <inter_I_lsm.3_10(2), inter_I_lsm.3_13(3)>
  # inter_I_lsm.4_8 = PHI <inter_I_lsm.4_11(2), inter_I_lsm.4_14(3)>
  # inter_I_lsm.5_7 = PHI <inter_I_lsm.5_12(2), inter_I_lsm.5_15(3)>
  if (i_1 < R_3(D))
    goto <bb 3>;
  else
    goto <bb 5>;

<bb 5>:
  # inter_I_lsm.5_19 = PHI <inter_I_lsm.5_7(4)>
  # inter_I_lsm.4_20 = PHI <inter_I_lsm.4_8(4)>
  # inter_I_lsm.3_21 = PHI <inter_I_lsm.3_9(4)>
  inter[0] = inter_I_lsm.3_21;
  inter[1] = inter_I_lsm.4_20;
  inter[2] = inter_I_lsm.5_19;
  return;
}

The issue is mitigated by loop-header copying because we there have a suitable
insertion place that is only executed when the loop body is executed (we seem
to cater for not inserting possibly trapping insns that way but do not
consider data-races possible for global memory).

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rakdver at gcc dot gnu.org]

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

--- Comment #14 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17 10:19:01 UTC ---
> > Also, the warning is at least morally right.  If R <= 1, the original code will
> > pass inter to foo uninitialized, which probably is not intended.  So, the right
> > thing to do could be issuing "may be used uninitialized" warning instead of "is
> > used uninitialized" one.
> 
> Yes, but the point is that without the loop header copy we insert the
> loads and stores from/to inter in a path that is executed even when
> R <= 1 and thus the loop is not executed at all, and we warn about
> the inserted loads - not about the final one.  Modified testcase:

I realize that; making the warning to point to the right line would be somewhat
difficult, I guess.

> For the store data-race consider
> 
> int inter[3];
> void
> f2 (int R)
> {
>   int i;
> 
>   for (i = 1; i < R; i++)
>     {
>       inter[0] = 1;
>       inter[1] = 1;
>       inter[2] = 1;
>     }
> }
> 
> where inter is protected by a mutex, but only if R > 1.  We still
> insert loads/stores on paths that are executed when the loop is not
> entered:

Which is to be expected, as long as inter is not volatile.  Store motion (and
cse, ...) will cause this kind of problems, this does not seem to be anything
specific to the testcase in question.  If you have something like

  for (i = 1; i < R; i++)
    {
       lock ();
       do something with inter[1]
       unlock ();
    }

LSM will move inter[1] to a temporary variable regardless of the locks, which
will cause race conditions with other threads (and whether loop header is
copied or not is irrelevant).

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-17 10:39:56 UTC ---
We have the C++11 memory model which (if asked for it through command line
options) will restrict what data races we may or may not introduce during
optimizations.

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-17 10:40:31 UTC ---
On Tue, 17 Jan 2012, rakdver at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
> 
> --- Comment #14 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17 10:19:01 UTC ---
> > > Also, the warning is at least morally right.  If R <= 1, the original code will
> > > pass inter to foo uninitialized, which probably is not intended.  So, the right
> > > thing to do could be issuing "may be used uninitialized" warning instead of "is
> > > used uninitialized" one.
> > 
> > Yes, but the point is that without the loop header copy we insert the
> > loads and stores from/to inter in a path that is executed even when
> > R <= 1 and thus the loop is not executed at all, and we warn about
> > the inserted loads - not about the final one.  Modified testcase:
> 
> I realize that; making the warning to point to the right line would be somewhat
> difficult, I guess.

Yeah.

> > For the store data-race consider
> > 
> > int inter[3];
> > void
> > f2 (int R)
> > {
> >   int i;
> > 
> >   for (i = 1; i < R; i++)
> >     {
> >       inter[0] = 1;
> >       inter[1] = 1;
> >       inter[2] = 1;
> >     }
> > }
> > 
> > where inter is protected by a mutex, but only if R > 1.  We still
> > insert loads/stores on paths that are executed when the loop is not
> > entered:
> 
> Which is to be expected, as long as inter is not volatile.  Store motion (and
> cse, ...) will cause this kind of problems, this does not seem to be anything
> specific to the testcase in question.  If you have something like
> 
>   for (i = 1; i < R; i++)
>     {
>        lock ();
>        do something with inter[1]
>        unlock ();
>     }
> 
> LSM will move inter[1] to a temporary variable regardless of the locks, which
> will cause race conditions with other threads (and whether loop header is
> copied or not is irrelevant).

I think for the explicit lock code we are safe because we consider
the lock/unlock calls to alias inter[] so we cannot SM it.  In the
light of the C++11 memory model we probably have to do something
about even non-volatile accesses.

I suppose we cannot easily detect at the moment if the loop has
its header copied, thus, is do {} while style?  We're using
ref_always_accessed_p for the trapping insns issue, we could
extend that to cover all global memory accesses - but I suppose
that would pessimize things if ref_always_accessed_p isn't
very good.

[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

[rakdver at gcc dot gnu.org]

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

--- Comment #17 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17 11:01:45 UTC ---
> > LSM will move inter[1] to a temporary variable regardless of the locks, which
> > will cause race conditions with other threads (and whether loop header is
> > copied or not is irrelevant).
> 
> I think for the explicit lock code we are safe because we consider
> the lock/unlock calls to alias inter[] so we cannot SM it.  

This is not necessary to be the case, if you for some reason implement your own
version of locking (and especially if lock/unlock get inlined).  Still, this
probably would not happen in practice.

> In the
> light of the C++11 memory model we probably have to do something
> about even non-volatile accesses.
> 
> I suppose we cannot easily detect at the moment if the loop has
> its header copied, thus, is do {} while style?  We're using
> ref_always_accessed_p for the trapping insns issue, we could
> extend that to cover all global memory accesses - but I suppose
> that would pessimize things if ref_always_accessed_p isn't
> very good.

Having header copied or not is actually irrelevant for the problem in question.
 You will get the same thing in

do
  {
    if (maybe)
      inter[1] = bla;
  }
while (something);

So, extending the use of ref_always_accessed_p would be the thing you want to
do; probably not by default, since this only affects badly written (no
volatile) multithreaded programs, but having that option could be useful
(of course, this should be on by default for c++, if it is the required
behavior).

[Bug tree-optimization/39612] [4.5/4.6/4.7/4.8 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:45:30 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug tree-optimization/39612] [4.5/4.6/4.7/4.8 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 11:28:17 UTC ---
The 4.5 branch is being closed, adjusting target milestone.

[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:16:03 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 32371
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32371&action=edit
Fix

[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine, but not for 4.9.

[Bug tree-optimization/39612] [4.7/4.8/4.9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
The fix uses the store-data-race avoiding path which keeps a flag per moved
mem-ref whether it was stored to.  With that I can avoid loading from the ref
before the loop if there are no loads in the loop itself.  But it reveals
that we possibly use too many flags (we don't try combining them - some
simple analysis should be able to improve that).

[Bug tree-optimization/39612] [4.7/4.8/4.9/4.10 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #24 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/39612] [4.8/4.9/4.10 Regression] LIM inserts loads from uninitialized local memory

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Bug 39612 depends on bug 61607, which changed state.

Bug 61607 Summary: DOM missed jump threading and destroyed loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

[Bug tree-optimization/39612] [4.8/4.9/5 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/39612] [4.8/4.9/5/6 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #26 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/39612] [4.9/5/6 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

[Bug tree-optimization/39612] [4.9/5/6 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

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

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eww.  Fixing the missed optimization causes tons of maybe-uninit warnings.
That was probably to be expected since we're introducing undefs on the loop
entry edge and conditional uses.  We eventually should mark the conditional
stores on the exits with no-warning...

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48420&action=edit
patch

Tested on x86_64-unknown-linux-gnu, queued for GCC 11.  Note it does not
(and cannot) fix the case for where we have a conditionally executed load
only - we still emit an unconditional load in the preheader then.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[cvs-commit at gcc dot gnu.org]

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

--- Comment #39 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:f9e1ea10e657af9fb02fafecf1a600740fd34409

commit r11-39-gf9e1ea10e657af9fb02fafecf1a600740fd34409
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Apr 30 10:47:15 2020 +0200

    tree-optimization/39612 - avoid issueing loads in SM when possible

    Currently store-motion emits a load of the value in the loop
    preheader even when the original loop does not contain any read
    of the reference.  This avoids doing this.  In the conditional
    store-motion case we need to mark the sunk stores with no-warning
    since the control dependence is too tricky to figure out for
    the uninit warning.

    2020-05-04  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/39612
            * tree-ssa-loop-im.c (im_mem_ref::loaded): New member.
            (set_ref_loaded_in_loop): New.
            (mark_ref_loaded): Likewise.
            (gather_mem_refs_stmt): Call mark_ref_loaded for loads.
            (execute_sm): Avoid issueing a load when it was not there.
            (execute_sm_if_changed): Avoid issueing warnings for the
            conditional store.

            * gcc.dg/tree-ssa/pr39612.c: New testcase.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #40 from Richard Biener <rguenth at gcc dot gnu.org> ---
And the missed optimization is now fixed as much as possible.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #41 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Hi Richi,

This patch f9e1ea10e657 seems to be causing miscompares in the GCC benchmark in
SPEC2017.

I haven't tried to produce a reproducer yet but could if that's needed.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenther at suse dot de]

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

--- Comment #42 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 5 May 2020, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
> 
> Tamar Christina <tnfchris at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |tnfchris at gcc dot gnu.org
> 
> --- Comment #41 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> Hi Richi,
> 
> This patch f9e1ea10e657 seems to be causing miscompares in the GCC benchmark in
> SPEC2017.
> 
> I haven't tried to produce a reproducer yet but could if that's needed.

PR94949 (already fixed)

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[tnfchris at gcc dot gnu.org]

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

--- Comment #43 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Oh, that was quick, thanks! I was looking at the log for another commit against
this PR so missed it :)

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[joseph at codesourcery dot com]

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

--- Comment #44 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
This commit also introduces bug 94963 which breaks the glibc build (and is 
*not* fixed by the commit that fixed bug 94949).

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |MF21330112 at smail dot nju.edu.cn

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105341 has been marked as a duplicate of this bug. ***