This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/52441] New: SH Target: Double sign/zero extensions for function arguments
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 29 Feb 2012 21:13:37 +0000
- Subject: [Bug target/52441] New: SH Target: Double sign/zero extensions for function arguments
- Auto-submitted: auto-generated
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: unassigned@gcc.gnu.org
ReportedBy: olegendo@gcc.gnu.org
CC: kkojima@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)