Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).
authorJoseph Myers <joseph@codesourcery.com>
Wed, 24 Jan 2018 23:36:29 +0000 (23:36 +0000)
committerJoseph Myers <jsm28@gcc.gnu.org>
Wed, 24 Jan 2018 23:36:29 +0000 (23:36 +0000)
commitd3719ee2c078a1518c9e21efae0cf438d4ffb8d6
tree78006b330fd44f5969627c5072238fcce69394a2
parent5e77d9b130abdd5878557d34839e1b159a7f68ef
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).

PR target/68467 is libgcc failing to build for m68k-linux-gnu
configured for ColdFire.

Jeff has an analysis in the PR identifying the problem as resulting
from the callers of libcalls with 1-byte or 2-byte arguments wanting
to push just 1 or 2 bytes on the stack, while the libcall
implementations have the normal C ABI and expect 4-byte arguments.
For normal C functions, I believe the TARGET_PROMOTE_PROTOTYPES
definition would ensure such arguments get passed as 4-byte, but that
does not apply for libcalls.

This patch fixes the issue by defining TARGET_PROMOTE_FUNCTION_MODE
for m68k.  The definition is conservative, only applying promotions in
the case of arguments to libcalls; otherwise it returns the unpromoted
type, which I believe matches what the default implementation of the
hook would have done on m68k.

I have tested that this fixes the libgcc build for ColdFire, and, in
conjunction with one glibc patch, this enables glibc to build cleanly
for ColdFire and to pass the compilation parts of the glibc testsuite
except for one test unrelated to this patch (while glibc and the
compilation parts of the testsuite continue to build OK for
non-ColdFire m68k, as expected).  I have *not* run any GCC tests for
this patch, or any execution tests for m68k.

PR target/68467
* config/m68k/m68k.c (m68k_promote_function_mode): New function.
(TARGET_PROMOTE_FUNCTION_MODE): New macro.

From-SVN: r257032
gcc/ChangeLog
gcc/config/m68k/m68k.c