(In reply to comment #0)

>    0x80136f0e <+30>:    movel #-2140172272,%d0
>    0x80136f14 <+36>:    movel #-2140172268,%d1
>    0x80136f1a <+42>:    andil #255,%d2
>    0x80136f20 <+48>:    movel %d2,%sp@-
>    0x80136f22 <+50>:    movel %d1,%sp@-
>    0x80136f24 <+52>:    movel %d0,%sp@-
>    0x80136f26 <+54>:    jsr 0x80187a8a <system__string_ops__str_concat_sc>
> […]
> 
> See how %d0 and %d1 (arguments to System.String_Ops.Str_Concat) have immense
> sizes. I don’t know the Ada calling conventions though, and three things are
> pushed, yet "." is a one-byte string, and Direct_Separator is only a char.

Translated to hex the values for d0 and d1 are 0x806f9010 and 0x806f9014, which look like pointers into the executable itself.  They're probably pointers to string values or something like that.

> Program received signal SIGSEGV, Segmentation fault.
> 0xc014d428 in memcpy (dstpp=0x8018668a, srcpp=0x80a2688e, len=2149082762) at
> memcpy.c:61

'len' is obviously bogus, in hex it is 0x8018668a, which equals dstpp!  Either memcpy() is utterly broken (unlikely) or something gave it broken parameters.

I see a different crash in opt___elabs, but perhaps related: __gnat_malloc is declared to returned a pointer, but it is aliased to the Ada function System.Memory.Alloc which returns a value of type System.Address, and this is apparently not treated as a pointer, thus the value is returned in %d0.  But the caller expects the returned value in %a0.

Actually, the backtrace is bogus. The problem lies here:

hostparm___elabs:
.LFB0:
        .file 1 "../../src/gcc/ada/hostparm.ads"
[…]
        move.l %d0,hostparm__Tnormalized_cwdS___SIZE_A_UNIT
        move.l %d0,-(%sp)   
        .cfi_escape 0x2e,0x4
        jsr __gnat_malloc
        move.l %a0,%d2
        move.l hostparm__Tnormalized_cwdS___SIZE_A_UNIT,-(%sp)
        move.l hostparm__R6s,-(%sp)
0x8013707c  move.l %a0,-(%sp)   
        .cfi_escape 0x2e,0xc
0x8013707e  jsr memcpy
0x80137084  move.l %d2,hostparm__normalized_cwd
        lea (16,%sp),%sp
        .loc 1 38 0
        movem.l -24(%fp),#252
        unlk %fp
        rts
        .cfi_endproc

The call to memcpy above SIGSEGVs. Upon entering memcpy@plt, the
stack looks as follows:

0xefcdaab0:     0x80137084      0x8018668a      0x80a2688e      0x00000002
                ret addr        dst             src             len

(gdb) x 0x80a2688e
0x80a2688e <system__secondary_stack__chunk+24>: 0x2e2f0000
(gdb) x 0x8018668a
0x8018668a <system__soft_links__abort_undefer_nt>:      0x4e560000

tg@zigo:~/Xg/gcc-4.4-4.4.6/b68k $ nm gcc/gnat1 | fgrep -we system__secondary_stack__chunk -e system__soft_links>
80a26876 b system__secondary_stack__chunk
8018668a T system__soft_links__abort_undefer_nt

So basically, this tries to overwrite space at T (.text segment).
__gnat_malloc is apparently assumed to return in a0…

… grepping gives:

ada/socket.c:extern void *__gnat_malloc32 (__SIZE_TYPE__);
ada/raise.h:extern void *__gnat_malloc          (__SIZE_TYPE__);
ada/i-cstrin.adb:   pragma Import (C, Memory_Alloc, "__gnat_malloc");
ada/s-memory.ads:   pragma Export (C, Alloc,   "__gnat_malloc");

I believe we may have our culprit, considering m68k return value locations. Phew!

(In reply to comment #2)
> apparently not treated as a pointer, thus the value is returned in %d0.  But
> the caller expects the returned value in %a0.

Ah, I see. We both got the same guess then, which makes me kind of happy
to see that the analysis seems good.

I lost quite some time tracking down my first error though (even annotating
EVERY line of a disassembly with what it does), only to find out it now
segfaulted later… ☺

(In reply to comment #2)
> the caller expects the returned value in %a0.

It’s even worse, __gnat_malloc contains:

        jsr malloc
        addq.l #4,%sp
        move.l %d0,-8(%fp)

Apparently, the Ada functions that are {Im,Ex}port’ed all assume
they get their values in d0 not a0…

I wonder if this is a conceptual problem preventing Ada to work
with the m68k ELF ABI. How does vxworks/m68k (which, apparently,
has a GNAT port) manage it? (Even if we “fix” the Export, the
Import of libc malloc will still fail… would this work if some
types were handled specially (like System.Address)? I wonder how
many third-party programmes would break on m68k when they have C
imports with uncleanly specified types then…)

That's not a problem because all pointer values are also returned in %d0 for compatibility.

OK, so the fix is that the System.Address type must be changed in GNAT
to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT
developer please working on this?

Created attachment 24491 [details]
patch fixing m68k function call abi issues in gnat

WRT the the m68k function call ABI issues, I believe there are only a few cases where gnat does something which breaks m68k:

- __gnat_malloc is defined in Ada to return Address (integer, so in d0), but it's called from a couple of places via fake "extern" declarations that pretend it returns void* (pointer, so in a0).  The attached patch fixes the two call sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well as the internal fake prototype (init_gigi_decls).
- Source code inspection showed that get_jmpbuf_address probably suffers from the same issue (mismatching decl and use via wrong intermediate fake prototype) so I fixed that too.

There are a number of pointer-returning C library routines that are imported as-is with fake prototypes that declare them as returning Address.  While wrong, this should work since the ABI returns pointers in both d0 and a0.

With these fixes in place I can bootstrap gnat et al and the resulting binaries can be executed:

aranym5_21_~/gnatroot/bin/gnat
GNAT 4.4.7 20110419 (prerelease)
Copyright 1996-2008, Free Software Foundation, Inc.

List of available commands

gnat bind               gnatbind
gnat chop               gnatchop
gnat clean              gnatclean
gnat compile            gnatmake -f -u -c
gnat check              gnatcheck
gnat sync               gnatsync
gnat elim               gnatelim
gnat find               gnatfind
gnat krunch             gnatkr
gnat link               gnatlink
gnat list               gnatls
gnat make               gnatmake
gnat metric             gnatmetric
gnat name               gnatname
gnat preprocess         gnatprep
gnat pretty             gnatpp
gnat stack              gnatstack
gnat stub               gnatstub
gnat xref               gnatxref

Commands find, list, metric, pretty, stack, stub and xref accept project file switches -vPx, -Pprj and -Xnam=val

However, compiling the most trivial Ada program now fails with an assertion:

aranym5_22_cat conftest.adb 
procedure conftest is begin null; end conftest;
aranym5_23_~/gnatroot/bin/gcc -S conftest.adb
+===========================GNAT BUG DETECTED==============================+
| 4.4.7 20110419 (prerelease) (m68k-unknown-linux-gnu) Assert_Failure einfo.adb:1748|
| Error detected at system.ads:153:5                                       |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

conftest.adb

compilation abandoned

In case I missed some return value ABI fixups I hacked the m68k backend to return pointers in a0+d0 as before but always fetch them from d0, but it made no difference.

The only potential issues I'm aware of now are endianess and alignment differences between the bootstrap host (i686-linux in my case) and m68k.  That's because the bootstrap has to run the host's gnatmake a couple of times to generate the einfo/sinfo/etc thingys, which might not work correctly if the host and target have different endianess or alignment rules.

Since I've bootstrapped gnat for big-endian ARM from little-endian i686 before, I don't think endianess is the problem, so I'm leaning towards m68k's unique alignment rules.

> - __gnat_malloc is defined in Ada to return Address (integer, so in d0), but
> it's called from a couple of places via fake "extern" declarations that pretend
> it returns void* (pointer, so in a0).  The attached patch fixes the two call
> sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well
> as the internal fake prototype (init_gigi_decls).
> - Source code inspection showed that get_jmpbuf_address probably suffers from
> the same issue (mismatching decl and use via wrong intermediate fake prototype)
> so I fixed that too.

I don't think that we want __gnat_malloc to return anything else than a pointer in the GCC representation.  Its DECL node is DECL_IS_MALLOC and had better mimic a canonical malloc as much as possible.

Andreas mentioned a compatibility trick in comment #6.  How is it implemented?

(In reply to comment #9)
> > - __gnat_malloc is defined in Ada to return Address (integer, so in d0), but
> > it's called from a couple of places via fake "extern" declarations that pretend
> > it returns void* (pointer, so in a0).  The attached patch fixes the two call
> > sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well
> > as the internal fake prototype (init_gigi_decls).
> > - Source code inspection showed that get_jmpbuf_address probably suffers from
> > the same issue (mismatching decl and use via wrong intermediate fake prototype)
> > so I fixed that too.
> 
> I don't think that we want __gnat_malloc to return anything else than a pointer
> in the GCC representation.  Its DECL node is DECL_IS_MALLOC and had better
> mimic a canonical malloc as much as possible.

In that case the Ada side of __gnat_malloc has to be changed to use a pointer type rather than Address.  Is Interfaces.C.Strings.chars_ptr acceptible, or is there a better approximation for void* somewhere?

> Andreas mentioned a compatibility trick in comment #6.  How is it implemented?

The effect is that a pointer-valued callee returns its value in both %a0 and %d0.  A caller that has seen the pointer-valued prototype picks up the value from %a0, but a caller that hasn't seen that prototype picks it up from %d0.  The actual implementation is in m68k_function_value.

> In that case the Ada side of __gnat_malloc has to be changed to use a pointer
> type rather than Address.  Is Interfaces.C.Strings.chars_ptr acceptible, or is
> there a better approximation for void* somewhere?

The problem is that pointers drag a heavy machinery in Ada (to make it impossible to introduce the dangling sub-species) so low-level routines don't really want to use pointers, as they (are supposed to) know what they are doing.

> The effect is that a pointer-valued callee returns its value in both %a0 and
> %d0.  A caller that has seen the pointer-valued prototype picks up the value
> from %a0, but a caller that hasn't seen that prototype picks it up from %d0. 

I see, thanks.  What about creating a machine-specific attribute, tentatively named "pointer return", that a m68k-specific version of s-memory.ads would put on the problematic functions?  GNAT already supports machine-specific attributes.  The effect would be the same as the one implemented in m68k_function_value.

Why not patch the frontend to magically make System.Address a pointer type for the backend to deal with? That way, no functions have to be changed, and potential other targets with “weird” calling conventions immediately share in the benefit.

As for the “compatibility trick”, it works the other way around, only when a pointer-returning function is called expecting integers. Here, we have an integer-returning function by mistake.

> Why not patch the frontend to magically make System.Address a pointer type for
> the backend to deal with? That way, no functions have to be changed, and
> potential other targets with “weird” calling conventions immediately share in
> the benefit.

Let's be clear: changing the Ada front-end because of weird ABIs on little-used platforms is pretty much out of question; this issue only arises on m68k AFAIK.

> As for the “compatibility trick”, it works the other way around, only when a
> pointer-returning function is called expecting integers. Here, we have an
> integer-returning function by mistake.

Right, that's precisely why I proposed the attribute.

Partial success: I've just managed to bootstrap gcc-4.1.2 w/ gnat on m68k-linux.  Lots of patches applied though.

Status update: I have a nice stable gcc-4.1.2 with gnat that has bootstrapped itself through approx 10 generations natively on m68k-linux, and the final working patch kit is quite small.

I forward-ported the 4.1.2 patch kit to 4.4.6, added one tweak (don't set DECL_IS_MALLOC on malloc_decl since it doesn't return a pointer type with the kit), but that failed near the end of stage2 with the same assertion as in #c8.

So I now intend to go back a do full bootstraps also with the intermediate 4.2 and 4.3 releases.  That in turn will require some digging to locate whatever m68k-specific patches I'll need for those releases.

4.2.4 (lightly patched) and 4.3.6 (heavily patched) both bootstrap fine with gnat and rebuild themselves without problems.  I'm going to rebuild 4.3.6 with a much smaller patch kit first, then move on to 4.4.6.

4.3.6 w/ gnat rebuilt itself fine with a fairly small patch kit (about 30 wrong-code fixes, almost half of them m68k-specific).  However, 4.4.6 with a similar small patch kit (essentially the 4.3 kit except the ones that were already fixed in upstream 4.4, total about 20 fixes) fails with the same assertion in stage3 I showed before in #c8.

gcc-4.5.3 (vanilla except for 8 m68k-specific patches) works perfectly with gnat and ZCX EH.  The only remaining issue is the bogus return type for __gnat_malloc, which I plan to solve properly by using type-correct replacements for s-memory.ad{s,b}.

I have type-correct s-memory-m68k.ad{b,s} written and tested on x86 (by adding s-memory.adb<s-memory-m68k.adb and ditto for .ads rules to the linux x86 Makefile.in fragment), but when I do this natively on m68k-linux the replacements don't happen for some reason, causing bootstrap to fail in stage3.

Specifically, when I did this on x86 I got a bunch of symbolic links in my objdir matching (I assume) the .ad{b,s} replacements, but on m68k I got no such symlinks at all.  Something weird is going in Makefile.in ...

Have you applied the patch I attached to this bugreport before?

The sections in Makefile.in are actually target specific, and
my patch added one for m68k-linux as:

+ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),)

I’m fairly certain it did pick these when I built it.

The problem is that LIBGNAT_TARGET_PAIRS is applied too late, and stage 1, 2, and 3 gnat1 etc are built out of a fixed set of source files that your target fragment in gcc/ada/gcc-interface/Makefile.in cannot influence (AFAIK).

You can observe this easily with a bootstrap on e.g. i686-linux.  On that platform system.ads should be replaced by system-linux-x86.ads, but the build log clearly shows stage 1, 2, 3 compiling the default gcc/ada/system.ads from the gcc source dir and linking that .o file into gnat1 etc.  It's not until some time after stage 3 that the build directory's gcc/ada/rts/ is populated according to LIBGNAT_TARGET_PAIRS, allowing system-linux-x86.ads to get used.
But that's too late for m68k, since the type-incorrect s-memory.ad{b,s} have already been compiled and linked into the intermediate gnat1 etc, which then crash in stage 2.

So I'm now patching s-memory.ad{b,s} instead.  Assuming the current bootstrap succeeds (sometime late tomorrow) I'll post my full patch for 4.5.3.

> The problem is that LIBGNAT_TARGET_PAIRS is applied too late, and stage 1, 2,
> and 3 gnat1 etc are built out of a fixed set of source files that your target
> fragment in gcc/ada/gcc-interface/Makefile.in cannot influence (AFAIK).

Yes, the full run-time is built only after the compiler is built.

> You can observe this easily with a bootstrap on e.g. i686-linux.  On that
> platform system.ads should be replaced by system-linux-x86.ads, but the build
> log clearly shows stage 1, 2, 3 compiling the default gcc/ada/system.ads from
> the gcc source dir and linking that .o file into gnat1 etc.  It's not until
> some time after stage 3 that the build directory's gcc/ada/rts/ is populated
> according to LIBGNAT_TARGET_PAIRS, allowing system-linux-x86.ads to get used.

It is populated only at the beginning of the build of the full run-time.  So, in particular, system.ads is indeed used for the compiler proper in all stages.

> But that's too late for m68k, since the type-incorrect s-memory.ad{b,s} have
> already been compiled and linked into the intermediate gnat1 etc, which then
> crash in stage 2.

OK, this is more involved than envisioned initially.  I can propose a slight variant of my earlier proposal: still the attribute, but gigi (interface between front-end and middle-end) would be responsible for setting it on the malloc-like functions used in Ada.

Created attachment 24753 [details]
working patch for gcc-4.5.3 (v4)

Here's the current working patch I'm using with gcc-4.5.3 on m68k-linux.  As the diffstat shows

 gcc/ada/gcc-interface/Makefile.in |   28 ++++++
 gcc/ada/s-memory.adb              |   17 ++++
 gcc/ada/s-memory.ads              |    1 
 gcc/ada/system-linux-m68k.ads     |  153 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 198 insertions(+), 1 deletion(-)

not much is needed beyond the obvious target fragment in Makefile.in and the new system-linux-m68k.ads.  The s-memory.ad{b,s} patches work around the __gnat_malloc issue by adding a private Gnat_Malloc wrapper function that returns a proper pointer, and changing the __gnat_malloc export to refer to that function rather than the integer-returning Alloc function.  This should be safe though unnecessary on other platforms (initially tested on i686).

If the special attribute is implemented, then what it needs to do is to say that a particular integer-typed function (from Ada's perspective) should be treated as returning the equivalent of C's void*, with unchecked conversions inserted in the function's return points and in every caller.

In principle at least three functions need this treatment: __gnat_malloc, __gnat_realloc, and system__soft_links__get_jmpbuf_address_soft.  However, __gnat_realloc doesn't seem to be used by gnat itself, and ..get_jmpbuf.. doesn't appear to be needed for ZCX EH (I did have to patch get_jmpbuf_decl related code earlier when I still used SJLJ EH).

Once my current final verification bootstrap finishes I'll upload the gcc-4.5.3 binaries and start working on gcc-4.6.1 and gcc-4.7.0.

I've uploaded gcc-4.5.3 bootstrap binaries and my gcc-4.5.3 m68k patches to
<http://user.it.uu.se/~mikpe/linux/m68k-ada/>.

A gcc-4.6.1 bootstrap is in progress.

The first 4.6.1 bootstrap attempt failed at the very first Ada compilation step in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads.  This was with a straight forward-port of the working 4.5.3 patch.  I'll keep digging...

mikpe at it dot uu.se dixit:

>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
>
>--- Comment #25 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-16 13:20:49 UTC ---
>The first 4.6.1 bootstrap attempt failed at the very first Ada compilation step
>in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads.  This was


Could this be related to that bug?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633754

bye,
//mirabilos

(In reply to comment #26)
> Could this be related to that bug?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633754

I can't say for sure, but the symptoms aren't identical.  stage2 gnat1 always SEGVs in the same way, but SP is below accessible memory, PC is way high in nowhere land and odd (which isn't allowed), and gdb cannot generate a symbolic stack trace.  stage1 gnat1 does work however, which makes me suspect a miscompilation.  I may have to try a bisection.

Created attachment 24791 [details]
working patch for gcc-4.7-20110709

gcc-4.7-20110709 bootstrapped fine with the attached forward-port of the gcc-4.5 patch.  I'm starting a bisection to see when trunk started to work again, hoping that the same change will unbreak 4.6.1.

(In reply to comment #28)
> Created attachment 24791 [details]
> working patch for gcc-4.7-20110709
> 
> gcc-4.7-20110709 bootstrapped fine with the attached forward-port of the
> gcc-4.5 patch.  I'm starting a bisection to see when trunk started to work
> again, hoping that the same change will unbreak 4.6.1.

After a lengthy bisection process, I've now finally identified r171341 <http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00765.html> as the critical change that unbroke GNAT/m68k on trunk.  r171341 mixes cleanups with bugfixes, and is far too big to backport as-is to 4.6, so I'm now trying to split it up to identify a minimal bugfix-only fragment that unbreaks GNAT/m68k.

(In reply to comment #29)

> After a lengthy bisection process, I've now finally identified r171341
> <http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00765.html> as the critical change
> that unbroke GNAT/m68k on trunk.  r171341 mixes cleanups with bugfixes, and is

Wow, kudos for the work! You’re doing great!

> far too big to backport as-is to 4.6, so I'm now trying to split it up to
> identify a minimal bugfix-only fragment that unbreaks GNAT/m68k.

That’s nice, Debian apparently switched to GNAT 4.6 for Wheezy.

(In reply to comment #29)
> (In reply to comment #28)
> > Created attachment 24791 [details]
> > working patch for gcc-4.7-20110709
> > 
> > gcc-4.7-20110709 bootstrapped fine with the attached forward-port of the
> > gcc-4.5 patch.  I'm starting a bisection to see when trunk started to work
> > again, hoping that the same change will unbreak 4.6.1.
> 
> After a lengthy bisection process, I've now finally identified r171341
> <http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00765.html> as the critical change
> that unbroke GNAT/m68k on trunk.  r171341 mixes cleanups with bugfixes, and is
> far too big to backport as-is to 4.6, so I'm now trying to split it up to
> identify a minimal bugfix-only fragment that unbreaks GNAT/m68k.

It's the store_bit_field_1 changes + the new helpers that do the trick, specifically:

        * optabs.h
        (expand_operand_type): New enum.
        (expand_operand): New structure.
        (create_expand_operand): New function.
        (create_fixed_operand, create_output_operand): Likewise
        (create_input_operand, create_convert_operand_to): Likewise.
        (create_convert_operand_from, create_address_operand): Likewise.
        (create_integer_operand): Likewise.
        (create_convert_operand_from_type, maybe_legitimize_operands): Declare.
        (maybe_gen_insn, maybe_expand_insn, maybe_expand_jump_insn): Likewise.
        (expand_insn, expand_jump_insn): Likewise.
        * optabs.c
        (create_convert_operand_from_type): New function.
        (maybe_legitimize_operand, maybe_legitimize_operands): Likewise.
        (maybe_gen_insn, maybe_expand_insn, maybe_expand_jump_insn): Likewise.
        (expand_insn, expand_jump_insn): Likewise.

        * expmed.c
        (store_bit_field_1): Use the new interfaces.

I'll continue trying to minimize the changeset.

(In reply to comment #31)
>         * expmed.c
>         (store_bit_field_1): Use the new interfaces.
> 
> I'll continue trying to minimize the changeset.

Of the three translation paths in store_bit_field_1 that were updated in that revision, vec_set, movstrict, and insv, only the insv path update matters for GNAT/m68k.

(In reply to comment #32)
> (In reply to comment #31)
> >         * expmed.c
> >         (store_bit_field_1): Use the new interfaces.
> > 
> > I'll continue trying to minimize the changeset.
> 
> Of the three translation paths in store_bit_field_1 that were updated in that
> revision, vec_set, movstrict, and insv, only the insv path update matters for
> GNAT/m68k.

Progress.  The minimal fragment of r171341 that allows r171340 to bootstrap GNAT/m68k is the following:

--- gcc-4.7-r171340/gcc/expmed.c.~1~    2011-03-04 11:31:33.000000000 +0100
+++ gcc-4.7-r171340/gcc/expmed.c        2011-10-11 09:31:31.000000000 +0200
@@ -656,7 +656,8 @@ store_bit_field_1 (rtx str_rtx, unsigned
            && (bitsize + bitpos > GET_MODE_BITSIZE (op_mode)))
       && insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT (bitsize),
                                                        VOIDmode)
-      && check_predicate_volatile_ok (CODE_FOR_insv, 0, op0, VOIDmode))
+      && check_predicate_volatile_ok (CODE_FOR_insv, 0, op0,
+                                     insn_data[CODE_FOR_insv].operand[0].mode))
     {
       int xbitpos = bitpos;
       rtx value1;

That is, when checking insv opnd 0 use the mode from insn_data[] not VOIDmode.

(The code looks different in r171341 due new APIs and moving the operand checking to a later point.  The essential _functional_ difference wrt opnd 0 is however just the different mode value used in the check.)

I'm currently trying to bootstrap GNAT/m68k with gcc-4.6.1 and the above patch.

Adding Richard Sandiford to CC: list.  Richard, do you have any idea why the above mode change might have unbroken m68k?

Created attachment 25494 [details]
backported fragment of r171341, fixes insv on m68k

With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955, r178834) I was finally able to successfully bootstrap Ada on m68k-linux.

I'll test this patch on more archs over the next couple of days, then if no regressions appeared I'll submit it to gcc-patches.

(In reply to comment #34)
> Created attachment 25494 [details]
> backported fragment of r171341, fixes insv on m68k
> 
> With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a
> few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955,
> r178834) I was finally able to successfully bootstrap Ada on m68k-linux.

(forgot to add)
with gcc-4.6.1; 4.5.3 and 4.7 already worked.

> With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a
…
> r178834) I was finally able to successfully bootstrap Ada on m68k-linux.
> 
> I'll test this patch on more archs over the next couple of days, then if no
> regressions appeared I'll submit it to gcc-patches.

Thanks, greatly appreciated!

> few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955,

Do you think those could help with the gcj-4.6 showstopper, too?
cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847

(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > >         * expmed.c
> > >         (store_bit_field_1): Use the new interfaces.
> > > 
> > > I'll continue trying to minimize the changeset.
> > 
> > Of the three translation paths in store_bit_field_1 that were updated in that
> > revision, vec_set, movstrict, and insv, only the insv path update matters for
> > GNAT/m68k.
> 
> Progress.  The minimal fragment of r171341 that allows r171340 to bootstrap
> GNAT/m68k is the following:
> 
> --- gcc-4.7-r171340/gcc/expmed.c.~1~    2011-03-04 11:31:33.000000000 +0100
> +++ gcc-4.7-r171340/gcc/expmed.c        2011-10-11 09:31:31.000000000 +0200
> @@ -656,7 +656,8 @@ store_bit_field_1 (rtx str_rtx, unsigned
>             && (bitsize + bitpos > GET_MODE_BITSIZE (op_mode)))
>        && insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT (bitsize),
>                                                         VOIDmode)
> -      && check_predicate_volatile_ok (CODE_FOR_insv, 0, op0, VOIDmode))
> +      && check_predicate_volatile_ok (CODE_FOR_insv, 0, op0,
> +                                    
> insn_data[CODE_FOR_insv].operand[0].mode))
>      {
>        int xbitpos = bitpos;
>        rtx value1;
> 
> That is, when checking insv opnd 0 use the mode from insn_data[] not VOIDmode.
> 
> (The code looks different in r171341 due new APIs and moving the operand
> checking to a later point.  The essential _functional_ difference wrt opnd 0 is
> however just the different mode value used in the check.)
> 
> I'm currently trying to bootstrap GNAT/m68k with gcc-4.6.1 and the above patch.
> 
> Adding Richard Sandiford to CC: list.  Richard, do you have any idea why the
> above mode change might have unbroken m68k?

Sorry for the slow reply.  The SImode/nonimmediate_operand combination
in m68k's insv pattern looks a little odd:

(define_expand "insv"
  [(set (zero_extract:SI (match_operand:SI 0 "nonimmediate_operand" "")
			 (match_operand:SI 1 "const_int_operand" "")
			 (match_operand:SI 2 "const_int_operand" ""))
	(match_operand:SI 3 "register_operand" ""))]
  "TARGET_68020 && TARGET_BITFIELD"
  "")

The generic insv interface can take two styles of operand:
a QImode memory or a word_mode (SImode) register.  The odd
thing is that this m68k pattern requires even the memories
to be SImode (which they never are).

In 4.6 and earlier, we simply ignored the :SI, so QImode
memories were still accepted.  The effect of the backport
is to restrict insv to register operands (because the mode
is now checked), so the patch is equivalent to changing
nonimmediate_operand to register_operand in the define_expand.
But that isn't really what you want.

In other words, I'm afraid it looks like this backport is
hiding a bug elsewhere that appears somehow (and probably
indirectly!) related to the memory insv define_insns.
Looks like you've also found a performance regression in 4.7,
because I assume we no longer allow memory operands there either.

(In reply to comment #36)
> > With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a
> …
> > r178834) I was finally able to successfully bootstrap Ada on m68k-linux.
> > 
> > I'll test this patch on more archs over the next couple of days, then if no
> > regressions appeared I'll submit it to gcc-patches.
> 
> Thanks, greatly appreciated!
> 
> > few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955,
> 
> Do you think those could help with the gcj-4.6 showstopper, too?
> cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847

I checked, they didn't; with them on top of 4.6.1 I got a SEGV while compiling Random.java just like PR49847 described.

My next step wrt GNAT/m68k is to bisect the 4.5->4.6 changes to see what broke GNAT/m68k in the first place.

(In reply to comment #38)
> (In reply to comment #36)

> > > few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955,
> > 
> > Do you think those could help with the gcj-4.6 showstopper, too?
> > cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
> 
> I checked, they didn't; with them on top of 4.6.1 I got a SEGV while compiling
> Random.java just like PR49847 described.

Yes, same here (just today I got the result…). Damn, no such luck :|

> My next step wrt GNAT/m68k is to bisect the 4.5->4.6 changes to see what broke
> GNAT/m68k in the first place.

OK.

I’m personally not happy with the s-memory.adb changes. It basically
replaces “we have an Ada function returning System.Address and expose
that to C” with “we have an Ada function returning System.Address,
write a wrapper that unchecked-converts the result to Char_Ptr, and
expose that to C”. This does not scale. This will require patching
any and all third-party Ada source code which exposes functions to
C (that return pointers). Those people will think it pointless, not
listen (“who cares about m68k”), or not do it because only a certain
checksum-controlled source code is qualified for $thing.

I’d rather see the System.Address type being made a C pointer type,
globally, in the first place. Since I don’t speak Ada, I can’t do
it “the right way”. But what prevents us from changing Char_Ptr in
+   type Char_Ptr is access all Character;
+   pragma Convention (C, Char_Ptr);
+   pragma No_Strict_Aliasing (Char_Ptr);
to System.Address, replacing the previous “opaque” definition?

> I’d rather see the System.Address type being made a C pointer type,
> globally, in the first place. Since I don’t speak Ada, I can’t do
> it “the right way”. But what prevents us from changing Char_Ptr in
> +   type Char_Ptr is access all Character;
> +   pragma Convention (C, Char_Ptr);
> +   pragma No_Strict_Aliasing (Char_Ptr);
> to System.Address, replacing the previous “opaque” definition?

See the first part of comment #11.  Ada doesn't like pointers very much.

(In reply to comment #25)
> The first 4.6.1 bootstrap attempt failed at the very first Ada compilation step
> in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads.  This was
> with a straight forward-port of the working 4.5.3 patch.  I'll keep digging...

GNAT/m68k worked on 4.6 branch, with a few unrelated interruptions, up to r161654.  Starting with r161655 (Richard Guenther's big MEM_REF merge):
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00006.html
it fails as follows:

/tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/tmp/install46/m68k-unknown-linux-gnu/bin/ -B/tmp/install46/m68k-unknown-linux-gnu/lib/ -isystem /tmp/install46/m68k-unknown-linux-gnu/include -isystem /tmp/install46/m68k-unknown-linux-gnu/sys-include    -c -g -O2   -W -Wall -gnatpg   s-fatllf.ads -o s-fatllf.o
+===========================GNAT BUG DETECTED==============================+
| 4.6.0 20100703 (experimental) (m68k-unknown-linux-gnu) GCC error:        |
| in gen_rtx_SUBREG, at emit-rtl.c:803                                     |
| Error detected around s-fatgen.adb:857:50                                |

This continues until r162897 (jiez's tree-sra tweak for PR45144):
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00108.html
after which it fails a bit earlier as follows:

/tmp/objdir/./prev-gcc/xgcc -B/tmp/objdir/./prev-gcc/ -B/tmp/install46/m68k-unknown-linux-gnu/bin/ -B/tmp/install46/m68k-unknown-linux-gnu/bin/ -B/tmp/install46/m68k-unknown-linux-gnu/lib/ -isystem /tmp/install46/m68k-unknown-linux-gnu/include -isystem /tmp/install46/m68k-unknown-linux-gnu/sys-include    -c -g -O2  -gnatpg -gnata -nostdinc -I- -I. -Iada -I/tmp/gcc-4.6-r162898/gcc/ada -I/tmp/gcc-4.6-r162898/gcc/ada/gcc-interface /tmp/gcc-4.6-r162898/gcc/ada/a-charac.ads -o ada/a-charac.o
xgcc: internal compiler error: Segmentation fault (program gnat1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [ada/a-charac.o] Error 4
make[3]: Leaving directory `/tmp/objdir/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/tmp/objdir'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/tmp/objdir'
make: *** [bootstrap] Error 2

which is the failure seen originally with gcc-4.6.1.  a-charac.ads was compiled ok earlier by the stage 1 (?) compiler, so this smells like a miscompilation of stage 3.

I'll continue to bisect and test with r162897 reverted.

(In reply to comment #41)
> I'll continue to bisect and test with r162897 reverted.

With r162897 reverted subsequent gcc-4.6 snapshots up to the 4.6.2 release bootstrap fine with Ada enabled and a few patches applied, specifically:
1. revert the core of r162897 (original has a few harmless failing hunks)
2. backport of pr43804 fix
3. backport of pr47612 fix which also fixes pr48554
4. the m68k-ada patch as posted here earlier
5. backport r178834 cfgcleanup HAVE_cc0 fix (will also be in 4.6.3)

Note I'm not applying the insv fragment of r171341 any more.  I saw some test suite regressions from 4.6 with it applied so I've dropped it.

However, meanwhile 4.7 has broken.  4.7-20110730 builds fine as a cross, but every snapshot from 20110806 to 20111203 ICE as follows:

/tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/bin/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/lib/ -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/include -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/sys-include    -c -g -O2   -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
+===========================GNAT BUG DETECTED==============================+
| 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error:            |
| in fp_size_to_prec, at ada/gcc-interface/misc.c:781                      |
| Error detected around <built-in>:0                                       |

So now I'm bisecting trunk to identify the cause of this regression.

What is the argument of fp_size_to_prec here?

(In reply to comment #43)
> What is the argument of fp_size_to_prec here?

size == 80

That should probably be 96.

There were a lot of float related changes around 2011-08-02.

(In reply to comment #42)
> -O2   -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
> +===========================GNAT BUG DETECTED==============================+
> | 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error:            |
> | in fp_size_to_prec, at ada/gcc-interface/misc.c:781                      |

This is caused by the float changes in r177137 plus the enumerate_modes fix in r177141 (without the latter it won't compile).

(In reply to comment #47)
> (In reply to comment #42)
> > -O2   -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
> > +===========================GNAT BUG DETECTED==============================+
> > | 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error:            |
> > | in fp_size_to_prec, at ada/gcc-interface/misc.c:781                      |
> 
> This is caused by the float changes in r177137 plus the enumerate_modes fix in
> r177141 (without the latter it won't compile).

I instrumented fp_prec_to_size and fp_size_to_prec to log who called them with what parameters and what they then computed, and saw something strange:

fp_prec_to_size_(32, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 116): mode 27 prec 32 bitsize 32
fp_prec_to_size_(32, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 116): mode 27 prec 32 bitsize 32
fp_prec_to_size_(64, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 122): mode 27 prec 32 bitsize 32
fp_prec_to_size_(64, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 122): mode 28 prec 64 bitsize 64
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 27 prec 32 bitsize 32
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 28 prec 64 bitsize 64
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 29 prec 80 bitsize 96
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 27 prec 32 bitsize 32
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 28 prec 64 bitsize 64
fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 29 prec 80 bitsize 96
gnat_to_gnu_entity: esize 80 max_esize 96 LONG_DOUBLE_TYPE_SIZE 80
fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 27 bitsize 32 prec 32
fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 28 bitsize 64 prec 64
fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 29 bitsize 96 prec 80
+===========================GNAT BUG DETECTED==============================+
| 4.7.0 20110802 (experimental) (m68k-unknown-linux-gnu) GCC error:        |
| in fp_size_to_prec_, at ada/gcc-interface/misc.c:793                     |

That is, first ada maps precisions 32, 64, and 80 to bit sizes 32, 64, and 96, respectively.  Then ada turns around and tries to map _bit_size_ 80 to a precision, but bit size 80 doesn't exist so fp_size_to_prec() asserts.  Did something confuse precision with bit size somewhere?

> That is, first ada maps precisions 32, 64, and 80 to bit sizes 32, 64, and 96,
> respectively.  Then ada turns around and tries to map _bit_size_ 80 to a
> precision, but bit size 80 doesn't exist so fp_size_to_prec() asserts.  Did
> something confuse precision with bit size somewhere?

No, but the new code (cstand.adb:Register_Float_Type) makes an invalid assumption about the size of a FP mode given its precision and alignment, instead of using the proper interface.  enumerate_modes should probably pass GET_MODE_BITSIZE to its callback.  I'd suggest opening a new regression PR for this problem.

(In reply to comment #49)
> No, but the new code (cstand.adb:Register_Float_Type) makes an invalid
> assumption about the size of a FP mode given its precision and alignment,
> instead of using the proper interface.  enumerate_modes should probably pass
> GET_MODE_BITSIZE to its callback.  I'd suggest opening a new regression PR for
> this problem.

Thanks.  I've opened PR51483 for the wrong FP representation assumption issue.

Geert's proposal at http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00556.html is an interesting track.  I'll give it a try.

Mikael’s patches work fine for me, gnat-4.6 (4.6.3-1+m68k.2) has just made its way to debian-ports.org unreleased, chances are it’ll become part of the stock unstable sources soon. Full three-stage bootstrap passes (with assorted GCC bugfix backports applied by Mikael’s suggestion of course), although I did not run the testsuite due to lack of time.

Thanks to everyone involved!

Test result for gcc-4.8-20120304 bootstrapped w/ Ada enabled has been posted:
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01425.html

The Ada results look as follows:

                === acats tests ===
FAIL:   ad8011a
FAIL:   c52103x
FAIL:   c52104x
FAIL:   c52104y
FAIL:   c940013
FAIL:   c94007a
FAIL:   c94007b
FAIL:   c954025
FAIL:   c954026
FAIL:   c960001
FAIL:   c9a007a
FAIL:   c9a011b
FAIL:   cda201a
FAIL:   cxa5a08
FAIL:   cxg2001
FAIL:   cxg2003
FAIL:   cxg2004
FAIL:   cxg2006
FAIL:   cxg2007
FAIL:   cxg2011
FAIL:   cxg2012
FAIL:   cxg2014
FAIL:   cxg2015
FAIL:   cxg2016
FAIL:   cxg2017
FAIL:   cxg2018
FAIL:   cxg2019
FAIL:   cxg2020
FAIL:   cxg2021

                === acats Summary ===
# of expected passes            2291
# of unexpected failures        29
Native configuration is m68k-unknown-linux-gnu

                === gnat tests ===


Running target unix
FAIL: gnat.dg/constant3.adb (test for excess errors)
FAIL: gnat.dg/discr32.adb execution test
FAIL: gnat.dg/incomplete2.adb (internal compiler error)
FAIL: gnat.dg/machine_code1.adb (test for excess errors)
FAIL: gnat.dg/null_pointer_deref1.adb execution test
FAIL: gnat.dg/old_errors.adb (internal compiler error)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 7)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 16)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 28)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 34)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 38)
FAIL: gnat.dg/old_errors.adb  (test for warnings, line 40)
FAIL: gnat.dg/old_errors.adb  (test for errors, line 44)
FAIL: gnat.dg/old_errors.adb (test for excess errors)
FAIL: gnat.dg/pack5.adb (test for excess errors)
FAIL: gnat.dg/rep_clause4.adb (test for excess errors)
FAIL: gnat.dg/unchecked_convert4.adb (test for excess errors)
FAIL: gnat.dg/specs/addr1.ads  (test for warnings, line 30)
FAIL: gnat.dg/specs/integer_value.ads (internal compiler error)
FAIL: gnat.dg/specs/integer_value.ads  (test for errors, line 4)
FAIL: gnat.dg/specs/integer_value.ads (test for excess errors)
FAIL: gnat.dg/specs/linker_section.ads (internal compiler error)
FAIL: gnat.dg/specs/linker_section.ads  (test for errors, line 6)
FAIL: gnat.dg/specs/linker_section.ads  (test for errors, line 10)
FAIL: gnat.dg/specs/linker_section.ads (test for excess errors)

                === gnat Summary ===

# of expected passes            1042
# of unexpected failures        25
# of expected failures          13
# of unsupported tests          11

Status update:

Although gnat is solid enough to rebuild itself with (patched) gcc-4.6 on m68k, there is a regression with (similarly patched) 4.7 that breaks bootstrap:

/mnt/scratch/objdir47/./gcc/xgcc -B/mnt/scratch/objdir47/./gcc/ -B/usr/m68k-brewer-linux/bin/ -B/usr/m68k-brewer-linux/lib/ -isystem /usr/m68k-brewer-linux/include -isystem /usr/m68k-brewer-linux/sys-include    -c -g -O2 -mcpu=68060 -fpic  -W -Wall -gnatpg -nostdinc -mcpu=68060  a-calfor.adb -o a-calfor.o
xgcc: internal compiler error: Segmentation fault (program gnat1)
Please submit a full bug report,
with preprocessed source if appropriate.
make[9]: *** [a-calfor.o] Error 4
make[9]: Leaving directory `/mnt/scratch/objdir47/gcc/ada/rts_m68060'
make[8]: *** [gnatlib] Error 2
make[8]: Leaving directory `/mnt/scratch/objdir47/gcc/ada'
make[7]: *** [gnatlib-shared-default] Error 2
make[7]: Leaving directory `/mnt/scratch/objdir47/gcc/ada'
make[6]: *** [gnatlib-shared-dual] Error 2
make[6]: Leaving directory `/mnt/scratch/objdir47/gcc/ada'
make[5]: *** [gnatlib-shared] Error 2
make[5]: Leaving directory `/mnt/scratch/objdir47/gcc/ada'
make[4]: *** [gnatlib-shared] Error 2
make[4]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/m68060/libada'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir47'
make: *** [bootstrap] Error 2

This only occurs when compiling the 68060 variant of the libraries.  With multilibs disabled 4.7.3 bootstraps fine w/ Ada.

This ICE started with r180192, an ICE fix (PR50780).  I don't see anything in that patch that seems m68k or cc0 related, so I suspect it just exposed some latent issue.

(In reply to comment #54)
> This ICE started with r180192, an ICE fix (PR50780).  I don't see anything in
> that patch that seems m68k or cc0 related

Actually, r180192 is HIGHLY CC0-related, see PR49847#c16.

Here's an annotated gdb session:

sh-4.2$ gdb /mnt/scratch/objdir47/./gcc/gnat1
GNU gdb (GDB) Brewer Linux (7.4.50.20120120-52.bl17.bl.1)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "m68k-brewer-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /mnt/scratch/objdir47/gcc/gnat1...done.
(gdb) run -gnatwa -quiet -nostdinc -dumpbase a-calfor.adb -auxbase-strip a-calfor.o -O2 -Wextra -Wall -fpic -g -mcpu=68060 -gnatpg -mcpu=68060 -gnatO a-calfor.o a-calfor.adb -o /tmp/ccudsaKf.s
Starting program: /mnt/scratch/objdir47/gcc/gnat1 -gnatwa -quiet -nostdinc -dumpbase a-calfor.adb -auxbase-strip a-calfor.o -O2 -Wextra -Wall -fpic -g -mcpu=68060 -gnatpg -mcpu=68060 -gnatO a-calfor.o a-calfor.adb -o /tmp/ccudsaKf.s

Program received signal SIGSEGV, Segmentation fault.
0x806f7016 in find_comparison_args (code=GE, parg1=0xeffff218, parg2=0xeffff21c, pmode1=0xeffff220, pmode2=0xeffff224) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:2975
2975	  while (arg2 == CONST0_RTX (GET_MODE (arg1)))
Missing separate debuginfos, use: debuginfo-install glibc-2.15-58.bl17.bl.1.m68k gmp-5.0.4-1.bl15.bl.2.m68k libmpc-1.0.1-1.bl17.bl.1.m68k mpfr-3.1.1-1.bl17.bl.1.m68k zlib-1.2.5-7.bl17.m68k
(gdb) bt
#0  0x806f7016 in find_comparison_args (code=GE, parg1=0xeffff218, parg2=0xeffff21c, pmode1=0xeffff220, pmode2=0xeffff224) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:2975
#1  0x806fe620 in record_jump_equiv (taken=<optimized out>, insn=0xc0a07440) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:3920
#2  cse_extended_basic_block (ebb_data=<optimized out>) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:6432
#3  cse_main (f=0xc09e3f80, nregs=185) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:6527
#4  0x806fe720 in rest_of_handle_cse () at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:7379
#5  0x804ba474 in execute_one_pass (pass=0x8088bc8c) at /mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2064
#6  0x804ba780 in execute_pass_list (pass=0x8088bc8c) at /mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2119
#7  0x804ba790 in execute_pass_list (pass=0x80889834) at /mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2120
#8  0x8057b212 in tree_rest_of_compilation (fndecl=0xc0547600) at /mnt/scratch/gcc-4.7-r180192/gcc/tree-optimize.c:420
#9  0x8035bb5a in cgraph_expand_function (node=0xc04d3d10) at /mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1804
#10 0x8035d3f2 in cgraph_expand_all_functions () at /mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1871
#11 cgraph_optimize () at /mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:2168
#12 0x8035d57e in cgraph_finalize_compilation_unit () at /mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1312
#13 0x80049b26 in gnat_write_global_declarations () at /mnt/scratch/gcc-4.7-r180192/gcc/ada/gcc-interface/utils.c:4920
#14 0x8053e70a in compile_file () at /mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:581
#15 do_compile () at /mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:1930
#16 toplev_main (argc=21, argv=0xeffff444) at /mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:2006
#17 0xc012dee8 in __libc_start_main () from /lib/libc.so.6
#18 0x800279a2 in _start ()
(gdb) list
2970	
2971	  arg1 = *parg1, arg2 = *parg2;
2972	
2973	  /* If ARG2 is const0_rtx, see what ARG1 is equivalent to.  */
2974	
2975	  while (arg2 == CONST0_RTX (GET_MODE (arg1)))
2976	    {
2977	      /* Set nonzero when we find something of interest.  */
2978	      rtx x = 0;
2979	      int reverse_code = 0;
(gdb) print *parg1
$1 = (rtx) 0x0

We're at the start of find_comparison_args, and *parg1 is NULL. No wonder we SEGV then at line 2975.

(gdb) up
#1  0x806fe620 in record_jump_equiv (taken=<optimized out>, insn=0xc0a07440) at /mnt/scratch/gcc-4.7-r180192/gcc/cse.c:3920
3920	  code = find_comparison_args (code, &op0, &op1, &mode0, &mode1);
(gdb) list
3915	     know that it isn't valid for floating-point.  */
3916	  code = GET_CODE (XEXP (SET_SRC (set), 0));
3917	  op0 = fold_rtx (XEXP (XEXP (SET_SRC (set), 0), 0), insn);
3918	  op1 = fold_rtx (XEXP (XEXP (SET_SRC (set), 0), 1), insn);
3919	
3920	  code = find_comparison_args (code, &op0, &op1, &mode0, &mode1);
3921	  if (! cond_known_true)
3922	    {
3923	      code = reversed_comparison_code_parts (code, op0, op1, insn);
3924	
(gdb) print op0
$2 = (rtx) 0x0
(gdb) call debug_rtx(set)
(set (pc)
    (if_then_else (ge (cc0)
            (const_int 0 [0]))
        (label_ref:SI 471)
        (pc)))
(gdb) call debug_rtx(insn)
(jump_insn 298 457 458 43 (set (pc)
        (if_then_else (ge (cc0)
                (const_int 0 [0]))
            (label_ref:SI 471)
            (pc))) a-calfor.adb:758 398 {bge}
     (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil))
 -> 471)

record_jump_equiv gets a jump_insn with a condition whose OP0 was (cc0) but fold_rtx turned it into NULL.  So we're calling find_comparison_args with a pointer to NULL, causing it to SEGV.

A quick look at the start of fold_rtx reveals:

  /* Try to perform some initial simplifications on X.  */
  code = GET_CODE (x);
  switch (code)
    {
...
#ifdef HAVE_cc0
    case CC0:
      return prev_insn_cc0;
#endif

Remember PR49847?  A consequence of r180192 is that it may separate CC0 setters from users in EH contexts.  And that's clearly what's happening here.  Patching the above case to return x when prev_insn_cc0 is NULL eliminates the SEGV when compiling a-calfor.adb, and allows compilation to proceed through many more .adb files; a debug printf shows that the case above with NULL prev_insn_cc0 triggers many times when compiling the 68060-optimized Ada runtime.  I'm currently doing a clean bootstrap with that patch.

Created attachment 32724 [details]
Ada support patch updated for gcc 4.9

Author: ebotcazou
Date: Wed Jun 29 13:03:22 2016
New Revision: 237850

URL: https://gcc.gnu.org/viewcvs?rev=237850&root=gcc&view=rev
Log:
	PR ada/48835
	PR ada/61954
	* gcc-interface/gigi.h (enum standard_datatypes): Add ADT_realloc_decl
	(realloc_decl): New macro.
	* gcc-interface/decl.c (gnat_to_gnu_entity) <E_Variable>: Use local
	variable for the entity type and translate it as void pointer if the
	entity has convention C.
	(gnat_to_gnu_entity) <E_Function>: If this is not a definition and the
	external name matches that of malloc_decl or realloc_decl, return the
	correspoding node directly.
	(gnat_to_gnu_subprog_type): Likewise for parameter and return types.
	* gcc-interface/trans.c (gigi): Initialize void_list_node here, not...
	Initialize realloc_decl.
	* gcc-interface/utils.c (install_builtin_elementary_types): ...here.
	(build_void_list_node): Delete.
	* gcc-interface/utils2.c (known_alignment) <CALL_EXPR>: Return the
	alignment of the system allocator for malloc_decl and realloc_decl.
	Do not take alignment from void pointer types either.

Modified:
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/decl.c
    trunk/gcc/ada/gcc-interface/gigi.h
    trunk/gcc/ada/gcc-interface/trans.c
    trunk/gcc/ada/gcc-interface/utils.c
    trunk/gcc/ada/gcc-interface/utils2.c

> OK, so the fix is that the System.Address type must be changed in GNAT
> to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT
> developer please working on this?

That's at last implemented on the mainline.

All the issues in this BZ should be addressed on the trunk.  Any further GNAT problems on m68k should be tracked with a new BZ.

Let's avoid mega-bugs like this in the future -- instead track each distinct problem as a distinct bug so that it's relatively easy to know the state of a given issue.

When many bugs are blocking a single larger issue (like we've seen with this BZ), open a bug for the large issue and make it dependent upon the individual bugs.

I don't see the patch which adds support for "M68K Linux" to Ada in the current trunk or gcc-7 [1]. Am I missing something?

Adrian

> [1] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/ada/gcc-interface/Makefile.in?view=markup

So, I have had a closer look and there is still no complete support for m68k-linux in gnat. We are still missing the changes to gcc/ada/gcc-interface/Makefile.in as well as the new file gcc/ada/system-linux-m68k.ads.

I'm attaching a patch with these changes which is just an updated patch from the Debian gcc package. This is just Mikael's patch with the changes to gcc/ada/s-memory.adb and gcc/ada/s-memory.ads removed since these shouldn't be necessary any longer according to comment #58.

Could we re-open this bug report, please? Because the main part of this bug report which is porting GNAT to m68k-linux is actually not resolved.

Thanks,
Adrian

Created attachment 40247 [details]
Ada support patch updated for gcc-7.0.

> Could we re-open this bug report, please? Because the main part of this bug
> report which is porting GNAT to m68k-linux is actually not resolved.

Done.

> Created attachment 40247 [details]
> Ada support patch updated for gcc-7.0.

The variables $(arch) and $(osys) are obsolete in Makefile.in and the line
"Frontend_Exceptions       : constant Boolean := False;" is missing.

(In reply to Eric Botcazou from comment #64)
> > Created attachment 40247 [details]
> > Ada support patch updated for gcc-7.0.
> 
> The variables $(arch) and $(osys) are obsolete in Makefile.in and the line
> "Frontend_Exceptions       : constant Boolean := False;" is missing.

Ok, thanks for the comment. I'll look into updating the patch.

Created attachment 40248 [details]
Ada support patch updated for gcc-7.0.

Alright, updated the patch accordingly. Hope it can be applied now :).

I think Mikael should still be set as the author when committing as the wrote the actual patch, I just updated it.

Thanks,
Adrian

Author: ebotcazou
Date: Mon Dec  5 11:27:55 2016
New Revision: 243247

URL: https://gcc.gnu.org/viewcvs?rev=243247&root=gcc&view=rev
Log:
	PR ada/48835
	* gcc-interface/Makefile.in: Add support for m68k-linux.
	* system-linux-m68k.ads: New file.

Added:
    trunk/gcc/ada/system-linux-m68k.ads
Modified:
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/Makefile.in

Thanks, patch applied on the mainline.

(In reply to Eric Botcazou from comment #68)
> Thanks, patch applied on the mainline.

Thanks a lot! Would you also mind backporting it to the gcc-7 branch?

Thanks,
Adrian

> Thanks a lot! Would you also mind backporting it to the gcc-7 branch?

There is no gcc-7 branch yet.

(In reply to Eric Botcazou from comment #70)
> > Thanks a lot! Would you also mind backporting it to the gcc-7 branch?
> 
> There is no gcc-7 branch yet.

Ah, sorry. I thought there already was since Matthias Klose recently started uploading gcc-7 to Debian experimental and I thought this means that it has been branched from master now.

Then I guess I'll just have to wait for the next upload.