Page MenuHomeFreeBSD

Add powerpc.powerpcspe support for lang/gcc compilers
ClosedPublic

Authored by jhibbits on Nov 17 2017, 4:16 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 2 2024, 8:20 AM
Unknown Object (File)
Jan 12 2024, 8:14 AM
Unknown Object (File)
Dec 22 2023, 11:31 PM
Unknown Object (File)
Nov 22 2023, 1:07 AM
Unknown Object (File)
Oct 4 2023, 5:17 PM
Unknown Object (File)
Sep 30 2023, 5:17 PM
Unknown Object (File)
Sep 26 2023, 12:24 AM
Unknown Object (File)
Sep 16 2023, 3:25 AM
Subscribers

Details

Summary

This brings all modern GCC ports to powerpcspe target.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 12801
Build 13068: arc lint + arc unit

Event Timeline

gerald requested changes to this revision.Nov 18 2017, 10:54 AM

Can we focus this effort on lang/gcc6 (or lang/gcc7) which both are still maintained
upstream, as opposed lang/gcc5 which is end-of-life? lang/gcc6 also is the default
version of GCC in the ports tree.

Ideally those changes would come in via upstream (which Andreas can do) if he agrees.

As far as the Makefile goes, please leave ​ONLY_FOR_ARCHS alphabetic (so swap the
two powerpc-related items).

And let's sort in the powerpc bits alphabetically as well later in, where the .if conditions
are, so something like the following:

-.if ${ARCH} == powerpc64
-CONFIGURE_ENV+= UNAME_m="powerpc64"
-USE_GCC= 5 # Cannot require ourselves, needs to be at least 4.9.
-.endif

  • .if ${ARCH} == aarch64 || ${ARCH} == armv6 || ${ARCH} == armv7 . if ${COMPILER_TYPE} == clang . if empty(PORT_OPTIONS:MBOOTSTRAP)

@@ -81,6 +76,11 @@
MAKE_ARGS+=STAGE1_CXXFLAGS=-fbracket-depth=512
. endif
. endif
+.elif ${ARCH} == powerpc64
+CONFIGURE_ENV+= UNAME_m="powerpc64"
+USE_GCC= 5 # Cannot require ourselves, needs to be at least 4.9.
+.elif ${ARCH} == powerpcspe
+:
.endif

From my perspective this is fine for lang/gcc6 and lang/gcc7 with those changes,
but please give Andreas a chance to chime in as well.

This revision now requires changes to proceed.Nov 18 2017, 10:54 AM

I forgot to ask: how have you tested this?

And let's sort in the powerpc bits alphabetically as well later in, where the .if conditions
are, so something like the following:

Update: I am going to make this change to lang/gcc6-devel, lang/gcc7-devel and
lang/gcc8-devel over the next week (as snapshots are updated); you can then
simply copy/leverage what I've done there.

I forgot to ask: how have you tested this?

I built this on the AmigaOne Tabor board, which has a Freescale P1022 SoC.

I tried building gcc6, but gengtype segfaulted in stage 3. Everything went fine until that point, so I'm trying again with gcc5 as the bootstrap compiler. My end goal is the newer compilers, when I can successfully build them.

config.gcc: please put the double ;; on a new line.

From gcc-8.0 upwards the spe part is no longer under config/rs6000. It is under config/powerpspe.

And sorry for the delay, -ENOMULTITHREAD

@gerald wrote:

And let's sort in the powerpc bits alphabetically as well later in, where the .if conditions
are, so something like the following:

Update: I am going to make this change to lang/gcc6-devel, lang/gcc7-devel and
lang/gcc8-devel over the next week (as snapshots are updated); you can then
simply copy/leverage what I've done there.

Hi Justin, I've made these changes for you so that your adds/changes can now be smaller / isolated. :-)

Thanks to Andreas for his review. Given that Andreas is upstream maintainer for GCC, let's push these
changes into HEAD (GCC 8) and one release back (GCC 7) at least, and then take it from there? That'll
take care of lang/gcc8-devel and lang/gcc7-devel, and I'd then help with lang/gcc7 and possibly, if that
is still the default at that point, lang/gcc6*.

Makes sense?

Address all comments.

Also update to include the newer compilers too (gcc6,gcc7,gcc8 and devels)

jhibbits retitled this revision from Add powerpc.powerpcspe support for lang/gcc5 to Add powerpc.powerpcspe support for lang/gcc compilers.Dec 13 2017, 4:13 AM
jhibbits edited the summary of this revision. (Show Details)

Fix the diff

Missed lang/gcc6-devel/Makefile, and had an unnecessary change for a segment of
the gcc6 Makefile

I've build-tested gcc5 and gcc6, and patch tested the others so far. It takes a very long time to build these on this board.

The ports changes look good to me per se, thanks Justin!

I'd like to see the actual code changes go to upstream GCC first and then ideally
backported to the GCC 7 and GCC 6 branches. -> Andreas?

And can we leave out lang/gcc5 now that lang/gcc6 is the default (and GCC 5 is
end of life)?

This revision is now accepted and ready to land.Dec 14 2017, 12:22 PM

The patches look good so far, but I'd like to build a cc before I continue. Unfortunately -CURRENT is totally broken regarding PowerPC-G5. And this hunting consumed quite a lot of time. Sure, for your patch this is not needed, but _I_ need a reference if gcc bootstrap works on PowerPC.
Btw, does powerpcspe have multilib directions?

Btw, does powerpcspe have multilib directions?

I have no idea. I assume it could have multilib, but I haven't tried at all.

And can we leave out lang/gcc5 now that lang/gcc6 is the default (and GCC 5 is
end of life)?

Sure, I can drop the gcc5 changes. I kept them mostly for completeness now, but they don't need to be committed.

The patches look good so far, but I'd like to build a cc before I continue. Unfortunately -CURRENT is totally broken regarding PowerPC-G5. And this hunting consumed quite a lot of time. Sure, for your patch this is not needed, but _I_ need a reference if gcc bootstrap works on PowerPC.

andreast, were you able to get a compiler built?

I have gone ahead and committed with the tier-2 blanket.

Unfortunately this DR has been stalled for several months and I would like to see it take effect for the Q2 branch. So, even though the optimal solution would be to have the changes upstream first, I think enough time has passed.

I did do the gcc5 commit; perhaps I should not have, but I tested them all at once.

Yes, I would have prefered _not_ to touch lang/gcc5 and lang/gcc5-devel.

And there is no (good) reason gcc8-devel and even gcc7-devel and gcc6-devel should not have gone in via upstream as I had asked for between Mark and Andreas. This really is the kind of approach we've found ourselves in troubles on the GCC front for... :-(

...probably should have read: Justin and Andreas.

Yes, I would have prefered _not_ to touch lang/gcc5 and lang/gcc5-devel.

And there is no (good) reason gcc8-devel and even gcc7-devel and gcc6-devel should not have gone in via upstream as I had asked for between Mark and Andreas. This really is the kind of approach we've found ourselves in troubles on the GCC front for... :-(

But nothing had happened since November.

I can back the gcc5 changes out if you like.