[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets

[amodra at bigpond dot net dot au]

------- Comment #19 from amodra at bigpond dot net dot au  2006-03-27 01:41 -------
After applying the patch, I decided I really ought to find where the regression
from 4.0 occurred.  It's a pity I didn't do that before developing the patch..
To my surprise I found that on the face of it, 4.0 ought to have the same
problem, because it has exactly the same peephole.  A debug session revealed
that 4.0 doesn't think that (subreg:DF (reg:DI 3 3 [128]) 0) is a valid
gpc_reg_operand for e500 double target, while 4.1 does.  After some
head-scratching, I discovered the reason for this is the TARGET_IEEEQUAD change
to rs6000.h:CANNOT_CHANGE_MODE_CLASS (well, really, it's the change to use IBM
extended double for powerpc-linux targets).

The first few lines of this macro are:

#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)                         \
  (!TARGET_IEEEQUAD                                                       \
   && GET_MODE_SIZE (FROM) >= 8 && GET_MODE_SIZE (TO) >= 8                \
   ? 0                                                                    \

This of course interacts badly with later TARGET_E500_DOUBLE tests for DFmode
and DImode, because now that TARGET_IEEEQUAD is false for linuxspe, we never
get to make the TARGET_E500_DOUBLE checks.  At the minimum, the
TARGET_E500_DOUBLE checks ought to be done before this test allows a zero
return.

These lines were added here
        PR target/11848
        * rs6000.h (CANNOT_CHANGE_MODE_CLASS): Allow change of mode
        in floating-point registers between TFmode and DImode.

Really, I think it would be better to check for TFmode<->DImode explicitly
rather than the rather obscure check that Geoff added.  We have quite a few
modes that have size greater than eight.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459