[PATCH, ARM] Reintroduce minipool ranges for zero-extension insn patterns

Eric Botcazou ebotcazou@adacore.com
Wed Jun 19 09:06:00 GMT 2013


> The following patch removed pool_range/neg_pool_range attributes from
> several instructions as a cleanup, which I believe to have been
> incorrect:
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01036.html
> 
> On a Mentor-local branch, this caused problems with instructions like:
> 
> (insn 77 53 87 (set (reg:SI 8 r8 [orig:197 s.4 ] [197])
>         (zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> [7 S2 A16]))) [...] 161 {*arm_zero_extendhisi2_v6} (nil))
> 
> The reasoning behind the cleanup was that the instructions in question
> have no immediate constraints -- but the minipool code is used for more
> than just immediates, e.g. in the above case where a symbol reference
> ("m") is loaded.

Probably the most reported ARM bug (PR target/49423) and a clear regression.

> I don't have a test case for the problem on mainline at present, but I
> believe it is still a latent bug. Tested with the default multilibs (ARM
> & Thumb mode) on arm-none-eabi, with no regressions. (The patch has
> also been tested with more multilibs on our local branches for a while,
> and I did ensure previously that it did not adversely affect Bernd's
> patch linked above.)

Can you attach it to PR target/49423?  Anybody doing serious testing with an 
ARM compiler will run into it in some configuration so it would be nice to 
have a single source for the fix (although that ought to be the tree...).

-- 
Eric Botcazou



More information about the Gcc-patches mailing list