[Bug tree-optimization/103192] New: [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[Bug tree-optimization/103192] New: [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

            Bug ID: 103192
           Summary: [12 Regression] ICE on libgomp
                    target-in-reduction-2.{C,c}
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I see ICE when compiling these testcases in a bootstrapped compiler:
../configure --enable-languages=default,ada,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra && make -j32 bootstrap
cd x86_64-*/libgomp
make check RUNTESTFLAGS='c.exp=target-in-reduction-2.c
c++.exp=target-in-reduction-2*'
FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to produce
executable
but can't reproduce that with stage1 gcc.
The ICE is in omp_add_variable being called with NULL first argument, but the
source code has:
          omp_add_variable (ctx, decl, flags);
          if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION
               || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_IN_REDUCTION
               || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_TASK_REDUCTION)
              && OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
            {
              struct gimplify_omp_ctx *pctx
                = code == OMP_TARGET ? outer_ctx : ctx;
              if (pctx)
                omp_add_variable (pctx, OMP_CLAUSE_REDUCTION_PLACEHOLDER (c),
                                  GOVD_LOCAL | GOVD_SEEN);
                ^^^^^^^^^^^^^^^^ Inside of the above call
              if (pctx
                  && OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c)
                  && walk_tree (&OMP_CLAUSE_REDUCTION_INIT (c),
                                find_decl_expr,
                                OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c),
                                NULL) == NULL_TREE)
                omp_add_variable (pctx,
                                  OMP_CLAUSE_REDUCTION_DECL_PLACEHOLDER (c),
                                  GOVD_LOCAL | GOVD_SEEN);
outer_ctx can be NULL, ctx may not, but the source really should guarantee that
when code is OMP_TARGET (this case) and outer_ctx is NULL, then
omp_add_variable is not called.
In *.strlen1 dump I still see
  <bb 1285> [local count: 22959172]:
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => iftmp.2373_1469
  [../../gcc/gimplify.c:10069:8] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10069:8] if (iftmp.2373_1469 != 0B)
    goto <bb 1286>; [70.00%]
  else
    goto <bb 1289>; [30.00%]

  <bb 1286> [local count: 38024558]:
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10070:3] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10070:51] _761 = omp_clause_range_check (c_4680, 5, 7,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:51] _762 = omp_clause_elt_check (_761, 3,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:20] _763 = [../../gcc/gimplify.c:10070:20] *_762;
  [../../gcc/gimplify.c:10070:20] omp_add_variable (iftmp.2373_1469, _763,
129);
but in threadfull2 dump I see:
  [../../gcc/gimplify.c:10065:12] _3356 = [../../gcc/gimplify.c:10065:12]
MEM[(union tree_node * *)c_4680 + 80B];
  [../../gcc/gimplify.c:10065:8] if (_3356 != 0B)
    goto <bb 1286>; [70.00%]
  else
    goto <bb 1621>; [30.00%]
...
  <bb 1286> [local count: 38024558]:
  [../../gcc/gimplify.c:10067:8] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10067:33] # DEBUG pctx => NULL
  [../../gcc/gimplify.c:10070:3] # DEBUG BEGIN_STMT
  [../../gcc/gimplify.c:10070:51] _761 = omp_clause_range_check (c_4680, 5, 7,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:51] _762 = omp_clause_elt_check (_761, 3,
[../../gcc/gimplify.c:10070:51] "../../gcc/gimplify.c", 10070,
[../../gcc/gimplify.c:10070:51] "gimplify_scan_omp_clauses");
  [../../gcc/gimplify.c:10070:20] _763 = [../../gcc/gimplify.c:10070:20] *_762;
  [../../gcc/gimplify.c:10070:20] omp_add_variable (iftmp.2373_1469, _763,
129);
which looks like OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) check to me.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
(note, I was bisecting just the gimplify.ii dump with
-fpreprocessed gimplify.ii -quiet -dumpbase gimplify.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -g -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wsuggest-attribute=format
-Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wimplicit-fallthrough=0 -version -fno-PIE
-fchecking=1 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common
-o gimplify.s -fdump-tree-optimized-lineno
looking for line 10070 omp_add_variable call and the guarding condition.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-11
           Keywords|                            |ice-on-valid-code,
                   |                            |wrong-code

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae

Huh.  I wonder what happened.  I never saw these regressions in my testing.

Will take a look.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I can reproduce on a stage2 compiler.  I've narrowed it down to:

-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
-fdisable-tree-thread2 -fdisable-tree-thread1
-fdbg-cnt=registered_jump_thread:543-544:550-555

Which is interesting because I've disabled both thread[12] and threadfull[12]
which are the passes affected by the bisected culprit (r12-4790).

All the threads come from ethread:

$ grep Register.*jump gimplify.c.*
gimplify.c.034t.ethread:  [543] Registering jump thread: (687, 689) incoming
edge;  (689, 690) nocopy; 
gimplify.c.034t.ethread:  [544] Registering jump thread: (688, 689) incoming
edge;  (689, 693) nocopy; 
gimplify.c.034t.ethread:  [550] Registering jump thread: (776, 777) incoming
edge;  (777, 801) nocopy; 
gimplify.c.034t.ethread:  [551] Registering jump thread: (779, 780) incoming
edge;  (780, 781) nocopy; 
gimplify.c.034t.ethread:  [552] Registering jump thread: (780, 782) incoming
edge;  (782, 785) nocopy; 
gimplify.c.034t.ethread:  [553] Registering jump thread: (784, 786) incoming
edge;  (786, 787) nocopy; 
gimplify.c.034t.ethread:  [554] Registering jump thread: (785, 786) incoming
edge;  (786, 788) nocopy; 
gimplify.c.034t.ethread:  [555] Registering jump thread: (804, 806) incoming
edge;  (806, 807) nocopy; 

...which was not affected by the commit, and which is a rather simple threading
pass with no IL changes and no full resolving ranger mode.

If I disable DOM it goes away, so *maybe* these ethreads cause DOM to perform
an optimization that triggers the ICE.

Damn it.  These bugs are getting trickier and trickier.  Where are the simple 5
liners I could fix in no time flat? :)

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
On one of my machines I can see the ICE with an LTO
profiledbootstrapped compiler but neither with a normally bootstrapped
compiler nor with an LTO-bootstrapped compiler, without PGO.  I have
not yet tried with a non-LTO profiledbootstrapped one.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Hmm, all these threads look correct.  Following are my steps for verification.

In a stage2 compiler I do:

$ rm -f gimplify.o
$ make cc1 CXXFLAGS="-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
-fdisable-tree-thread2 -fdisable-tree-thread1
-fdbg-cnt=registered_jump_thread:543-543:544-544:550-550:551-551:552-552:553-553:554-554:555-555
-fdump-tree-all-details --param=threader-debug=all"
$ ./cc1 a.c -O2 -fopenmp -quiet
a.c: In function ‘foo’:
a.c:35:13: internal compiler error: Segmentation fault
...
...

This disables all the threaders except DOM and ethread.  It also splits up the
individual threaded paths for easy grepping in the source (dbgcnt.*543,
dbgcnt.*544, etc).  All of the threads are needed to reproduce.  All of them
are from ethread and belong to the gimplify_scan_omp_clauses function:

$ grep Register.*jump gimplify.c.*
gimplify.c.034t.ethread:  [543] Registering jump thread: (687, 689) incoming
edge;  (689, 690) nocopy; 
gimplify.c.034t.ethread:  [544] Registering jump thread: (688, 689) incoming
edge;  (689, 693) nocopy; 
gimplify.c.034t.ethread:  [550] Registering jump thread: (776, 777) incoming
edge;  (777, 801) nocopy; 
gimplify.c.034t.ethread:  [551] Registering jump thread: (779, 780) incoming
edge;  (780, 781) nocopy; 
gimplify.c.034t.ethread:  [552] Registering jump thread: (780, 782) incoming
edge;  (782, 785) nocopy; 
gimplify.c.034t.ethread:  [553] Registering jump thread: (784, 786) incoming
edge;  (786, 787) nocopy; 
gimplify.c.034t.ethread:  [554] Registering jump thread: (785, 786) incoming
edge;  (786, 788) nocopy; 
gimplify.c.034t.ethread:  [555] Registering jump thread: (804, 806) incoming
edge;  (806, 807) nocopy; 

All of these paths, with the exception of 551 are trivially solvable.  For
example:

The IL immediate above this...

***dbgcnt: lower limit 543 reached for registered_jump_thread.***
***dbgcnt: upper limit 543 reached for registered_jump_thread.***
  [543] Registering jump thread: (687, 689) incoming edge;  (689, 690) nocopy; 
path: 687->689->690 SUCCESS

...is the path:

    <bb 689> :
    # iftmp.2344_1598 = PHI <1(687), 0(688)>
    if (iftmp.2344_1598 != 0)
      goto <bb 690>; [INV]
    else
      goto <bb 693>; [INV]

That's an obvious thread from 687->689->690.

The rest are a similar pattern.  The only different path is:

***dbgcnt: lower limit 551 reached for registered_jump_thread.***
***dbgcnt: upper limit 551 reached for registered_jump_thread.***
  [551] Registering jump thread: (779, 780) incoming edge;  (780, 781) nocopy; 
path: 779->780->781 SUCCESS

with an IL of:

    <bb 780> :
    # iftmp.2373_1603 = PHI <outer_ctx_1871(778), ctx_1868(779)>
    if (iftmp.2373_1603 != 0B)
      goto <bb 781>; [INV]
    else
      goto <bb 782>; [INV]

but if you look at the definition of ctx_1868, it's clear it's threadable to
bb781 because ctx_1868 is known to be non-zero:

  ctx_1868 = new_omp_context (region_type_1866(D));
  ctx_1868->code = code_1869(D);

Those are all the jump threads in play and they're all correct.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For me, all I can see is that clearly at runtime omp_add_variable is called
with pctx NULL despite the if (pctx) guard around it and that until threadfull2
I was seeing a guarding condition in the IL that ensured that (either test of
the SSA_NAME passed to first arg of omp_add_variable later against 0, or in
some cases/some revisions something like:
  temp = code == OMP_TARGET ? outer_ctx : ctx;
...
  if (code != OMP_TARGET)
    goto bbn;
  if (outer_ctx != 0)
    goto bbn;
  else
    goto somewhere_else;
bbn:
  omp_add_variable (temp, ...);
which is also fine, as ctx is guaranteed to be non-NULL.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Note that I've disabled all the thread full passes and the problem persists.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> Note that I've disabled all the thread full passes and the problem persists.

So, can you see where the guarding condition vanishes in that case?

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The guard seems to be removed by the vrp2 pass, not by jump threading.

a.ii.195t.vrp2:Folding predicate iftmp.2373_1515 != 0B to 1

For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and removes
the check against zero:

=========== BB 219 ============
region_type_1384(D)     unsigned int VARYING
ctx_1386        struct gimplify_omp_ctx * [1B, +INF]
code_1387(D)    tree_code [0, 65535]
outer_ctx_1389  struct gimplify_omp_ctx * VARYING
_2620   bool VARYING
c_3771  union tree_node * [1B, +INF]
_3783   bool VARYING
    <bb 219> [local count: 105119385]:
    iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80;
    iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80;
    check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B;
    iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;

iftmp.2304_1247 : gomp_map_kind [80, 81]
iftmp.2340_1256 : gomp_map_kind [80, 81]
iftmp.2373_1515 : struct gimplify_omp_ctx * [1B, +INF]

Notice the non-zero range on exit.

To reproduce:

tmcc1plus a.ii -O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
-fdisable-tree-thread2 -fdisable-tree-thread1
-fdbg-cnt=registered_jump_thread:543-543:544-544:550-550:551-551:552-552:553-553:554-554:555-555
-fno-PIE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common
-fdump-tree-all-lineno 

and search for:

:10070:.*omp_add_variable

...in the vrp2 dump.  There's no guard on iftmp.2373_1515 because the check was
removed.

It is possible that threadfull2, which uses the ranger engine and runs before
vrp2, was threading the check, since ranger obviously thinks it's a constant. 
This is why removing threadfull2 didn't fix the problem, since vrp2 (which is
now using ranger) will make the same conclusion, albeit with a different
approach (remove the conditional instead of thread the path).

And indeed, if I add --param=vrp2-mode=vrp, to the above steps, the problem
goes away.

So, this is ranger...not the threader.  I'm going to put this aside while I
take a look at the other P1s that are completely the threader's fault, and if
Andrew doesn't get to it before, I'll come back to this.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 51778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51778&action=edit
preprocessed source to reproduce

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 103224 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Bootstrapping x86_64-linux with 
../configure --enable-checking=release --with-build-config=bootstrap-lto
--disable-plugin --enable-l
anguages=c++
leads to broken cc1 (it fails to compile empty function ICEing in gimplifier as
well).

I spent good part of day today looking into it.
The problem goes away with disabling pure/const discovery, but I think it only
triggers misoptimization later.

main
t.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
    1 | main()
      | ^~~~

Analyzing compilation unit
<built-in>: In function ‘main’:
<built-in>: internal compiler error: in force_constant_size, at gimplify.c:738
DWARF underflow in .debug_line at 18485786
DWARF underflow in .debug_line at 3053700
DWARF underflow in .debug_line at 3249290
DWARF underflow in .debug_line at 1495718
DWARF underflow in .debug_line at 5987571
DWARF underflow in .debug_line at 96

Breakpoint 1, internal_error (gmsgid=gmsgid@entry=0x1fc1ab2 "in %s, at %s:%d")
at ../../gcc/diagnostic.c:1905
1905    {
(gdb) bt
#0  internal_error (gmsgid=gmsgid@entry=0x1fc1ab2 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1905
#1  0x000000000043b560 in fancy_abort (file=0x1b93b78 "../../gcc/gimplify.c",
line=738, 
    function=0x1b93d09 "force_constant_size") at ../../gcc/diagnostic.c:2009
#2  0x0000000000410c06 in force_constant_size (var=0x7ffff7fedc60) at
../../gcc/gimplify.c:738
#3  0x000000000070f500 in gimple_add_tmp_var (tmp=0x7ffff7fedc60) at
../../gcc/gimplify.c:776
#4  0x0000000000711eb8 in create_tmp_var (prefix=0x0, type=0x7ffff6dae5e8) at
../../gcc/gimple-expr.c:485
#5  create_tmp_reg (prefix=0x0, type=0x7ffff6dae5e8) at
../../gcc/gimple-expr.c:496
#6  gimplify_return_expr (stmt=0x7ffff6ee0200, pre_p=0x7fffffffdb60) at
../../gcc/gimplify.c:1660
#7  0x000000000073ae4f in gimplify_expr (expr_p=0x7ffff6edd400,
pre_p=0x7fffffffdb60, post_p=<optimized out>, 
    gimple_test_f=0x728e00 <is_gimple_stmt(tree)>, fallback=<optimized out>) at
../../gcc/gimplify.c:14932
#8  0x000000000073a0ce in gimplify_stmt (seq_p=0x7fffffffdb60,
stmt_p=0x7ffff6edd400) at ../../gcc/gimplify.c:7031
#9  gimplify_statement_list (pre_p=0x7fffffffdb60, expr_p=0x7ffff6ed11c0) at
../../gcc/gimplify.c:2012
#10 gimplify_expr (expr_p=0x7ffff6ed11c0, pre_p=0x7fffffffdb60,
post_p=<optimized out>, 
    gimple_test_f=0x728e00 <is_gimple_stmt(tree)>, fallback=<optimized out>) at
../../gcc/gimplify.c:15115
#11 0x00000000007507ad in gimplify_stmt (seq_p=0x7fffffffdb60,
stmt_p=0x7ffff6ed11c0) at ../../gcc/gimplify.c:7026
#12 gimplify_body (fndecl=0x7ffff6ed1100, do_parms=<optimized out>) at
../../gcc/gimplify.c:15916
#13 0x00000000007512a1 in gimplify_function_tree (fndecl=0x7ffff6ed1100) at
../../gcc/gimplify.c:16070
#14 0x00000000005bb5c6 in cgraph_node::analyze (this=0x7ffff6da8220) at
../../gcc/cgraphunit.c:670
#15 0x00000000005bd2a8 in analyze_functions (first_time=<optimized out>) at
../../gcc/cgraphunit.c:1234
#16 0x00000000005bf976 in symbol_table::finalize_compilation_unit
(this=0x7ffff6d97000) at ../../gcc/cgraphunit.c:2508
#17 0x000000000099fff8 in compile_file () at ../../gcc/toplev.c:479
#18 0x00000000009a13b5 in do_compile (no_backend=<optimized out>) at
../../gcc/toplev.c:2156
#19 0x000000000044bc18 in toplev::main (argv=<optimized out>, argc=<optimized
out>, this=<synthetic pointer>)
    at ../../gcc/toplev.c:2308
#20 main (argc=<optimized out>, argv=<optimized out>) at ../../gcc/main.c:39

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeffreyalaw at gmail dot com

--- Comment #14 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #10)

> 
> For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and
> removes the check against zero:
> 
> =========== BB 219 ============
> region_type_1384(D)	unsigned int VARYING
> ctx_1386	struct gimplify_omp_ctx * [1B, +INF]
> code_1387(D)	tree_code [0, 65535]
> outer_ctx_1389	struct gimplify_omp_ctx * VARYING
> _2620	bool VARYING
> c_3771	union tree_node * [1B, +INF]
> _3783	bool VARYING
>     <bb 219> [local count: 105119385]:
>     iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80;
>     iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80;
>     check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B;
>     iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
> 
> iftmp.2304_1247 : gomp_map_kind [80, 81]
> iftmp.2340_1256 : gomp_map_kind [80, 81]
> iftmp.2373_1515 : struct gimplify_omp_ctx * [1B, +INF]
> 
> Notice the non-zero range on exit.

Looking at how we calculate iftmp.2373_1515, it does actually calculate VARYING
for the range on this statement, but intersects that with the known global
range picked up from SSA_NAME_PTR_INFO (name)->pt.null  Which tags it as a
non-null ssa-name for some reason.
I put a breakpoint in set_ptr_nonnull() for this ssa-name, and it triggers on:

433       struct ptr_info_def *pi = get_ptr_info (name);
(gdb) p print_generic_expr (stderr, name, 0)
iftmp.2373_1515

#0  set_ptr_nonnull (name=0x7fffe3b32d80) at
/gcc/master/gcc/gcc/tree-ssanames.c:433
#1  0x0000000001aa6857 in find_what_p_points_to (fndecl=0x7fffe50cd100,
p=0x7fffe3b32d80) at /gcc/master/gcc/gcc/tree-ssa-structalias.c:6851
#2  0x0000000001aa8c23 in compute_points_to_sets () at
/gcc/master/gcc/gcc/tree-ssa-structalias.c:7624
#3  0x0000000001aaa180 in compute_may_aliases () at
/gcc/master/gcc/gcc/tree-ssa-structalias.c:8036
#4  0x00000000016425e4 in execute_function_todo (fn=0x7fffe508d240,
data=0x100040) at /gcc/master/gcc/gcc/passes.c:2014
#5  0x00000000016415e1 in do_per_function (callback=0x1642515
<execute_function_todo(function*, void*)>, data=0x100040) at
/gcc/master/gcc/gcc/passes.c:1687
#6  0x0000000001642935 in execute_todo (flags=1048640) at
/gcc/master/gcc/gcc/passes.c:2096
#7  0x0000000001643a22 in execute_one_pass (pass=0x4188b60) at
/gcc/master/gcc/gcc/passes.c:2604
#8  0x0000000001643c63 in execute_pass_list_1 (pass=0x4188b60) at
/gcc/master/gcc/gcc/passes.c:2656
#9  0x0000000001643c94 in execute_pass_list_1 (pass=0x4188780) at
/gcc/master/gcc/gcc/passes.c:2657
#10 0x0000000001643cf3 in execute_pass_list (fn=0x7fffe508d240, pass=0x4188480)
at /gcc/master/gcc/gcc/passes.c:2667
#11 0x00000000010cd1ae in cgraph_node::expand (this=0x7fffe4d96220) at
/gcc/master/gcc/gcc/cgraphunit.c:1828

It looks like compute_may_aliases decides it's non-null?

I set a breakpoint in set_ptr_nonnull if name->>base.u.version == 1515  , and
the second time it trips is this variable.

Interestingly,  vrp1 also then finds this value:

Found new range for iftmp.2373_1515: struct gimplify_omp_ctx * [1B, +INF] 
EQUIVALENCES: { } (0 elements),

but that point it is a PHI node:
iftmp.2373_1515 = PHI <outer_ctx_288(2090), ctx_4333(2089)>

and it proceeds to transform it:

gimplify.ii.112t.vrp1:  # iftmp.2373_1515 = PHI <outer_ctx_288(2090),
ctx_4333(2089)>
gimplify.ii.112t.vrp1:Visiting PHI node: iftmp.2373_1515 = PHI
<outer_ctx_288(2090), ctx_4333(2089)>
gimplify.ii.112t.vrp1:Folding PHI node: iftmp.2373_1515 = PHI
<outer_ctx_288(2090), ctx_4333(2089)>
gimplify.ii.112t.vrp1:  # iftmp.2373_1515 = PHI <outer_ctx_1389(1544),
ctx_1386(1543)>

and then the lim2 pass converts it from the PHi node to:
Moving PHI node
iftmp.2373_1515 = PHI <outer_ctx_1389(1393), ctx_1386(1392)>
(cost 20) out of loop 1.

producing the block as we see it.
  <bb 215> [local count: 105119385]:
  iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80;
  iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80;
  check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B;
  iftmp.2373_1515 = code_1387(D) == 181 ? outer_ctx_1389 : ctx_1386;


Next, it looks like DOM3 has inserted the condition that is being removed that
is problematic?  from the .dom3 listing:

Optimizing statement if (outer_ctx_1389 != 0B)
  Replaced 'outer_ctx_1389' with variable 'iftmp.2373_1515'

Visiting conditional with predicate: if (iftmp.2373_1515 != 0B)

With known ranges
        iftmp.2373_1515: struct gimplify_omp_ctx * VARYING

Predicate evaluates to: DON'T KNOW
LKUP STMT iftmp.2373_1515 ne_expr 0B
0>>> COPY iftmp.2373_1515 = 0B
<<<< COPY iftmp.2373_1515 = 0B
1>>> STMT 1 = iftmp.2373_1515 ne_expr 0B
1>>> STMT 0 = iftmp.2373_1515 eq_expr 0B


Im not sure why dom thinks it is varying when it is globally set to non-null by
previous passes, nor exactly what is going on in this transformation, but it
definitely rearrange and rewrite code..

someone else can tell me what thats all about...  but bottom line is ranger is
picking up the [1, +INF] range from another pass setting it.
When I run vrp2 with the old vrp, it does not pick up the global range for
iftmp.2373_1515,  so maybe the VRP pass DOESN'T pick up globals? 

The first pass actually calculated NON_NULL, DOM3 then transforms the code, and
the second pass no longer can detect that it is nonull..   And in fact ranger
cannot detect that it is non-null either.. except it picks up the global value
produced by vrp1 and folds away the problematic stmt.

So maybe someone can comment on what DOM has done here?    Or on the stablity
of the global table by the time we get to VRP2?

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[amacleod at redhat dot com]

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

--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
I added a series of vrp passes to see when things go amok.

immediately before DOM3, we see:

 <bb 1416> [local count: 22683134]:
  if (outer_ctx_1389 != 0B)
    goto <bb 1417>; [70.00%]
  else
    goto <bb 1420>; [30.00%]

  <bb 1417> [local count: 37567381]:
  _784 = omp_clause_range_check (c_3171, 5, 7,
"/home/aldyh/src/gcc/gcc/gimplify.c", 10070, "gimplify_scan_omp_clauses");
  _785 = omp_clause_elt_check (_784, 3, "/home/aldyh/src/gcc/gcc/gimplify.c",
10070, "gimplify_scan_omp_clauses");
  _786 = *_785;
  omp_add_variable (iftmp.2373_1515, _786, 129);

and outer_ctx_1389 is varying, so we cannot fold anything,and we know:
iftmp.2373_1515  : struct gimplify_omp_ctx * [1B, +INF]

then DOM3 runs, and transforms this into:
  <bb 1415> [local count: 22683134]:
  if (iftmp.2373_1515 != 0B)
    goto <bb 1416>; [70.00%]
  else
    goto <bb 1419>; [30.00%]

  <bb 1416> [local count: 37567381]:
  _784 = omp_clause_range_check (c_3171, 5, 7,
"/home/aldyh/src/gcc/gcc/gimplify.c", 10070, "gimplify_scan_omp_clauses");
  _785 = omp_clause_elt_check (_784, 3, "/home/aldyh/src/gcc/gcc/gimplify.c",
10070, "gimplify_scan_omp_clauses");
  _786 = *_785;
  omp_add_variable (iftmp.2373_1515, _786, 129);


which is going to clearly cause problems when VRP knows that iftmp.2373_151 is
non-null...  

So it looks like this transformation is the problematic one for sure.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

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

--- Comment #16 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Based in c#15 there must be an equivalence between outer_ctx_1389  and
iftmp.2373_1515  that dominates the condition.  The equivalence doesn't have to
be a global equivalence though.  I'd start by chasing that down to see if it
makes sense.  I'm going to hazard a guess it's a conditional equivalence and
that there's a difference in the cost to compute those two objects (otherwise
we'd ignore the conditional equivalence).



Presumably the range on outer_ctx_1389 is global VARYING and iftmp.2373_1515 is
global non-zero.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
iftmp.2373_1515 is defined earlier as:
  iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
so the transformation by dom3? from
  if (outer_ctx_1389 != 0B)
to
  if (iftmp.2373_1515 != 0B)
is sound (even though it undoes some previously done optimization), but perhaps
we need to reset_flow_sensitive_info on it somewhere along the way?  Though,
the definition is always not in code guarded by outer_ctx_1389 != 0B check, so
I wonder why it would be marked as non-NULL, only the uses or some of the uses
of the SSA_NAME can be non-NULL.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[aldyh at gcc dot gnu.org]

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

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #17)
> iftmp.2373_1515 is defined earlier as:
>   iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
> so the transformation by dom3? from
>   if (outer_ctx_1389 != 0B)
> to
>   if (iftmp.2373_1515 != 0B)
> is sound (even though it undoes some previously done optimization), but
> perhaps
> we need to reset_flow_sensitive_info on it somewhere along the way?  Though,
> the definition is always not in code guarded by outer_ctx_1389 != 0B check,
> so I wonder why it would be marked as non-NULL, only the uses or some of the
> uses of the SSA_NAME can be non-NULL.

It looks like DOM uses propagate_value() which makes the substitution outright,
whereas the copy-prop pass is more careful with global ranges:

              /* Points-to information is cfg insensitive,
                 but [E]VRP might record context sensitive alignment
                 info, non-nullness, etc.  So reset context sensitive
                 info if the two SSA_NAMEs aren't defined in the same
                 basic block.  */
              if (var_bb != copy_of_bb)
                reset_flow_sensitive_info (copy_of[i].value);

Perhaps we need something similar in DOM's cprop_operand?

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This looks like a lim2 bug to me.
Before that we have:
  <bb 1392> [local count: 44372324]:
  [/usr/src/gcc/gcc/gimplify.c:10068:24] if (code_1387(D) == 181)
    goto <bb 1393>; [51.12%]
  else
    goto <bb 1394>; [48.88%]

  <bb 1393> [local count: 22683134]:
  [/usr/src/gcc/gcc/gimplify.c:10069:8] if (outer_ctx_1389 != 0B)
    goto <bb 1394>; [70.00%]
  else
    goto <bb 1397>; [30.00%]

  <bb 1394> [local count: 37567381]:
  # PT = nonlocal escaped { D.141932 D.141953 D.141974 D.181276 D.181278
D.181824 D.181827 D.181828 D.181834 D.182151 D.182157 D.182167 D.182168
D.182169 D.182170 D.182171 D.182173 D
.182190 D.182192 D.182194 D.182195 D.182198 D.182398 D.182856 D.182863 D.182865
D.182867 D.182946 D.182947 D.182948 D.182949 } (nonlocal, escaped, escaped
heap)
  # iftmp.2373_1515 = PHI <outer_ctx_1389(1393), ctx_1386(1392)>
so it is perfectly fine that null isn't there in PT of iftmp.2373_1515.
But lim2 moves it to:
  # PT = nonlocal escaped { D.141932 D.141953 D.141974 D.181276 D.181278
D.181824 D.181827 D.181828 D.181834 D.182151 D.182157 D.182167 D.182168
D.182169 D.182170 D.182171 D.182173 D
.182190 D.182192 D.182194 D.182195 D.182198 D.182398 D.182856 D.182863 D.182865
D.182867 D.182946 D.182947 D.182948 D.182949 } (nonlocal, escaped, escaped
heap)
  iftmp.2373_1515 = code_1387(D) == 181 ? outer_ctx_1389 : ctx_1386;
which isn't dominated by the outer_ctx_1389 != NULL check and so
reset_flow_sensitive_info should have been called on it.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51810&action=edit
gcc12-pr103192.patch

Untested fix.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:077425c890927eefacb765ab5236060de9859e82

commit r12-5337-g077425c890927eefacb765ab5236060de9859e82
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 17 14:18:42 2021 +0100

    lim: Reset flow sensitive info even for pointers [PR103192]

    Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
    if moving them from conditional contexts inside of a loop into
unconditional
    before the loop, but as the miscompilation of gimplify.c shows, we need to
    treat pointers the same, even for them we need to reset whether the pointer
    can/can't be null or the recorded pointer alignment.

    This fixes
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
    -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
(internal compiler error)
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test
for excess errors)
    -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
    -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
    -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to
produce executable
    on both x86_64 and i686.

    2021-11-17  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/103192
            * tree-ssa-loop-im.c (move_computations_worker): Use
            reset_flow_sensitive_info instead of manually clearing
            SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
            with integral types.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9ec84b35640aa06de5b2108deb30a3501342fbaf

commit r11-9333-g9ec84b35640aa06de5b2108deb30a3501342fbaf
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 17 14:18:42 2021 +0100

    lim: Reset flow sensitive info even for pointers [PR103192]

    Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
    if moving them from conditional contexts inside of a loop into
unconditional
    before the loop, but as the miscompilation of gimplify.c shows, we need to
    treat pointers the same, even for them we need to reset whether the pointer
    can/can't be null or the recorded pointer alignment.

    This fixes
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
    -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
(internal compiler error)
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test
for excess errors)
    -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
    -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
    -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to
produce executable
    on both x86_64 and i686.

    2021-11-17  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/103192
            * tree-ssa-loop-im.c (move_computations_worker): Use
            reset_flow_sensitive_info instead of manually clearing
            SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
            with integral types.

    (cherry picked from commit 077425c890927eefacb765ab5236060de9859e82)

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r10-10654-gbce66daa009ae64d1b0fa5ed0188b184767d7081
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 17 14:18:42 2021 +0100

    lim: Reset flow sensitive info even for pointers [PR103192]

    Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
    if moving them from conditional contexts inside of a loop into
unconditional
    before the loop, but as the miscompilation of gimplify.c shows, we need to
    treat pointers the same, even for them we need to reset whether the pointer
    can/can't be null or the recorded pointer alignment.

    This fixes
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
    -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
(internal compiler error)
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test
for excess errors)
    -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
    -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
    -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to
produce executable
    on both x86_64 and i686.

    2021-11-17  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/103192
            * tree-ssa-loop-im.c (move_computations_worker): Use
            reset_flow_sensitive_info instead of manually clearing
            SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
            with integral types.

    (cherry picked from commit 077425c890927eefacb765ab5236060de9859e82)

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1f02d664cdcc8824c56b7d20a98a3aaa8fc6f0f8

commit r9-10110-g1f02d664cdcc8824c56b7d20a98a3aaa8fc6f0f8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 17 14:18:42 2021 +0100

    lim: Reset flow sensitive info even for pointers [PR103192]

    Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
    if moving them from conditional contexts inside of a loop into
unconditional
    before the loop, but as the miscompilation of gimplify.c shows, we need to
    treat pointers the same, even for them we need to reset whether the pointer
    can/can't be null or the recorded pointer alignment.

    This fixes
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
    -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
(internal compiler error)
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test
for excess errors)
    -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
    -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
    -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
    -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to
produce executable
    on both x86_64 and i686.

    2021-11-17  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/103192
            * tree-ssa-loop-im.c (move_computations_worker): Use
            reset_flow_sensitive_info instead of manually clearing
            SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
            with integral types.

    (cherry picked from commit 077425c890927eefacb765ab5236060de9859e82)