[Bug target/52441] New: SH Target: Double sign/zero extensions for function arguments

[olegendo at gcc dot gnu.org]

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

             Bug #: 52441
           Summary: SH Target: Double sign/zero extensions for function
                    arguments
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: olege...@gcc.gnu.org
                CC: kkoj...@gcc.gnu.org
            Target: sh*-*-*


When passing function arguments with < 32 bits, sign/zero extension happens on
both sides of a function call: in the caller and in the callee.

int yy (char a, char b)
{
  return a + b;
}

int xx (int a, int b)
{
  return yy (a, b);
}

compiled with -Os -fno-inline:


_yy:
    exts.b    r4,r0
    exts.b    r5,r5
    rts
    add    r5,r0


_xx:
    mov.l    .L6,r0
    exts.b    r4,r4
    jmp    @r0
    exts.b    r5,r5

    .align 2
.L6:
    .long    _yy

The sign/zero extensions in the caller (_xx) are not emitted when using the
original Renesas ABI (-mrenesas), which is correct.

Maybe this double sign/zero extension has some historical reason for some ABI
backwards compatibilities in the GNU SH ABI... but shouldn't it actually be
safe to leave out the sign/zero extensions on one side of the function call
(either caller or callee)?


Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20120227 (experimental) (GCC)