[Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

[Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

[gscfq@t-online.de]

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

            Bug ID: 98330
           Summary: [11 Regression] ICE in compute_parm_map, at
                    ipa-modref.c:2900
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Changed between 20201018 and 20201108, at -O1+ :


$ cat z1.cc
float a = __builtin_pow[1] (3.0, 2);


$ cat z2.cc
float f (float x)
{
  return __builtin_pow[1] (x, 2);
}


$ g++-11-20201213 -c z1.cc -O2
z1.cc:1:26: warning: pointer to a function used in arithmetic [-Wpointer-arith]
    1 | float a = __builtin_pow[1] (3.0, 2);
      |                          ^
during IPA pass: modref
z1.cc:1:36: internal compiler error: Segmentation fault
    1 | float a = __builtin_pow[1] (3.0, 2);
      |                                    ^
0xc8f5ff crash_signal
        ../../gcc/toplev.c:327
0x8c75f2 symtab_node::ultimate_alias_target(availability*, symtab_node*)
        ../../gcc/cgraph.h:3182
0x8c75f2 cgraph_node::ultimate_alias_target(availability*, symtab_node*)
        ../../gcc/cgraph.h:3203
0x8c75f2 cgraph_node::function_or_virtual_thunk_symbol(availability*,
symtab_node*)
        ../../gcc/cgraph.c:3868
0xaa629a compute_parm_map
        ../../gcc/ipa-modref.c:2900
0xaa6961 compute_parm_map
        ../../gcc/ipa-modref.c:2891
0xaa6961 propagate_unknown_call
        ../../gcc/ipa-modref.c:3271
0xaa8757 modref_propagate_in_scc
        ../../gcc/ipa-modref.c:3425
0xaa8f7c execute
        ../../gcc/ipa-modref.c:3833

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2020-12-17
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Can't reproduce that with the current master.

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|WAITING                     |NEW
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |11.0
           Keywords|                            |ice-on-valid-code

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on trunk (with z2.cc):

> ./cc1plus -quiet t.ii
t.ii: In function 'float f(float)':
t.ii:3:25: warning: pointer to a function used in arithmetic [-Wpointer-arith]
    3 |   return __builtin_pow[1] (x, 2);
      |                         ^
rguenther@ryzen:~/obj-gcc2-g/gcc> ./cc1plus -quiet t.ii -O2
t.ii: In function 'float f(float)':
t.ii:3:25: warning: pointer to a function used in arithmetic [-Wpointer-arith]
    3 |   return __builtin_pow[1] (x, 2);
      |                         ^
during IPA pass: modref
t.ii: At global scope:
t.ii:4:1: internal compiler error: Segmentation fault
    4 | }
      | ^
0x1851657 crash_signal
        /home/rguenther/src/gcc2/gcc/toplev.c:327
0xc8fbe8 symtab_node::ultimate_alias_target(availability*, symtab_node*)
        /home/rguenther/src/gcc2/gcc/cgraph.h:3182
0x10c5fbe cgraph_node::ultimate_alias_target(availability*, symtab_node*)
        /home/rguenther/src/gcc2/gcc/cgraph.h:3203
0x10c2224 cgraph_node::function_or_virtual_thunk_symbol(availability*,
symtab_node*)
        /home/rguenther/src/gcc2/gcc/cgraph.c:3868
0x1477503 compute_parm_map
        /home/rguenther/src/gcc2/gcc/ipa-modref.c:2900

[Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11 Regression] ICE in      |[9/10/11 Regression] ICE in
                   |compute_parm_map, at        |compute_parm_map, at
                   |ipa-modref.c:2900           |ipa-modref.c:2900 since
                   |                            |r9-2640-g3d78e00879b42574
           Keywords|ice-on-valid-code           |ice-on-invalid-code

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
It's an invalid code and I can see it since r9-2640-g3d78e00879b42574:

pr98330.c: In function ‘float f(float)’:
pr98330.c:3:25: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
3 |   return __builtin_pow[1] (x, 2);
  |                         ^
during GIMPLE pass: ccp
pr98330.c:4:1: internal compiler error: tree check: expected function_decl,
have mem_ref in fndecl_built_in_p, at tree.h:5851
4 | }
  | ^

[Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So modref allocates a fnspec_summary for an unknown indirect call (NULL callee)
but then in compute_parm_map calls function_or_virtual_thunk_symbol on
that NULL callee unconditionally.  We have a meaningful fnspec for the
call because the call type has a 'fn spec' attribute attached.

So I'm proposing the following which avoids the ICE (and undefined behavior
calling a member fn on a NULL object)

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 74ad876cf58..8a5669c7f9b 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1247,11 +1247,13 @@ analyze_stmt (modref_summary *summary,
modref_summary_lto *summary_lto,
            && (!fnspec.global_memory_read_p ()
                || !fnspec.global_memory_written_p ()))
          {
-           fnspec_summaries->get_create
-                (cgraph_node::get (current_function_decl)->get_edge (stmt))
-                       ->fnspec = xstrdup (fnspec.get_str ());
-           if (dump_file)
-             fprintf (dump_file, "  Recorded fnspec %s\n", fnspec.get_str ());
+           cgraph_edge *e = cgraph_node::get (current_function_decl)->get_edge
(stmt);
+           if (e->callee)
+             {
+               fnspec_summaries->get_create (e)->fnspec = xstrdup
(fnspec.get_str ());
+               if (dump_file)
+                 fprintf (dump_file, "  Recorded fnspec %s\n", fnspec.get_str
());
+             }
          }
       }
      return true;

Re: [Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[Jan Hubicka]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330
> 
> --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> So modref allocates a fnspec_summary for an unknown indirect call (NULL callee)
> but then in compute_parm_map calls function_or_virtual_thunk_symbol on
> that NULL callee unconditionally.  We have a meaningful fnspec for the
> call because the call type has a 'fn spec' attribute attached.
> 
> So I'm proposing the following which avoids the ICE (and undefined behavior
> calling a member fn on a NULL object)

That looks OK.  We do not expect fnspecs on types of indirect calls (we
probably should, I just did not expected them to exist) but then we can
always recover them from type.  I suppose we do not need per-call-stmt
sensitive fnspec attributes on indirect calls, right?

Honza

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE in |[11 Regression] ICE in
                   |compute_parm_map, at        |compute_parm_map, at
                   |ipa-modref.c:2900 since     |ipa-modref.c:2900 since
                   |r9-2640-g3d78e00879b42574   |r9-2640-g3d78e00879b42574

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #3)
> It's an invalid code and I can see it since r9-2640-g3d78e00879b42574:
> 
> pr98330.c: In function ‘float f(float)’:
> pr98330.c:3:25: warning: pointer to a function used in arithmetic
> [-Wpointer-arith]
> 3 |   return __builtin_pow[1] (x, 2);
>   |                         ^
> during GIMPLE pass: ccp
> pr98330.c:4:1: internal compiler error: tree check: expected function_decl,
> have mem_ref in fndecl_built_in_p, at tree.h:5851
> 4 | }
>   | ^

I can't reproduce the CCP ICE on trunk, I guess that was fixed at some point.
We just got a new modref case?

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
> I can't reproduce the CCP ICE on trunk, I guess that was fixed at some point.

Yes, this one got fixed with r10-4264-g6773658a809fbebc.

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |ice-on-valid-code

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Valid C testcase that crashes the same way:

float f (__typeof (__builtin_pow) fn, float x)
{
  return fn (x, 2);
}

gimple_call_fnspec doesn't return anything for an indirect call to a
const function (where gimple_call_flags would say ECF_CONST).

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330
> 
> --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> So modref allocates a fnspec_summary for an unknown indirect call (NULL callee)
> but then in compute_parm_map calls function_or_virtual_thunk_symbol on
> that NULL callee unconditionally.  We have a meaningful fnspec for the
> call because the call type has a 'fn spec' attribute attached.
> 
> So I'm proposing the following which avoids the ICE (and undefined behavior
> calling a member fn on a NULL object)

That looks OK.  We do not expect fnspecs on types of indirect calls (we
probably should, I just did not expected them to exist) but then we can
always recover them from type.  I suppose we do not need per-call-stmt
sensitive fnspec attributes on indirect calls, right?

Honza

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[rguenth at gcc dot gnu.org]

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

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 #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330
> > 
> > --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> > So modref allocates a fnspec_summary for an unknown indirect call (NULL callee)
> > but then in compute_parm_map calls function_or_virtual_thunk_symbol on
> > that NULL callee unconditionally.  We have a meaningful fnspec for the
> > call because the call type has a 'fn spec' attribute attached.
> > 
> > So I'm proposing the following which avoids the ICE (and undefined behavior
> > calling a member fn on a NULL object)
> 
> That looks OK.  We do not expect fnspecs on types of indirect calls (we
> probably should, I just did not expected them to exist) but then we can
> always recover them from type.  I suppose we do not need per-call-stmt
> sensitive fnspec attributes on indirect calls, right?

Right.

> Honza

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:66dd412feeab29783fcdcf7ab36f20c5dd7b2332

commit r11-6791-g66dd412feeab29783fcdcf7ab36f20c5dd7b2332
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Jan 19 14:21:41 2021 +0100

    ipa/98330 - avoid ICEing on call indirect call

    The following avoids ICEing on a indirect calls with a fnspec
    in modref analysis.

    2021-01-19  Richard Biener  <rguenther@suse.de>

            PR ipa/98330
            * ipa-modref.c (analyze_stmt): Only record a summary for a
            direct call.

            * g++.dg/pr98330.C: New testcase.
            * gcc.dg/pr98330.c: Likewise.

[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574

[rguenth at gcc dot gnu.org]

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

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

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

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