[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 --- Comment #7 from Vladimir Makarov --- Author: vmakarov Date: Wed Jan 30 21:49:23 2019 New Revision: 268404 URL: https://gcc.gnu.org/viewcvs?rev=268404=gcc=rev Log: 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * lra-constraints.c (simplify_operand_subreg): Reload memory in subreg if the address became invalid. 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * gcc.target/i386/pr87246.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr87246.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 --- Comment #6 from Vladimir Makarov --- I am working on this. I hope to fix the PR this week.
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |7.5
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 --- Comment #5 from Jakub Jelinek --- And that hook indeed returns the need for secondary reload there, so looks like LRA bug for not honoring it?
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Started with r233107.
>
> Slightly adjusted testcase:
>
> __int128 a;
> int b;
>
> void
> bar (__int128 *x)
> {
> if (*x != 0)
> {
> a = 0;
> b = b <= *x;
> }
> }
>
> void
> foo (unsigned int x)
> {
> bar (x + 1);
> }
>
> This is on
> (mem:TI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ]) (const_int 1 [0x1]
> which matches the predicate of the *movti_internal instruction -
> general_operand, but the selected alternative needs offsettable memory.
> LRA attempts:
> (mem:DI (plus:DI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ])
> (const_int 1 [0x1])))
> (const_int 8 [0x8])) [1 *_3+8 S8 A64])
> but that isn't a valid offsettable address, it should have instead forced
> the zero_extend into a register.
>
> Or should some reload hook in the backend tell LRA that it should do that if
> it wants an offsettable address out of that?
This should be handled in ix86_secondary_reload TARGET_SECONDARY_RELOAD hook,
which has the code to handle
/* Double-word spills from general registers to non-offsettable memory
references (zero-extended addresses) require special handling. */
via reload_noff_{load,store} patterns.
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Started with r233107.
Slightly adjusted testcase:
__int128 a;
int b;
void
bar (__int128 *x)
{
if (*x != 0)
{
a = 0;
b = b <= *x;
}
}
void
foo (unsigned int x)
{
bar (x + 1);
}
This is on
(mem:TI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ]) (const_int 1 [0x1]
which matches the predicate of the *movti_internal instruction -
general_operand, but the selected alternative needs offsettable memory.
LRA attempts:
(mem:DI (plus:DI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ])
(const_int 1 [0x1])))
(const_int 8 [0x8])) [1 *_3+8 S8 A64])
but that isn't a valid offsettable address, it should have instead forced the
zero_extend into a register.
Or should some reload hook in the backend tell LRA that it should do that if it
wants an offsettable address out of that?
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 Richard Biener changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Known to work||5.5.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
