https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80401
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-04-13
CC| |meissner at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Michael Meissner <meissner at gcc dot gnu.org> ---
While the underlying bug is due to an LRA change, the fix for each of these in
the rs6000 backend is likely to be different.
The first failure (dimode_off) is one of these tests that are so hard-wired to
the compiler that it likely needs to change every so often.
Yes, it can become a regression, but it only happens on a power8/power9 system
and the offset of a load/store is not divisible by 4. Due to alignment issues,
the DImode load/store is almost always divisible by 4, unless you are loading
up unaligned memory, or specifically add odd numbers to a char * pointer and
convert it to a long pointer. These should be rare in practice.
The underlying reason is the LD and STD instructions use the bottom 2 bits for
encoding the instruction, while the LFD and STFD instructions allows a full
16-bit offset.
The second failure listed is 79308-1.c that makes sure an optimization I put in
still works. However, since the optimization is converting a char/short value
to __float128 on a Power9
