* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
@ 2023-05-17 19:07 ` pinskia at gcc dot gnu.org
2023-05-22 18:04 ` aldyh at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-17 19:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-05-17
Blocks| |63426
Keywords| |ice-on-valid-code
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Breakpoint 6, range_cast (r=..., type=<record_type 0x7ffff73eda80 S0>) at
/home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
4853 Value_Range tmp (r);
Confirmed.
The code looks like:
```
int g_5, func_1_l_32, func_50___trans_tmp_31;
...
int func_1() { func_50(g_3_4, g_5, func_1_l_32, 8, 3); }
...
struct S0 *func_50(int p_51, struct S0 p_52, struct S1 p_53, int p_54,
int p_55) {
...
}
```
Code in gcc:
if (TREE_CODE (arg) == SSA_NAME
&& param_type
/* Limit the ranger query to integral types as the rest
of this file uses value_range's, which only hold
integers and pointers. */
&& irange::supports_p (TREE_TYPE (arg))
&& get_range_query (cfun)->range_of_expr (vr, arg)
&& !vr.undefined_p ())
{
value_range resvr = vr;
range_cast (resvr, param_type);
if (!resvr.undefined_p () && !resvr.varying_p ())
ipa_set_jfunc_vr (jfunc, &resvr);
else
gcc_assert (!jfunc->m_vr);
}
else
gcc_assert (!jfunc->m_vr);
Maybe there should be an extra check for `irange::supports_p (param_type)` too
to catch the case where param_type type is not supported at all.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
2023-05-17 19:07 ` [Bug ipa/109886] " pinskia at gcc dot gnu.org
@ 2023-05-22 18:04 ` aldyh at gcc dot gnu.org
2023-05-22 18:07 ` pinskia at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aldyh at gcc dot gnu.org @ 2023-05-22 18:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Breakpoint 6, range_cast (r=..., type=<record_type 0x7ffff73eda80 S0>) at
> /home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
> 4853 Value_Range tmp (r);
>
>
> Confirmed.
> The code looks like:
> ```
> int g_5, func_1_l_32, func_50___trans_tmp_31;
> ...
> int func_1() { func_50(g_3_4, g_5, func_1_l_32, 8, 3); }
> ...
> struct S0 *func_50(int p_51, struct S0 p_52, struct S1 p_53, int p_54,
> int p_55) {
> ...
> }
> ```
>
> Code in gcc:
> if (TREE_CODE (arg) == SSA_NAME
> && param_type
> /* Limit the ranger query to integral types as the rest
> of this file uses value_range's, which only hold
> integers and pointers. */
> && irange::supports_p (TREE_TYPE (arg))
> && get_range_query (cfun)->range_of_expr (vr, arg)
> && !vr.undefined_p ())
> {
> value_range resvr = vr;
> range_cast (resvr, param_type);
> if (!resvr.undefined_p () && !resvr.varying_p ())
> ipa_set_jfunc_vr (jfunc, &resvr);
> else
> gcc_assert (!jfunc->m_vr);
> }
> else
> gcc_assert (!jfunc->m_vr);
>
>
> Maybe there should be an extra check for `irange::supports_p (param_type)`
> too to catch the case where param_type type is not supported at all.
If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
integer/pointer, but if range_cast is being called on a parm_type of
RECORD_TYPE, someone's trying to cast a structure to an integer. Is that the
intent here, because that will not work with ranges??
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
2023-05-17 19:07 ` [Bug ipa/109886] " pinskia at gcc dot gnu.org
2023-05-22 18:04 ` aldyh at gcc dot gnu.org
@ 2023-05-22 18:07 ` pinskia at gcc dot gnu.org
2023-05-22 18:13 ` aldyh at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-22 18:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #2)
> If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> integer/pointer, but if range_cast is being called on a parm_type of
> RECORD_TYPE, someone's trying to cast a structure to an integer. Is that
> the intent here, because that will not work with ranges??
That is correct. The generated code has a VIEW_CONVERT_EXR from an integer type
to a RECORD_TYPE.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (2 preceding siblings ...)
2023-05-22 18:07 ` pinskia at gcc dot gnu.org
@ 2023-05-22 18:13 ` aldyh at gcc dot gnu.org
2023-05-23 16:14 ` jamborm at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aldyh at gcc dot gnu.org @ 2023-05-22 18:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > integer/pointer, but if range_cast is being called on a parm_type of
> > RECORD_TYPE, someone's trying to cast a structure to an integer. Is that
> > the intent here, because that will not work with ranges??
>
> That is correct. The generated code has a VIEW_CONVERT_EXR from an integer
> type to a RECORD_TYPE.
Eeeech. In that case, then what you suggest is reasonable. Bail if param_type
is not supported by the underlying range. Maybe the IPA experts could opine?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (3 preceding siblings ...)
2023-05-22 18:13 ` aldyh at gcc dot gnu.org
@ 2023-05-23 16:14 ` jamborm at gcc dot gnu.org
2023-06-07 20:57 ` amacleod at redhat dot com
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jamborm at gcc dot gnu.org @ 2023-05-23 16:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Aldy Hernandez from comment #2)
> > > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > > integer/pointer, but if range_cast is being called on a parm_type of
> > > RECORD_TYPE, someone's trying to cast a structure to an integer. Is that
> > > the intent here, because that will not work with ranges??
> >
> > That is correct. The generated code has a VIEW_CONVERT_EXR from an integer
> > type to a RECORD_TYPE.
>
> Eeeech. In that case, then what you suggest is reasonable. Bail if
> param_type is not supported by the underlying range. Maybe the IPA experts
> could opine?
With LTOed type mismateches or with K&R style code, IPA has to be prepared to
deal with such cases, unfortunately. So a check like that indeed looks
reasonable.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (4 preceding siblings ...)
2023-05-23 16:14 ` jamborm at gcc dot gnu.org
@ 2023-06-07 20:57 ` amacleod at redhat dot com
2023-06-08 12:27 ` jamborm at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amacleod at redhat dot com @ 2023-06-07 20:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > (In reply to Andrew Pinski from comment #3)
> > > That is correct. The generated code has a VIEW_CONVERT_EXR from an integer
> > > type to a RECORD_TYPE.
> >
> > Eeeech. In that case, then what you suggest is reasonable. Bail if
> > param_type is not supported by the underlying range. Maybe the IPA experts
> > could opine?
>
> With LTOed type mismateches or with K&R style code, IPA has to be prepared
> to deal with such cases, unfortunately. So a check like that indeed looks
> reasonable.
The new range-op dispatch code is coming shortly.. when an unsupported type is
passed in to any ranger routine, we'll simply return false instead of trapping
like we do now.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (5 preceding siblings ...)
2023-06-07 20:57 ` amacleod at redhat dot com
@ 2023-06-08 12:27 ` jamborm at gcc dot gnu.org
2023-06-08 19:00 ` amacleod at redhat dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jamborm at gcc dot gnu.org @ 2023-06-08 12:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I see, thanks! But I wonder whether it would make sense to commit the simple
fix in the meantime so that the test pass. It is easy to miss new regressions
now when I expect the overall result not to be clean.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (6 preceding siblings ...)
2023-06-08 12:27 ` jamborm at gcc dot gnu.org
@ 2023-06-08 19:00 ` amacleod at redhat dot com
2023-06-09 9:00 ` jamborm at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amacleod at redhat dot com @ 2023-06-08 19:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
I just checked in:
commit cd9c7f898d6e6313465f78227e566f27dce5e5a3
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Wed May 31 13:10:31 2023 -0400
Provide a new dispatch mechanism for range-ops.
As a side effect it should make range_cast simply return varying if the RHS is
an unsupported type or unimplemented cast.
Check if this resolves this PR.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (7 preceding siblings ...)
2023-06-08 19:00 ` amacleod at redhat dot com
@ 2023-06-09 9:00 ` jamborm at gcc dot gnu.org
2023-06-09 13:14 ` amacleod at redhat dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jamborm at gcc dot gnu.org @ 2023-06-09 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #9 from Martin Jambor <jamborm at gcc dot gnu.org> ---
A buildbot run which checked out this revision unfortunately still reports this
problem with UBSAN-bootstrapped compiler.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (8 preceding siblings ...)
2023-06-09 9:00 ` jamborm at gcc dot gnu.org
@ 2023-06-09 13:14 ` amacleod at redhat dot com
2023-06-09 13:58 ` amacleod at redhat dot com
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amacleod at redhat dot com @ 2023-06-09 13:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Oh, I see.. there's a second problem, and that is that range_cast doesn't
check if the type is supported before it blindly sets it to varying :-P
One more patcxh coming today to deal with that.. I was going to move cast to
the header file anyway, I will tweak the definition at the same time.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (9 preceding siblings ...)
2023-06-09 13:14 ` amacleod at redhat dot com
@ 2023-06-09 13:58 ` amacleod at redhat dot com
2023-06-09 16:37 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amacleod at redhat dot com @ 2023-06-09 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Actually, I do not think that range_cast is the root problem upon further
review... Discussing it with Aldy, I think there is a typo in the code:
value_range resvr = vr;
range_cast (resvr, param_type);
That should be
Value_Range resvr = vr;
range_cast (resvr, param_type);
value_range is the legacy int_range (which should be going away this release)
and Value_Range is the new range type that supports multiple ranges, including
unsupported ranges for UNDEFINED and VARYING.
So the set_varying call in range_cast is trying to cast the integer to a
different class which isnt supported by int_range.
BUt then, i see that ipa_set_jfunc_vr (jfunc, &resvr); is expecting a
value_range *, so perhapsd this is really a can of worms. we're checking that
arg is an irange supported, we should also perhaps just check that param_type
is too...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (10 preceding siblings ...)
2023-06-09 13:58 ` amacleod at redhat dot com
@ 2023-06-09 16:37 ` cvs-commit at gcc dot gnu.org
2023-06-10 1:44 ` amacleod at redhat dot com
2023-06-13 9:16 ` jamborm at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-09 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:
https://gcc.gnu.org/g:5612aa4d06594166c0ee848dc733bb9458c1bdbf
commit r14-1662-g5612aa4d06594166c0ee848dc733bb9458c1bdbf
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Fri Jun 9 10:17:59 2023 -0400
Also check type being cast to
before casting into an irange, make sure the type being cast into
is also supported.
PR ipa/109886
* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Check param
type as well.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (11 preceding siblings ...)
2023-06-09 16:37 ` cvs-commit at gcc dot gnu.org
@ 2023-06-10 1:44 ` amacleod at redhat dot com
2023-06-13 9:16 ` jamborm at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: amacleod at redhat dot com @ 2023-06-10 1:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> ---
Let me know if the buildbot likes that change :-)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
2023-05-17 8:55 [Bug ipa/109886] New: UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c jamborm at gcc dot gnu.org
` (12 preceding siblings ...)
2023-06-10 1:44 ` amacleod at redhat dot com
@ 2023-06-13 9:16 ` jamborm at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jamborm at gcc dot gnu.org @ 2023-06-13 9:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #13)
> Let me know if the buildbot likes that change :-)
The buildbot seems happy now, thanks!
^ permalink raw reply [flat|nested] 15+ messages in thread