Created attachment 36792 [details]
build log

Well the final error is :

/home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:198:13: internal compiler error: in emit_library_call_value_1, at calls.c:4401
     return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \
             ^
/home/angelo/archivio/aziende/sysam/buildall/gcc-5.2.0/libgcc/config/m68k/linux-atomic.c:203:1: note: in expansion of macro 'SUBWORD_BOOL_CAS'
 SUBWORD_BOOL_CAS (unsigned char,  1)

I tried also gcc 5.3.0, same error using --with-arch=cf.

Seems like m68k branch is not considered at all.

Confirmed.  Building libgcc for m68k-linux-gnu --with-arch=cf fails for every GCC version from 4.7 onwards (4.6 didn't have linux-atomic.c, so I'm not sure if this counts as a regression).

Errors with current mainline:

/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c: In function '__sync_bool_compare_and_swap_1':
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:197:13: internal compiler error: in emit_library_call_value_1, at calls.c:4624
     return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:202:1: note: in expansion of macro 'SUBWORD_BOOL_CAS'
 SUBWORD_BOOL_CAS (unsigned char,  1)
 ^~~~~~~~~~~~~~~~
0x6a7dc7 emit_library_call_value_1
        /scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4623
0x6acb5f emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, int, ...)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4817
0x9e576e expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*, rtx_def*, rtx_def*, bool, memmodel, memmodel)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/optabs.c:6210
0x690b1b expand_builtin_compare_and_swap
        /scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:5059
0x69db77 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:6606
0x7bdd4d expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:10773
0x7c8e4f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5548
0x7ca790 expand_assignment(tree_node*, tree_node*, bool)
        /scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5317
0x6bb4ba expand_call_stmt
        /scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:2666
0x6bb4ba expand_gimple_stmt_1
        /scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3581
0x6bb4ba expand_gimple_stmt
        /scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3747
0x6bd28e expand_gimple_basic_block
        /scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:5754
0x6c3176 execute
        /scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:6368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

*** Bug 53833 has been marked as a duplicate of this bug. ***

Created attachment 40117 [details]
preprocessed source

Preprocessed source of file causing ICE attached.  Compile with: -S -g -O2 -fPIC -fbuilding-libgcc -fno-stack-protector linux-atomic.i

Compiler configured with: /scratch/jmyers/glibc/many7/src/gcc/configure '--prefix=/scratch/jmyers/glibc/many7/install/compilers/m68k-linux-gnu-coldfire' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--target=m68k-glibc-linux-gnu' '--with-sysroot=/scratch/jmyers/glibc/many7/install/compilers/m68k-linux-gnu-coldfire/sysroot' '--with-arch=cf' --disable-multilib --disable-libsanitizer --disable-libssp '--with-gmp=/scratch/jmyers/glibc/many7/install/host-libraries' '--with-mpfr=/scratch/jmyers/glibc/many7/install/host-libraries' '--with-mpc=/scratch/jmyers/glibc/many7/install/host-libraries' '--enable-languages=c' --disable-shared --disable-threads --disable-libatomic --disable-decimal-float --disable-libffi --disable-libgomp --disable-libitm --disable-libmpx --disable-libquadmath --without-headers --with-newlib '--with-glibc-version=2.24'

This is a bad interaction between PREFERRED_STACK_BOUNDARY and PUSH_ROUNDING, but there's a deeper code generation issue that needs to be looked at as well.

So background.  A push insn on the m68k is actually a store using a pre-decrement addressing mode and register a7. ie -(%a7) aka -(%sp)

The original m68k family special cased byte pushes so that if you did something like

mov.b <input>,-(%sp)

You would actually push 2 bytes on the stack instead of 1 to ensure the stack was always 2 byte aligned.  This quirk was only done when using sp/a7 in predec/postinc addressing modes as push/pop insns.

The coldfire family did away with that quirk and no longer special cases sp/a7 in those addressing modes.


GCC uses PUSH_ROUNDING to describe the behavior of the original m68k family.  As expected it's behavior is now conditional on TARGET_COLDFIRE:

/* On the 680x0, sp@- in a byte insn really pushes a word.
   On the ColdFire, sp@- in a byte insn pushes just a byte.  */
#define PUSH_ROUNDING(BYTES) (TARGET_COLDFIRE ? BYTES : ((BYTES) + 1) & ~1)


Another quirk of the Coldfire family is that it really prefers its stack stack 32 bit aligned.  It impacts all kinds of things.  So not surprisingly m68k has (m68k.h and linux.h respectively):

/* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
#define PREFERRED_STACK_BOUNDARY \
  ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)


#undef PREFERRED_STACK_BOUNDARY
#define PREFERRED_STACK_BOUNDARY 32


So far, so good on the target bits.    We define various sync builtins, including:

DEF_SYNC_BUILTIN (BUILT_IN_SYNC_VAL_COMPARE_AND_SWAP_1,
                  "__sync_val_compare_and_swap_1",
                  BT_FN_I1_VPTR_I1_I1, ATTR_NOTHROWCALL_LEAF_LIST)

ie,

char __sync_val_compare_and_swap_1 (void *, char, char)

These are called as libcalls, not normal functions.  This distinction is important.  

So when we make a call to __sync_val_compare_and_swap, on coldfire we push 6 bytes of data.  This then runs afoul of this assert in emit_library_call_value_1:


 /* Stack must be properly aligned now.  */
  gcc_assert (!(stack_pointer_delta
                & (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1)));

(STACK_POINTER_DELTA will be 6).


But wait, it's actually worse.  While the caller seems to want to push bytes, the callee seems to be using a more standard ABI where the usual promotions occur.  ie, expects the caller to have pushed 32bit words.

So not only do we have the assertion to deal with, we really need to address the ABI mismatch.  What a mess.  There's a reasonable chance I will not get this addressed prior to gcc-7.  m68k just isn't that high a priority.

Can't we disable compilation of linux-atomic.c for gcc7 then?
So that at least it is possible to build a toolchain for coldfire?

Unsure.  I thought libstdc++ used some of the libatomic facilities under the hood so we'd just replace one build failure with another.

It might also mess up the older 68k systems (assuming I'm wrong about the ABI implications and they are in fact working properly) to just remove libatomic from the builds.

In short, I don't have enough information to recommend a reasonable course of action on this BZ.

To answer Waldemar's question, that is exactly how I worked around the problem for gcc 4.7 and 4.8 in 2012 (see Bug 53833).  That enabled me to have a functioning gcc for ColdFire.  I used it to fix broken stack limit checking for ColdFire processors.  I never tried to use it for building any system components, such as Jeff describes.

The fact that libcalls aren't using the C ABI is likely hurting everyone.

I talking about following change:
diff -Nur gcc.orig/libgcc/config.host gcc/libgcc/config.host
--- gcc.orig/libgcc/config.host   2016-02-26 21:02:28.000000000 +0100
+++ gcc/libgcc/config.host        2016-04-29 09:18:40.377989160 +0200
@@ -812,7 +812,7 @@
 m68k*-*-openbsd*)
        ;;
 m68k-*-uclinux*)       # Motorola m68k/ColdFire running uClinux with uClibc
-       tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
+       tmake_file="$tmake_file m68k/t-floatlib"
        md_unwind_header=m68k/linux-unwind.h
        ;;
 m68k-*-linux*)                 # Motorola m68k's running GNU/Linux


This would allow to create a working toolchain. 
m68k-nommu (coldfire) is only supported by uClibc-ng and not GNU libc.
There is only support for Linuxthreads, so TLS/libatomic is disabled at configure time.
C++ support still seems to work fine.
The m68k (full MMU) support isn't changed with this patch.

From the embedded build system maintainer view, I think the patch is fine to at least
get some working toolchain until the ICE is solved.

The patch is used for some time in Buildroot/OpenADK.

linux-atomic is independent of libc and libpthread, it implements compiler intrinsics and only depends on the kernel support for CAS on Coldfire.

Okay.
So what is your opinion, how we proceed here?

(In reply to Waldemar Brodkorb from comment #11)

> diff -Nur gcc.orig/libgcc/config.host gcc/libgcc/config.host
> --- gcc.orig/libgcc/config.host   2016-02-26 21:02:28.000000000 +0100
> +++ gcc/libgcc/config.host        2016-04-29 09:18:40.377989160 +0200
> @@ -812,7 +812,7 @@
>  m68k*-*-openbsd*)
>         ;;
>  m68k-*-uclinux*)       # Motorola m68k/ColdFire running uClinux with uClibc
> -       tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
> +       tmake_file="$tmake_file m68k/t-floatlib"
>         md_unwind_header=m68k/linux-unwind.h
>         ;;
>  m68k-*-linux*)                 # Motorola m68k's running GNU/Linux

This is exactly the same patch I was referring to in Comment #9 that I used to work around the problem for gcc 4.7 and 4.8 in 2012 (see Bug 53833).

Jeffrey, seems gcc 7 is coming soon, any chance getting this resolved?

Any news on this bug?

Currently I'm trying to get a 5485 board working with linux and I'm facing the fact that there's no working toolchain available anymore.

It would be great to have this old boards up and running again

Hi Carlos,

maybe you can try one of these 2 toolchains i prepared years ago:

http://sysam.it/toolchains.html

Regads,
Angelo

On 25/06/2017 20:40, csotoalonso at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
>
> Carlos Soto <csotoalonso at gmail dot com> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |csotoalonso at gmail dot com
>
> --- Comment #16 from Carlos Soto <csotoalonso at gmail dot com> ---
> Any news on this bug?
>
> Currently I'm trying to get a 5485 board working with linux and I'm facing the
> fact that there's no working toolchain available anymore.
>
> It would be great to have this old boards up and running again
>

(In reply to angelo from comment #17)
> Hi Carlos,
> 
> maybe you can try one of these 2 toolchains i prepared years ago:
> 
> http://sysam.it/toolchains.html
> 
> Regads,
> Angelo
> 

Hi angelo,
thanks for pointing that. But unfortunately those toolchain lack a sysroot so they are not suitable for Buildroot, the tool I use to create the root fs.

So, I'm stuck for the time being...

Author: jsm28
Date: Wed Jan 24 23:36:29 2018
New Revision: 257032

URL: https://gcc.gnu.org/viewcvs?rev=257032&root=gcc&view=rev
Log:
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.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/m68k/m68k.c

Fixed for GCC 8.

I can confirm that this fixes the problem even for gcc 7.x.
Any chance to get it included into gcc 7 branch?

No regression found while running the uClibc-ng testsuite inside
qemu-system-m68k.

Thanks a lot!

What do the m68k maintainers think about the suggestion of backporting to 
GCC 7 (and for that matter GCC 6)?  This is a regression in the sense of 
"libgcc used to build for ColdFire, then that broke", though not (as far 
as I know) a regression in the sense of "this fixed .i file used to build, 
then that broke".

I've got no objection Joseph.  But I think you need to make your case to Richi and Jakub -- I doubt they're on CC for this BZ :-)

Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165

URL: https://gcc.gnu.org/viewcvs?rev=257165&root=gcc&view=rev
Log:
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.

	Backport from mainline
	2018-01-24  Joseph Myers  <joseph@codesourcery.com>

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

Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/config/m68k/m68k.c

Also now fixed for GCC 7.4.