[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  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
 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  2011-09-10 13:11:16 
UTC ---
(In reply to comment #29)

> After a lengthy bisection process, I've now finally identified r171341
>  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  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
>  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  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  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #33 from Mikael Pettersson  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.0 +0100
+++ gcc-4.7-r171340/gcc/expmed.c2011-10-11 09:31:31.0 +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  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  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  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  
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.0 +0100
> +++ gcc-4.7-r171340/gcc/expmed.c2011-10-11 09:31:31.0 +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  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  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  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  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/msg6.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  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  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 :0   |

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

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

[sch...@linux-m68k.org]

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

--- Comment #43 from Andreas Schwab  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  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

[sch...@linux-m68k.org]

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

--- Comment #45 from Andreas Schwab  2011-12-07 12:48:29 
UTC ---
That should probably be 96.

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

[sch...@linux-m68k.org]

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

--- Comment #46 from Andreas Schwab  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  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  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  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  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  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  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 GNU/Linux/m68k

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  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 
> […]
> 
> 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

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||dewar at gnat dot com
   Host||m68k-linux

--- Comment #2 from Andreas Schwab  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  changed:

   What|Removed |Added

   Host|m68k-linux  |

--- Comment #3 from Thorsten Glaser  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  0x0002
ret addrdst src len

(gdb) x 0x80a2688e
0x80a2688e : 0x2e2f
(gdb) x 0x8018668a
0x8018668a :  0x4e56

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  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  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

[sch...@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab  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  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  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 compilegnatmake -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  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #9 from Eric Botcazou  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  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  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  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  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  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  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  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  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  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  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

[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  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  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  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.12 17:05:07
 Ever Confirmed|0   |1

--- Comment #22 from Eric Botcazou  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  changed:

   What|Removed |Added

  Attachment #24491|0   |1
is obsolete||

--- Comment #23 from Mikael Pettersson  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  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
.

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  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  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  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  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  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.