[Bug tree-optimization/91756] New: [10 regression] g++.dg/lto/alias-3 FAILs

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] New: [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

            Bug ID: 91756
           Summary: [10 regression] g++.dg/lto/alias-3 FAILs
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
            Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

Between 20190910 (r275594) and 20190911 (r275651), g++.dg/lto/alias-3 regressed
on both Solaris/SPARC and Solaris/x86:

+FAIL: g++.dg/lto/alias-3 cp_lto_alias-3_0.o-cp_lto_alias-3_1.o execute  -O3
-flto -fno-early-inlining

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfe289715 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfe289715 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfe281fbf in thr_kill () from /lib/libc.so.1
#2  0xfe1c92fa in raise () from /lib/libc.so.1
#3  0xfe19b29e in abort () from /lib/libc.so.1
#4  0x08050e29 in main ()
    at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/alias-3_0.C:27

A reghunt identified the following patch as the culprit:

2019-09-11  Richard Biener  <[hidden email]>

        PR tree-optimization/90387
        * vr-values.c (vr_values::extract_range_basic): After inlining
        simplify non-constant __builtin_constant_p to false.

        * gcc.dg/Warray-bounds-44.c: New testcase.
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.0
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-09-13
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It works fine on x86_64-linux with {,-m32} but fails with
-fno-use-linker-plugin.
This causes the global vars to not resolve to constants.  With -fno-tree-vrp
it passes because DOM optimizes the bptr2->a[ij].bar load.  FRE misses this
for some reason, I'll investigate why.
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The disambiguation needs "translation" (vn_reference_lookup_3 using the
original
ref for path-based disambiguation), but we do not allow this when looking
across backedges in the maybe_skip_until walk and the loop we have to cross
in alias disambiguation looks like

 do
   {
      if (n <= i)
        break;
      ptr->a[i].foo = 1; // this stmt to disambiguate against
   }
 while (1);

but then DOM is happy with this structure because it valueizes in the IL
itself.  So the guard against backedges must be too conservative since
DOM also walks across them.  I've added this as fix for PR87132.
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Sep 16 11:58:35 2019
New Revision: 275747

URL: https://gcc.gnu.org/viewcvs?rev=275747&root=gcc&view=rev
Log:
2019-09-16  Richard Biener  <[hidden email]>

        PR tree-optimization/91756
        PR tree-optimization/87132
        * tree-ssa-alias.h (enum translate_flags): New.
        (get_continuation_for_phi): Use it instead of simple bool flag.
        (walk_non_aliased_vuses): Likewise.
        * tree-ssa-alias.c (maybe_skip_until): Adjust.
        (get_continuation_for_phi): When looking across backedges only
        disallow valueization.
        (walk_non_aliased_vuses): Adjust.
        * tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid valueization
        if requested.

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

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-81.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-alias.c
    trunk/gcc/tree-ssa-alias.h
    trunk/gcc/tree-ssa-sccvn.c
Reply | Threaded
Open this post in threaded view
|

[Bug tree-optimization/91756] [10 regression] g++.dg/lto/alias-3 FAILs

marxin at gcc dot gnu.org
In reply to this post by marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91756

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.