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

["tg at mirbsd dot org" <gcc-bugzilla at gcc dot gnu 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?