https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #9 from Jakub Jelinek ---
If we wanted to support just INSN_UIDs up to 0x5554, it could be even just
lra_insn_recog_data_len = index * 3U / 2 + 1;
Looking around, vec.cc has similar limitation, it uses unsigned rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #6 from rguenther at suse dot de ---
On Thu, 30 Nov 2023, zsojka at seznam dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
>
> --- Comment #5 from Zdenek Sojka ---
> Thank you for the evaluation.
>
> - params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #5 from Zdenek Sojka ---
Thank you for the evaluation.
I am not reporting ICEs (assertion / checking failures) due to overflows caused
by extreme --param values:
- this param is typically causing ICEs due to insn UID overflow
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #4 from Alexandre Oliva ---
yeah, its intended use case is for debugging -fcompare-debug fails, reducing
superfluous differences between rtl dumps.
In theory GCC may overflow insn uids regardless of this param, and if guarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
--- Comment #3 from Richard Sandiford ---
This parameter is firmly into “developer only” territory, so I'm not sure we
should try to enforce a range. IMO we should just recommend that the parameter
isn't included in fuzz testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411
Richard Biener changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
