* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
@ 2020-12-17 11:14 ` marxin at gcc dot gnu.org
2021-01-04 15:33 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-12-17 11:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
2020-12-17 11:14 ` [Bug c++/98330] " marxin at gcc dot gnu.org
@ 2021-01-04 15:33 ` rguenth at gcc dot gnu.org
2021-01-06 11:47 ` [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
` (8 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-04 15:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
2020-12-17 11:14 ` [Bug c++/98330] " marxin at gcc dot gnu.org
2021-01-04 15:33 ` rguenth at gcc dot gnu.org
@ 2021-01-06 11:47 ` marxin at gcc dot gnu.org
2021-01-19 13:18 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-06 11:47 UTC (permalink / raw)
To: gcc-bugs
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 | }
| ^
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (2 preceding siblings ...)
2021-01-06 11:47 ` [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
@ 2021-01-19 13:18 ` rguenth at gcc dot gnu.org
2021-01-19 13:29 ` Jan Hubicka
2021-01-19 13:20 ` [Bug c++/98330] [11 " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 1 reply; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-19 13:18 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bug c++/98330] [9/10/11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2021-01-19 13:18 ` rguenth at gcc dot gnu.org
@ 2021-01-19 13:29 ` Jan Hubicka
0 siblings, 0 replies; 13+ messages in thread
From: Jan Hubicka @ 2021-01-19 13:29 UTC (permalink / raw)
To: rguenth at gcc dot gnu.org; +Cc: gcc-bugs
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (3 preceding siblings ...)
2021-01-19 13:18 ` rguenth at gcc dot gnu.org
@ 2021-01-19 13:20 ` rguenth at gcc dot gnu.org
2021-01-19 13:25 ` marxin at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-19 13:20 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (4 preceding siblings ...)
2021-01-19 13:20 ` [Bug c++/98330] [11 " rguenth at gcc dot gnu.org
@ 2021-01-19 13:25 ` marxin at gcc dot gnu.org
2021-01-19 13:28 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-19 13:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (5 preceding siblings ...)
2021-01-19 13:25 ` marxin at gcc dot gnu.org
@ 2021-01-19 13:28 ` rguenth at gcc dot gnu.org
2021-01-19 13:29 ` hubicka at ucw dot cz
` (3 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-19 13:28 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (6 preceding siblings ...)
2021-01-19 13:28 ` rguenth at gcc dot gnu.org
@ 2021-01-19 13:29 ` hubicka at ucw dot cz
2021-01-19 14:13 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 13+ messages in thread
From: hubicka at ucw dot cz @ 2021-01-19 13:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (7 preceding siblings ...)
2021-01-19 13:29 ` hubicka at ucw dot cz
@ 2021-01-19 14:13 ` rguenth at gcc dot gnu.org
2021-01-19 14:50 ` cvs-commit at gcc dot gnu.org
2021-01-19 14:51 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-19 14:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (8 preceding siblings ...)
2021-01-19 14:13 ` rguenth at gcc dot gnu.org
@ 2021-01-19 14:50 ` cvs-commit at gcc dot gnu.org
2021-01-19 14:51 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-19 14:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 since r9-2640-g3d78e00879b42574
2020-12-16 18:34 [Bug c++/98330] New: [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900 gscfq@t-online.de
` (9 preceding siblings ...)
2021-01-19 14:50 ` cvs-commit at gcc dot gnu.org
@ 2021-01-19 14:51 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-19 14:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread