------- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-23 10:20
-------
The problem seems to be in Richard's patch
(http://article.gmane.org/gmane.comp.gcc.patches/130602) checked in r120961.
All and all, it seems that revision 120961 should be reverted to enable 'T'
constraint for (flag_pic && !TARGET_PCREL).
The 's' constraint is defined as
==
case 's':
if (CONST_INT_P (op)
|| (GET_CODE (op) == CONST_DOUBLE
&& GET_MODE (op) == VOIDmode))
break;
case 'i':
if (CONSTANT_P (op))
win = 1;
break;
==
So, unless I'm missing something, the statement
"... 's' doesn't accept anything if flag_pic"
is just wrong.
FYI, the story behind 'T' constraint is described in comment in r27576:
+ In parallel with these new predicates, two new constraint letters
+ were defined: 'S' and 'T'. 'S' is the -mpcrel analog of 'm'.
+ 'T' replaces 's' in the non-pcrel case. It is a no-op in the pcrel case.
+ In the pcrel case 's' is only valid in combination with 'a' registers.
+ See addsi3, subsi3, cmpsi, and movsi patterns for a better understanding
+ of how these constraints are used.
+
...
+ All of the ugliness with predicates and constraints is due to the
+ simple fact that the m68k does not allow a pc-relative addressing
+ mode as a destination. gcc does not distinguish between source and
+ destination addresses. Hence, if we claim that pc-relative address
+ modes are valid, e.g. GO_IF_LEGITIMATE_ADDRESS accepts them, then we
+ end up with invalid code. To get around this problem, we left
+ pc-relative modes as invalid addresses, and then added special
+ predicates and constraints to accept them.
--
mkuvyrkov at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdsandiford at googlemail
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
