[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-06 10:27:03 UTC --- Working on a fix.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-05 09:14:46 UTC --- If the folder or GIMPLE passes see it is a shift by 32, they fold it away (with or without a warning), so the fact that it is a constant larger than bitsize of the shifted operand has to be seen only during RTL optimizations.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 08:17:56 UTC --- In any case, this looks like a clear backend bug, as it allows const_int 32 in the operand (through the use of M constraint), but then doesn't handle it at all in arm_output_shift (it forces use of %S3 on it and that requires 0 .. 31 constant, not 0 .. 32). And while the code has undefined behavior, if you never invoke it, you should still be able to have it in a valid program.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-05 07:01:42 UTC --- Definitely a back-end bug. I'm not disputing that. My surprise is that this hasn't bitten us long before now, since the code has been this way for well over ten years.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-04 07:01:07 UTC --- Confirmed. I'm a bit wary of just truncating the value. Shifts by 32 may be valid in the ARM back-end in some circumstances where we're using the shift as part of setting up the flags. Fixing this fully would require getting rid of shift_operator and replacing it with iterators. But that's a pretty radical overhaul. Long term that might well be worthwhile, but not this close to a release.
