It seems to be the change to arm_regno_class relating to PC_REGNUM. I see
scal-to-vec1.c failing with just that, or that in combination with the changes
to cfgexpand.c+varasm.c.
And scal-to-vec1.c is OK on -fPIC if I apply the changes to cfgexpand.c,
varasm.c, and arm.c (arm_hard_regno_ok), i.
On Wed, 17 Sep 2014, Alan Lawrence wrote:
> We've just noticed this patch causes an ICE in
> gcc.c-torture/execute/scal-to-vec1.c at -O3 when running with -fPIC on
> arm-none-linux-gnueabi and arm-none-linux-gnueabihf; test logs:
Which part causes the ICE? The arm_hard_regno_mode_ok change relat
We've just noticed this patch causes an ICE in
gcc.c-torture/execute/scal-to-vec1.c at -O3 when running with -fPIC on
arm-none-linux-gnueabi and arm-none-linux-gnueabihf; test logs:
spawn /tmp/alan/buildarm-none-linux-gnueabi/obj/gcc4/gcc/xgcc -B/tmp/alan/builda
rm-none-linux-gnueabi/obj/gcc4/g
On 08/22/2014 02:14 PM, Joseph S. Myers wrote:
> Tested with no regressions for cross to arm-none-eabi (it also fixes
> failures of gcc.dg/noncompile/920507-1.c, which is PR 61330). OK to
> commit?
>
> 2014-08-22 Joseph Myers
>
> PR target/60606
> PR target/61330
> * varasm.
PR 60606 reports an ICE on ARM when declaring a register variable in
register pc. Discussion in that bug suggests this usage should be
considered invalid and give an error. It turns out similar ICEs also
occur (after errors) for other cases of invalid register variables.
This patch fixes at leas
