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?
