[Bug target/37633] New: [4.4 Regression] wrong register use on sh64

[kkojima at gcc dot gnu dot org]

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