[Bug ada/48835] New: Porting GNAT to GNU/Linux/m68k

[Bug ada/48835] New: Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

           Summary: Porting GNAT to GNU/Linux/m68k
           Product: gcc
           Version: 4.4.6
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: ada
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tg@mirbsd.org


Created attachment 24151
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24151
first draft

Discussion about attempting to port GNAT to GNU/Linux/m68k.

I’ve come this far:

root@ara5:...mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc # gdb ./gnat1
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc/gnat1...done.
warning: not using untrusted file ".gdbinit"
(gdb) r
Starting program: /mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc/gnat1
#NO_APP 
        .file   "<stdin>"

Program received signal SIGSEGV, Segmentation fault.
0xc014d428 in memcpy (dstpp=0x8018668a, srcpp=0x80a2688e, len=2149082762) at
memcpy.c:61
61      memcpy.c: No such file or directory.
        in memcpy.c
(gdb) bt
#0  0xc014d428 in memcpy (dstpp=0x8018668a, srcpp=0x80a2688e, len=2149082762)
at memcpy.c:61
#1  0x80137084 in <hostparm___elabs> () at ../../src/gcc/ada/hostparm.ads:54
#2  0x800049cc in adainit () at ada/b_gnat1.c:317
#3  0x80015a3a in gnat_parse_file (set_yydebug=0) at
../../src/gcc/ada/gcc-interface/misc.c:198
#4  0x80459e62 in compile_file (argc=1, argv=0xefe5dc24) at
../../src/gcc/toplev.c:970
#5  do_compile (argc=1, argv=0xefe5dc24) at ../../src/gcc/toplev.c:2197
#6  toplev_main (argc=1, argv=0xefe5dc24) at ../../src/gcc/toplev.c:2229
#7  0xc00fae68 in __libc_start_main (main=0x802a29e4 <main>, argc=1,
ubp_av=0xefe5dc24, 
    init=0x806dadd0 <__libc_csu_init>, fini=0x806dadc8 <__libc_csu_fini>,
rtld_fini=0xc000d320 <_dl_fini>,
    stack_end=0xefe5dc24) at libc-start.c:228
#8  0x80003a6e in _start ()
(gdb) frame 1
#1  0x80137084 in <hostparm___elabs> () at ../../src/gcc/ada/hostparm.ads:54
54         Normalized_CWD : constant String := "." & Direct_Separator;
(gdb) disas
Dump of assembler code for function hostparm___elabs:
   0x80136ef0 <+0>:     linkw %fp,#0
   0x80136ef4 <+4>:     moveml %d2-%d7,%sp@-
   0x80136ef8 <+8>:     movel 0x806db078 <__gnat_vmsp>,%d0
   0x80136efe <+14>:    sne %d0
   0x80136f00 <+16>:    negb %d0
   0x80136f02 <+18>:    moveb %d0,0x807eff68 <hostparm__openvms>
   0x80136f08 <+24>:    moveb 0x807ab130 <__gnat_dir_separator>,%d2
   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.
This matches the “len” argument to memcpy.

(gdb) info r
d0             0x1      1
d1             0xf      15
d2             0x8018668a       -2145884534
d3             0xf      15
d4             0x1c     28
d5             0x1      1
d6             0x1      1
d7             0x1      1
a0             0x8018668a       0x8018668a
a1             0x80a2688f       0x80a2688f
a2             0x0      0x0
a3             0x802f3094       0x802f3094
a4             0x8000319c       0x8000319c
a5             0xc0202000       0xc0202000
fp             0xefe5dadc       0xefe5dadc
sp             0xefe5dab4       0xefe5dab4
ps             0x300    [ I0 I1 ]
pc             0x80137084       0x80137084 <<hostparm___elabs>+404>
fpcontrol      0x0      0
fpstatus       0x0      0
fpiaddr        0x0      0

I’m attaching my current patch (I have copyright assignments standing),
although the result is currently the same with the patch not applied.

My baseline is Debian gcc-4.4 (4.4.6-2), since that contains all needed
backports for working C, C++ and GCJ on m68k.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> 2011-04-30 16:19:42 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dewar at gnat dot com
               Host|                            |m68k-linux

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> 2011-04-30 21:56:16 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

Thorsten Glaser <tg at mirbsd dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|m68k-linux                  |

--- Comment #3 from Thorsten Glaser <tg at mirbsd dot org> 2011-04-30 22:16:10 UTC ---
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!

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #4 from Thorsten Glaser <tg at mirbsd dot org> 2011-04-30 22:17:36 UTC ---
(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… ☺

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #5 from Thorsten Glaser <tg at mirbsd dot org> 2011-04-30 22:28:03 UTC ---
(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…)

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[schwab@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> 2011-05-01 07:54:16 UTC ---
That's not a problem because all pointer values are also returned in %d0 for
compatibility.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #7 from Thorsten Glaser <tg at mirbsd dot org> 2011-06-10 20:54:58 UTC ---
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?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-11 12:33:09 UTC ---
Created attachment 24491
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24491
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-13 21:16:20 UTC ---
> - __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?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-14 08:12:54 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-14 08:44:12 UTC ---
> 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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #12 from Thorsten Glaser <tg at mirbsd dot org> 2011-06-14 10:59:03 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-06-14 11:27:24 UTC ---
> 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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #14 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-17 10:02:21 UTC ---
Partial success: I've just managed to bootstrap gcc-4.1.2 w/ gnat on
m68k-linux.  Lots of patches applied though.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-23 08:36:33 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #16 from Mikael Pettersson <mikpe at it dot uu.se> 2011-06-29 07:40:20 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #17 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-01 07:54:05 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #18 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-09 10:57:47 UTC ---
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}.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #19 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-11 22:27:53 UTC ---
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 ...

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #20 from Thorsten Glaser <tg at mirbsd dot org> 2011-07-11 22:52:04 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #21 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-12 15:42:35 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.07.12 17:05:07
     Ever Confirmed|0                           |1

--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-12 17:05:07 UTC ---
> 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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24491|0                           |1
        is obsolete|                            |

--- Comment #23 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-14 08:44:51 UTC ---
Created attachment 24753
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24753
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #24 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-15 10:11:45 UTC ---
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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
with a straight forward-port of the working 4.5.3 patch.  I'll keep digging...

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot de]

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

--- Comment #26 from tg at mirbsd dot de <tg at mirbsd dot de> 2011-07-16 16:17:35 UTC ---
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

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #27 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-17 10:18:25 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #28 from Mikael Pettersson <mikpe at it dot uu.se> 2011-07-19 09:12:01 UTC ---
Created attachment 24791
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24791
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #29 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-10 09:52:34 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #30 from Thorsten Glaser <tg at mirbsd dot org> 2011-09-10 13:11:16 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #31 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-21 07:34:33 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #32 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-25 18:05:21 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #33 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-12 17:20:46 UTC ---
(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?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #34 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-14 07:54:15 UTC ---
Created attachment 25494
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25494
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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #35 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-14 07:57:24 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #36 from Thorsten Glaser <tg at mirbsd dot org> 2011-10-14 08:39:06 UTC ---
> 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

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[rsandifo at gcc dot gnu.org]

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

--- Comment #37 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-10-16 13:20:01 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #38 from Mikael Pettersson <mikpe at it dot uu.se> 2011-10-17 16:26:28 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[tg at mirbsd dot org]

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

--- Comment #39 from Thorsten Glaser <tg at mirbsd dot org> 2011-10-17 20:29:52 UTC ---
(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?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

--- Comment #40 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-10-17 22:21:20 UTC ---
> 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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #41 from Mikael Pettersson <mikpe at it dot uu.se> 2011-11-21 09:25:27 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #42 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-07 09:58:17 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[schwab@linux-m68k.org]

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

--- Comment #43 from Andreas Schwab <schwab@linux-m68k.org> 2011-12-07 11:07:16 UTC ---
What is the argument of fp_size_to_prec here?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #44 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-07 12:04:14 UTC ---
(In reply to comment #43)
> What is the argument of fp_size_to_prec here?

size == 80

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[schwab@linux-m68k.org]

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

--- Comment #45 from Andreas Schwab <schwab@linux-m68k.org> 2011-12-07 12:48:29 UTC ---
That should probably be 96.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[schwab@linux-m68k.org]

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

--- Comment #46 from Andreas Schwab <schwab@linux-m68k.org> 2011-12-07 13:10:15 UTC ---
There were a lot of float related changes around 2011-08-02.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #47 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-07 21:12:39 UTC ---
(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).

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #48 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-08 09:25:55 UTC ---
(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?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

--- Comment #49 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-08 16:00:34 UTC ---
> 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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #50 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-09 09:38:33 UTC ---
(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.

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |bosch at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #51 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-11 14:43:54 UTC ---
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.

[Bug ada/48835] porting GNAT to m68k-linux

[tg at mirbsd dot org]

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

--- Comment #52 from Thorsten Glaser <tg at mirbsd dot org> 2012-03-10 00:52:32 UTC ---
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!

[Bug ada/48835] porting GNAT to m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #53 from Mikael Pettersson <mikpe at it dot uu.se> 2012-03-12 22:14:46 UTC ---
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

[Bug ada/48835] porting GNAT to m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #54 from Mikael Pettersson <mikpe at it dot uu.se> 2013-03-20 11:05:58 UTC ---
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.

[Bug ada/48835] porting GNAT to m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #55 from Mikael Pettersson <mikpe at it dot uu.se> 2013-03-22 14:30:23 UTC ---
(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.

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|ebotcazou at gcc dot gnu.org       |unassigned at gcc dot gnu.org

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
Bug 48835 depends on bug 51483, which changed state.

Bug 51483 Summary: [4.7/4.8/4.9 regression] cstand.adb:Register_Float_Type makes invalid assumption about FP modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug ada/48835] porting GNAT to m68k-linux

[schwab@linux-m68k.org]

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

--- Comment #56 from Andreas Schwab <schwab@linux-m68k.org> ---
Created attachment 32724
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32724&action=edit
Ada support patch updated for gcc 4.9