diff mbox

[Ada] Fix powerpc-darwin bootstrap with gcc-trunk.

Message ID E2F06B67-6C0F-42A7-A19E-20C91F864C3D@codesourcery.com
State New
Headers show

Commit Message

Iain Sandoe March 29, 2015, 6:37 p.m. UTC
Hi Arnaud,

Currently Ada bootstrap is broken for bootstrap compiler == gcc-trunk, and platform == powerpc-darwin9 (although it is possible to bootstrap with gcc-4.9).

The reason is that generations of sinfo.h appears now to _require_ support for atomics (I assume that's intended).

In fact, w.r.t atomics there's no need to treat powerpc-darwin any differently from other ppc platform.

The patch below enables them which restores bootstrap and fixes 15 acts and 8 gnat regressions (which essentially, leaves GCC trunk on parity with gcc-4.9 for Ada on the powerpc-darwin9 platform).

This is a bootstrap fail, albeit for an unmentioned target - however, it is entirely local to the platform, so 
OK for trunk?

Iain

Tested on powerpc-darwin9, x86_86-darwin12 and x86_64-darwin12 X powerpc-darwin9 (and by Dominique too, thanks!).

gcc/ada:
	* gcc-interface/Makefile.in (darwin, powerpc): Enable atomics.

Comments

Arnaud Charlet March 29, 2015, 6:43 p.m. UTC | #1
> Currently Ada bootstrap is broken for bootstrap compiler == gcc-trunk, and
> platform == powerpc-darwin9 (although it is possible to bootstrap with
> gcc-4.9).
> 
> The reason is that generations of sinfo.h appears now to _require_ support
> for atomics (I assume that's intended).

No, that's definitely not intended, and I doubt this is the case since there
are other platforms without atomic support.

> In fact, w.r.t atomics there's no need to treat powerpc-darwin any
> differently from other ppc platform.
> 
> The patch below enables them which restores bootstrap and fixes 15 acts and 8
> gnat regressions (which essentially, leaves GCC trunk on parity with
> gcc-4.9 for Ada on the powerpc-darwin9 platform).
> 
> This is a bootstrap fail, albeit for an unmentioned target - however, it is
> entirely local to the platform, so
> OK for trunk?

OK on principle, but that doesn't explain the underlying issue you got,
since atomics should definitely not be needed for bootstrap.

Can you give more details on the failure you got?

Arno
Iain Sandoe March 29, 2015, 6:54 p.m. UTC | #2
Hi Arnaud,

On 29 Mar 2015, at 19:43, Arnaud Charlet wrote:

>> Currently Ada bootstrap is broken for bootstrap compiler == gcc-trunk, and
>> platform == powerpc-darwin9 (although it is possible to bootstrap with
>> gcc-4.9).
>> 
>> The reason is that generations of sinfo.h appears now to _require_ support
>> for atomics (I assume that's intended).
> 
> No, that's definitely not intended, and I doubt this is the case since there
> are other platforms without atomic support.
> 
>> In fact, w.r.t atomics there's no need to treat powerpc-darwin any
>> differently from other ppc platform.
>> 
>> The patch below enables them which restores bootstrap and fixes 15 acts and 8
>> gnat regressions (which essentially, leaves GCC trunk on parity with
>> gcc-4.9 for Ada on the powerpc-darwin9 platform).
>> 
>> This is a bootstrap fail, albeit for an unmentioned target - however, it is
>> entirely local to the platform, so
>> OK for trunk?
> 
> OK on principle, but that doesn't explain the underlying issue you got,
> since atomics should definitely not be needed for bootstrap.
> 
> Can you give more details on the failure you got?

recent trunk (say 221750) built without the patch, is installed and then used as the bootstrap compiler.

At stage #1 the following fail occurs when xsinfo is run to generate sinfo.h:

(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
raised PROGRAM_ERROR : s-atocou.adb:57 explicit raise

Looking at this code, it indicates that it is a dummy implementation for platforms without an atomic increment support.

hence, I concluded (possibly erroneously) that such support is now required in some way.

We can try and analyse further (slowish hardware), if necessary - but this is repeatable on two different setups.

thanks
Iain
Arnaud Charlet March 29, 2015, 7:01 p.m. UTC | #3
> (cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
> raised PROGRAM_ERROR : s-atocou.adb:57 explicit raise
> 
> Looking at this code, it indicates that it is a dummy implementation for
> platforms without an atomic increment support.
> 
> hence, I concluded (possibly erroneously) that such support is now
> required in some way.

No, this definitely looks like something else is wrong.

> We can try and analyse further (slowish hardware), if necessary - but this is
> repeatable on two different setups.

Well given the platform and given that your patch only impacts ppc-darwin,
probably not worth it. I suspect there was a latent bug in the target pairs
for this old platform that got exposed recently.

BTW, what's the plan wrt ppc-darwin and newer versions of GCC? Seems surprising
for a quickly moving target such as darwin to still want to maintain recent
versions of GCC.

Arno
Iain Sandoe March 29, 2015, 7:22 p.m. UTC | #4
On 29 Mar 2015, at 20:01, Arnaud Charlet wrote:

>> (cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
>> raised PROGRAM_ERROR : s-atocou.adb:57 explicit raise
>> 
>> Looking at this code, it indicates that it is a dummy implementation for
>> platforms without an atomic increment support.
>> 
>> hence, I concluded (possibly erroneously) that such support is now
>> required in some way.
> 
> No, this definitely looks like something else is wrong.
> 
>> We can try and analyse further (slowish hardware), if necessary - but this is
>> repeatable on two different setups.
> 
> Well given the platform and given that your patch only impacts ppc-darwin,
> probably not worth it. I suspect there was a latent bug in the target pairs
> for this old platform that got exposed recently.

makes sense - there were also 15 acats and 8 gnat regressions.

> BTW, what's the plan wrt ppc-darwin and newer versions of GCC? Seems surprising
> for a quickly moving target such as darwin to still want to maintain recent
> versions of GCC.

On the ppc-side, my QuadG5 is still in daily use (and has been for 10years) - not just building compilers either :-).
I guess, when that dies, both interest and ability to maintain the powerpc-darwin port will reduce (the G4s I have running are somewhat too slow for compiler devt).

The point of building Ada is more to explore "corner-cases in code-gen" than anything (I doubt there are many Ada users still on powerpc-darwin).  Still, one doesn't like to see things broken for no good reason.

As far as the X86 side is concerned, in the "non-bleeding-edge-cs" world, as I'm sure you're aware, there are still lots of commercial folks supporting at least 10.6    I have a bunch of core duo hardware also in daily use - which won't support anything > 10.6.

Hobby-wise, there are still a few champions building key applications for the last version of ppc - i.e. 10.5.

I'd say these uses above are most likely to be the ones interested in modern support from GCC.

From a "hobby effort" point of view (since that's what this is) most improvements for modern darwin are applicable across the patch, so no loss in supporting the older ones.  TBH our biggest hassle is the amount of time we spend chasing breakage instead of trying to make improvements ;-).

Of course, there's no question that the modern platform has considerably more users now than a few years ago - it would be good to improve the quality of the compiler there too.

---

So, FAOD, you're OK with my applying the patch to trunk for gcc-5?

thanks
Iain
Arnaud Charlet March 29, 2015, 8:11 p.m. UTC | #5
> So, FAOD, you're OK with my applying the patch to trunk for gcc-5?

Yes, that's fine.
diff mbox

Patch

diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index 60c1b5b..ecc443e 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2321,7 +2321,9 @@  ifeq ($(strip $(filter-out darwin%,$(target_os))),)
       s-intman.adb<s-intman-posix.adb \
       s-osprim.adb<s-osprim-posix.adb \
       a-numaux.ads<a-numaux-darwin.ads \
-      a-numaux.adb<a-numaux-darwin.adb
+      a-numaux.adb<a-numaux-darwin.adb \
+      $(ATOMICS_TARGET_PAIRS) \
+      $(ATOMICS_BUILTINS_TARGET_PAIRS)
 
     ifeq ($(strip $(MULTISUBDIR)),/ppc64)
       LIBGNAT_TARGET_PAIRS += \