[Bug tree-optimization/113520] New: ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[Bug tree-optimization/113520] New: ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[sjames at gcc dot gnu.org]

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

            Bug ID: 113520
           Summary: ICE when building swi-prolog-9.1.2 with LTO (tree
                    check: expected array_type, have integer_type in
                    array_ref_low_bound)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
                CC: arsen at gcc dot gnu.org
  Target Milestone: ---

Arsen mentioned this to me earlier so I looked at reducing it.

ICEs when building swi-prolog-9.1.2 with LTO.

passing.c.i:
```
typedef void Any;
int get_table, getGetMethodClass_class;
extern int builtin_names[];
Any getResolveGetMethodClass();
static Any getGetMethodClass(int *name) {
  getResolveGetMethodClass(get_table);
  getResolveGetMethodClass(getGetMethodClass_class, name);
}
void pceResolveImplementation() { getGetMethodClass(&builtin_names[1]); }
```

name.c.i
```
int builtin_names;
```

```
$ gcc -flto -O3  passing.c.i name.c.i -shared
during GIMPLE pass: alias
passing.c.i: In function ‘pceResolveImplementation’:
passing.c.i:9:6: internal compiler error: tree check: expected array_type, have
integer_type in array_ref_low_bound, at tree.cc:12851
    9 | void pceResolveImplementation() { getGetMethodClass(&builtin_names[1]);
}
      |      ^
0x5653e7eb8b8c tree_check_failed(tree_node const*, char const*, int, char
const*, ...)
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree.cc:8952
0x5653e71ee414 tree_check(tree_node*, char const*, int, char const*, tree_code)
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree.h:3612
0x5653e71ee414 array_ref_low_bound(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree.cc:12851
0x5653e88640b8 get_ref_base_and_extent(tree_node*, poly_int<1u, long>*,
poly_int<1u, long>*, poly_int<1u, long>*, bool*)
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-dfa.cc:497
0x5653e8973a07 get_constraint_for_component_ref
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3319
0x5653e8973a07 get_constraint_for_1(tree_node*, vec<constraint_expr, va_heap,
vl_ptr>*, bool, bool) [clone .isra.0]
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3634
0x5653e89738aa get_constraint_for_address_of
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3502
0x5653e89738aa get_constraint_for_1(tree_node*, vec<constraint_expr, va_heap,
vl_ptr>*, bool, bool) [clone .isra.0]
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3570
0x5653e89ca9d7 get_constraint_for_rhs
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3719
0x5653e89ca9d7 make_constraint_to
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:3848
0x5653e89ca9d7 handle_call_arg
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:4100
0x5653e89a7bcc handle_rhs_call
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:4344
0x5653e8971603 find_func_aliases_for_call
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:5018
0x5653e8971603 find_func_aliases
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:5121
0x5653e896b1d7 compute_points_to_sets
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:7573
0x5653e896b1d7 compute_may_aliases()
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/tree-ssa-structalias.cc:8027
0x5653e8722af3 execute_function_todo
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/passes.cc:2063
0x5653e8722af3 do_per_function
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/passes.cc:1687
0x5653e8722af3 execute_todo
       
/usr/src/debug/sys-devel/gcc-14.0.1.9999/gcc-14.0.1.9999/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[sjames at gcc dot gnu.org]

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

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
10/11/12/13/14 all reproduce it for me

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This code is definitely undefined.

Is builtin_names really defined as an array in one TU but an int in another
one?

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code has:
```
struct bname builtin_names[] =
{
...
};
```


header file:
```
extern struct name builtin_names[];     /* object-array of built-in's */
```

Wich is underfined but in a different way than the reduced testcase.

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[sjames at gcc dot gnu.org]

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

--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
Yeah, after you asked, I just realised the original does ICE differently. Let's
retitle this one and I'll reduce it properly again for the original (but it is
similar)

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://github.com/SWI-Prolog/packages-xpce/commit/641bbb1d83416be2fb910dbffcd6ba32db1c0b8e

Was the commit which "fixed" compiling with GCC 4.0 but really it is broken.
I suspect the fix is to use s/struct name/struct bname/ here might work. but
this is all messy pre-ANSI C code.

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-22
          Component|tree-optimization           |ipa
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Keywords|                            |lto

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, we are supposed to "handle" this during in-streaming.  This seems to work
but then for some reason it gets fiddled with again...

Ah, so this is reading of IPA CP summaries where it seems that we do not
apply these "tricks", gimple-streamer-out.cc has

          /* Wrap all uses of non-automatic variables inside MEM_REFs
             so that we do not have to deal with type mismatches on
             merged symbols during IL read in.  The first operand
             of GIMPLE_DEBUG must be a decl, not MEM_REF, though.  */
          if (!flag_wpa && op && (i || !is_gimple_debug (stmt)))
            {
              basep = &op;
              if (TREE_CODE (*basep) == ADDR_EXPR)
                basep = &TREE_OPERAND (*basep, 0);
              while (handled_component_p (*basep))
                basep = &TREE_OPERAND (*basep, 0);
              if (VAR_P (*basep)
                  && !auto_var_in_fn_p (*basep, fn->decl)
                  && !DECL_REGISTER (*basep)) 
                {
                  bool volatilep = TREE_THIS_VOLATILE (*basep);
                  tree ptrtype = build_pointer_type (TREE_TYPE (*basep));
                  *basep = build2 (MEM_REF, TREE_TYPE (*basep),
                                   build1 (ADDR_EXPR, ptrtype, *basep),
                                   build_int_cst (ptrtype, 0));
                  TREE_THIS_VOLATILE (*basep) = volatilep;
...

and gimple-streamer-in.cc undoes this when the prevailing decls are compatible:

          /* At LTO output time we wrap all global decls in MEM_REFs to
             allow seamless replacement with prevailing decls.  Undo this
             here if the prevailing decl allows for this.
             ???  Maybe we should simply fold all stmts.  */
          if (TREE_CODE (*opp) == MEM_REF
              && TREE_CODE (TREE_OPERAND (*opp, 0)) == ADDR_EXPR
              && integer_zerop (TREE_OPERAND (*opp, 1))
              && (TREE_THIS_VOLATILE (*opp)
                  == TREE_THIS_VOLATILE
                       (TREE_OPERAND (TREE_OPERAND (*opp, 0), 0)))
              && !TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (*opp, 1)))
              && (TREE_TYPE (*opp)
                  == TREE_TYPE (TREE_TYPE (TREE_OPERAND (*opp, 1))))
              && (TREE_TYPE (*opp)
                  == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (*opp, 0), 0))))
            *opp = TREE_OPERAND (TREE_OPERAND (*opp, 0), 0);

I suppose we might want to split these out so summary streaming can apply
this to streamed trees as well?

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's also a missing WPA diagnostic (OTOH one decl is just external and IIRC
we kind-of allow builtin_names[] to refer of a single element array
implemented as 'int builtin_names').

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I think the ipa-cp summaries should be used only when types match. At least
Martin added type streaming for all the jump functions.  So we are missing some
check?

[Bug ipa/113520] ICE with mismatched types with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> I think the ipa-cp summaries should be used only when types match. At least
> Martin added type streaming for all the jump functions.  So we are missing
> some check?

I don't think this applies here, we're having


foo (&b[5]);

with b being int vs int[], so it's not about the argument types matching
or the type of the JF but instead the value effectively changing during
streaming due to varpool node "merging".

As said elsewhere we avoid the issue by preserving the type of possibly
merged decls by wrapping it with a MEM_REF (for rvalues a V_C_E would
be possible as well).  And we unwrap it later when possible (but that's
of course optional).

I think any summary streaming referencing decls subject to WPA merging
need to do the same - it's not possible to recover after the fact since
the original type is lost (for the ARRAY_REF case it might be possible
to infer a type that would be good enough of course).