> 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
