------- 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