Currently many tests for string builtin functions fail on sh64-unknown-linux-gnu. Here is a small test case:
extern void abort (void); char buf[64]; int main (void) { __builtin_strcpy (buf, "mystring"); if (strcmp (buf, "mystring") != 0) abort (); __builtin_strcpy (buf, "mystring"); if (strcmp (buf, "mystring") != 0) abort (); return 0; } With -O3, the register R11 is used to hold 8-byte of "mystring" for the first __builtin_strcpy call. The value in R11 is reused with the 2nd __builtin_strcpy call. When strcmp is dynamically linked, the upper 32-bit of R11 is clobbered by the first call of strcmp. Then the 2nd strcmp returns false. The backend defines HARD_REGNO_CALL_PART_CLOBBERED so to notify that the upper 32-bit of R11 may be clobbered for SHmedia: /* Only the lower 32-bits of R10-R14 are guaranteed to be preserved across SHcompact function calls. We can't tell whether a called function is SHmedia or SHcompact, so we assume it may be when compiling SHmedia code with the 32-bit ABI, since that's the only ABI that can be linked with SHcompact code. */ #define HARD_REGNO_CALL_PART_CLOBBERED(REGNO,MODE) \ (TARGET_SHMEDIA32 \ && GET_MODE_SIZE (MODE) > 4 \ && (((REGNO) >= FIRST_GENERAL_REG + 10 \ && (REGNO) <= FIRST_GENERAL_REG + 15) \ || TARGET_REGISTER_P (REGNO) \ || (REGNO) == PR_MEDIA_REG)) but it seems that now HARD_REGNO_CALL_PART_CLOBBERED doesn't affect the register allocation. -- Summary: [4.4 Regression] wrong register use on sh64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC target triplet: sh64-unknow-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633