Bug 239813 - Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
Summary: Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 AB...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Some People
Assignee: Gerald Pfeifer
URL:
Keywords:
: 240076 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-08-13 09:42 UTC by Mark Linimon
Modified: 2019-11-20 08:07 UTC (History)
5 users (show)

See Also:


Attachments
patches to lang/gcc9 (7.17 KB, patch)
2019-08-13 09:42 UTC, Mark Linimon
no flags Details | Diff
replacement for earlier patch to gcc9/Makefile (941 bytes, patch)
2019-08-28 13:09 UTC, Mark Linimon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Linimon freebsd_committer freebsd_triage 2019-08-13 09:42:59 UTC
Created attachment 206484 [details]
patches to lang/gcc9

This patch (as of yet untested) brings the changes from PR 239266 and http://mikael.urankar.free.fr/FreeBSD/powerpc64/lang_gcc8_elfv2.diff to lang/gcc9.
Comment 1 Gerald Pfeifer freebsd_committer 2019-08-13 12:38:03 UTC
I've bit my tongue a couple of times in the last hour and will therefore
not as blunt as I would have been back then.  Still...

 1. I really, really, really would appreciate a bit, just a bit, of
collaboration with upstream here.  The last time I properly reported
a powerpc64 specific issue on FreeBSD with upstream GCC it got fixed
and backported to all relevant release branches within 24 hours.

 2. FreeBSD has an upstream maintainer in GCC, so there should be zero
reason patching files named *freebsd* locally.

 3. I do appreciate getting bug reports that include fixes, but what I
have seen on the powerpc* front as of lately looked a bit random.  With
the proposed patchset here, for example (a) two of the patches are 
tackling the very same issue, (b) patch-gcc_config_rs6000_freebsd64.h	
does something completely different than its description, and (c)
disabling BOOTSTRAP is incorrect pretty much by definition.

 4. Instead of opening new issues, it would be nice to get feedback
on existing ones, e.g. PR 239266 (which relates to item (a) above).
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2019-08-13 23:20:50 UTC
I'll keep this as a local patchset on ppcdevref for now.

I generated this patchset so that I could make progress on the "powerpc64 now defaults to clang" task -- so that we can minimize the regressions that users will experience during the imminent Flag Day.

That task is taking all of my time right now.  Given the many hundreds of changes I have been generating and/or testing, I do not have the cycles to work with every upstream -- the task would never complete, as new ports are added, and, in particular, upgrades to both llvm and gcc happen underneath me.

So, I have not taken the time to investigate the Perfect Way to handle this issue.  I merely modified an existing patchset that allowed me to proceed on testing gcc8-dependent ports, over to gcc9, so that I could proceed on testing the thousands of gcc9-based ports.
Comment 3 Gerald Pfeifer freebsd_committer 2019-08-24 11:27:48 UTC
(In reply to Mark Linimon from comment #2)
> That task is taking all of my time right now.  Given the many hundreds
> of changes I have been generating and/or testing, I do not have the
> cycles to work with every upstream

Yes, but there are also others interested in powerpc and working with
upstream on the toolchain side just is the right thing.

And I helped, but have not been getting feedback from anyone (until I
pushed again) when proposing a patch to work around one of the clang
issues.

Anyway, lang/gcc8 and lang/gcc9 now carry my patch which Mark Millard
kindly verified -- lang/gcc9/files/patch-clang-vec_step.

That should obsolete most of the patchset in this PR (most of which was
not necessary anyway). In particular gcc/tree-vect-loop.c should not see
*any* further changes.

Disabling the BOOTSTRAP option still looks very wrong, and does not seem
to be required by other powerpc users.
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2019-08-24 11:50:30 UTC
I am currently going through the process of rebuilding gcc8 and gcc9, with the patches I had been given and also the latest committed patches, on both of the systems that I have been given access to (both gcc-based and clang-based), and
*very carefully* writing down which result I got from which.

Each run takes the better part of a day.

When that is *complete* I will provide it.

I was not the person that filed the initial report on gcc8, so you will have to take it up with that person.  I thought by porting over that patch that I *might* help other users with gcc9.  Clearly this was not the case and I apologize.

I do have proof that gcc9 does not build on powerpc64 with clang in base but until I can annotate *specifically* the error messages and the patches involved I am going to wait to post it.
Comment 5 Piotr Kubaj freebsd_committer 2019-08-24 17:28:08 UTC
*** Bug 240076 has been marked as a duplicate of this bug. ***
Comment 6 Piotr Kubaj freebsd_committer 2019-08-24 17:31:49 UTC
With today's patches committed, we only need for gcc8:
Index: Makefile
===================================================================
--- Makefile    (revision 509727)
+++ Makefile    (working copy)
@@ -62,7 +62,11 @@

 .elif ${ARCH} == powerpc64
 CONFIGURE_ENV+=        UNAME_m="powerpc64"
+.if ${CHOSEN_COMPILER_TYPE} == gcc
 MAKE_ARGS+=    CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" BOOT_CFLAGS="-O1" # PR235975
+.else
+CONFIGURE_ARGS+=       --with-abi=elfv2
+.endif

 .elif ${ARCH} == powerpcspe
 CONFIGURE_ARGS+=       --with-cpu=8548 --enable-e500_double --without-fp

And for gcc9:
Index: Makefile
===================================================================
--- Makefile    (revision 509727)
+++ Makefile    (working copy)
@@ -61,7 +61,11 @@

 .elif ${ARCH} == powerpc64
 CONFIGURE_ENV+=        UNAME_m="powerpc64"
+.  if ${CHOSEN_COMPILER_TYPE} == gcc
 USE_GCC=       8
+.  else
+CONFIGURE_ARGS+=       --with-abi=elfv2
+.  endif
 .endif

 LANGUAGES:=    c,c++,objc,fortran
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2019-08-28 13:09:24 UTC
Created attachment 206970 [details]
replacement for earlier patch to gcc9/Makefile

This is the next patch I will test on the elfv2 machine.  This is pkubaj's patch but reformatted it for Bugzilla.
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2019-08-29 09:38:06 UTC
(In reply to Mark Linimon from comment #7)

A build with these patches failed due to a stale tree:

  pkg-static: cannot load keyword from /usr/ports/Keywords/ldconfig.ucl: No such file or directory

so I will need to SVN update and rebuild.
Comment 9 Gerald Pfeifer freebsd_committer 2019-08-29 12:42:56 UTC
Mark, I do believe (more than just hope) that basic building of gcc9
and gcc8 should be fine now after the patches I applied to the ports
(though I'll keep pushing for either clang to be fixed or GCC to work
around this upstream as well).


There is another issues which Piotr has been raising, and which his
proposed patches in the PR now are about, and that is an update of 
the ABI to ELFv2 which is orthogonal to this question.

Shall we continue to track the ABI update in this issue and the "clang
breaks GCC on powerpc" issue on PR239266?

(Both this issues equally affect lang/gcc8 and lang/gcc9, and any
fixes/adjustments should be the same for two, so splitting by underlying
issue instead of version of GCC makes things easier.) 


Of course if you still see regular build failures, please advise and we
will jointly see how to address them with priority!
Comment 10 Andreas Tobler freebsd_committer 2019-09-01 20:45:14 UTC
(In reply to Piotr Kubaj from comment #6)

Is this intended? If you build gcc with clang you produce a gcc which produces different binaries than one built with gcc?
I think the whole clang switch is not really planned, is it?
Comment 11 Piotr Kubaj freebsd_committer 2019-09-01 20:52:17 UTC
(In reply to Andreas Tobler from comment #10)
If you build it with GCC, it means you run ELFv1, because GCC is used in base on ELFv1 systems.

If you build with Clang, it's an ELFv2 system.

So yes, both GCC's will generate different binaries. When running on ELFv1 system, it's reasonable to generate ELFv1 binaries.

"I think the whole clang switch is not really planned, is it?"
Since powerpc is a tier-2 platform, the developers have to do required work on their own. Of course, you are free to help, if you wish to.
Comment 12 Mark Linimon freebsd_committer freebsd_triage 2019-09-01 20:53:48 UTC
(In reply to Gerald Pfeifer from comment #9)
> I do believe (more than just hope) that basic building of gcc9
> and gcc8 should be fine now after the patches I applied to the ports.

I have now confirmed this.

> Shall we continue to track the ABI update in this issue and the "clang
> breaks GCC on powerpc" issue on PR239266?

I have no opinion at this point.  I'll let the other folks involved decide.
Comment 13 Andreas Tobler freebsd_committer 2019-09-01 21:14:47 UTC
(In reply to Piotr Kubaj from comment #11)

What happens if you build gcc with gcc on an elfv2 system? Back to elfv1!

That was the question about planning.

You can do the switch from elfv1 to elfv2 on -CURRENT at a dedicated time and not before. And you have to do it on all components which affects the abi at once. Otherwise you'll might have an abi mess.
Comment 14 Brandon Bergren freebsd_committer 2019-09-01 21:23:24 UTC
Specifically here, the existance of base clang can be used as an indication that an ELFv2 system is in use, because:

a) base ld.bfd only supports ELFv1, and is missing relocations needed to link anything built by clang, ELFv1 or ELFv2.

b) base ld.lld only supports ELFv2. The original ELFv1 support has long been removed from the lld code upstream.

While it would theoretically be possible to have an ELFv1 system with base clang installed, you would only be able to do that by disabling LLD and using the base/binutils port to replace the system linker, and rebuilding world, as binutils from ports is the only modern linker supporting ELFv1.

Once the flag day happens, we'll have an actual __FreeBSD_version value to target so that upstream can properly support the ABI switch.
Comment 15 Brandon Bergren freebsd_committer 2019-09-01 21:31:12 UTC
The flag day patches and progress tracking are all be listed on https://wiki.freebsd.org/powerpc/llvm-elfv2 by the way.

Good point re: building gcc with gcc. I don't think there's a good way to cover that case until after flag day. At which point we'll have a version number to report upstream as the cutover point and get this fixed properly.
Comment 16 Gerald Pfeifer freebsd_committer 2019-09-02 12:47:05 UTC
Thanks for the background, Brandon!  I was guessing something similar,
yet it's good to see more background.

Let me make sure I understand correctly, and propose some next steps:

 * The proposed patch to gcc8/Makefile and gcc9/Makefile uses the
   choice of system compiler as an indicator for a flag day. GCC
   implies ABIv1, clang implies ABIv2.
 * For the time being that is the most reliable (only reasonable?) 
   indicator available, but we can later replace it once there is
   a __FreeBSD_version assigned.
 * If the above is correct, would you mind proposing a comment for
   those Makefile patches that describes that?  Like Andreas I was
   surprised to see compiler and ABI mixed, and so will others
   probably be.

Then, I guess, the question is whether these patches should be applied
now, even though they would not make a difference, or wait for flag day?

If the former, I can approve or take care (when, ideally, you have shared
the proposed comment).

(And based on the answer we probably can/should take this PR off Marks'
shoulders then.)
Comment 17 Mark Linimon freebsd_committer freebsd_triage 2019-09-02 14:02:10 UTC
To be clear, I have only tested:

 - GG-based system with only the patches in the tree (both gcc8 and gcc9 work).
 - clang-based system with the patches in #c6 (both gcc8 and gcc9 work).

I have not tried the #c6 patches on a GCC-based system.  I can do that if needed.

I do *not* believe the clang-based system will build gcc8 or gcc9 without the patch in c6.  I can repeat that test if necessary, but I just gave the machine a day's worth of work to do (testing lang/ruby26 as default).
Comment 18 Mark Linimon freebsd_committer freebsd_triage 2019-09-02 14:56:09 UTC
(In reply to Mark Linimon from comment #17)
> I have not tried the #c6 patches on a GCC-based system.  I can do that if needed.

Actually my home machine was idle so I gave it this task.
Comment 19 Mark Linimon freebsd_committer freebsd_triage 2019-09-03 18:11:50 UTC
(In reply to Mark Linimon from comment #17)
> I have not tried the #c6 patches on a GCC-based system.  I can do that if needed.

These ports now build on a GCC-based system:

  FreeBSD blackbird1.lonesome.com 13.0-CURRENT FreeBSD 13.0-CURRENT r349478 GENERIC  powerpc
Comment 20 Mark Millard 2019-10-26 01:56:39 UTC
(In reply to Brandon Bergren from comment #14)

QUOTE
While it would theoretically be possible to have an ELFv1 system with base
clang installed, you would only be able to do that by disabling LLD and using
the base/binutils port to replace the system linker, and rebuilding world, as
binutils from ports is the only modern linker supporting ELFv1.
END QUOTE

It is more than theoretical:

I've been doing buildworld buildkernel targetting ELFv1 as an experimental
environment for years, reporting oddities that I ran into. I generally used
devel/powerpc64-binutils for both cross-builds and self-hosted-builds (more
uniformity). These days I also sometimes use base/binutils alternative and
install its builutils on the old PowerMacs that I sometimes have access to.

I've also built for ELFv1 via devel/powerpc-gcc ( and
devel/powerpc-xtoolchain-gcc ), both as cross-builds and as self-hosted-builds.

I have also tested using base/gcc to establish system compilers on the old
PowerMacs. (This is rare, however.)

Most of the time I did not build/include the old gcc 4.2.1 at all.

(I have patches involved to deal with PowerMac specific issues and a few FreeBSD
issues as well. I genrally avoided various issues via WITHOUT_LIB32= as well.)

I use ports-mgmt/poudriere-devel to build ports on old PowerMacs, at least
in more recent years.

Currently a PowerMac11,2 (2 sockets/2 cores each) is running a clang-built
system with system-clang/clang++ as the compilers and base/binutils materials.
The ports present are from ports-mgmt/poudriere-devel building them, ignoring
base/binutils materials.

I'm not claiming that there is any good reason to to try to support my odd
environment types for the transition, even if I end up frustrated with the
process of transitioning or end up starting from scratch. I might be the
only one around with such odd powerpc64 environments.

But it would be nice to have a very clear notice when the first changes
are checked-in that would not fit with such environment types, both system
check-ins and port check-ins (if there is a time frame distinction for some
reason). I'd prefer -r?????? for the system and for the ports to be explicit
in the notice.
Comment 21 Piotr Kubaj freebsd_committer 2019-11-12 20:58:27 UTC
Can you commit the patch so that we get both gcc8 and gcc9 working?
Comment 22 Gerald Pfeifer freebsd_committer 2019-11-12 22:56:14 UTC
Do we have an actual _FreeBSD_version to key of? 

If not, and the check for gcc/clang is the only one we can use, mind 
proposing a comment as I had suggested in comment #16?

Or wouldn't it be better to commit this as part of a flag day?  Happy
to pre-approve in that case.

Gerald
Comment 23 Piotr Kubaj freebsd_committer 2019-11-13 06:10:57 UTC
(In reply to Gerald Pfeifer from comment #22)
You could instead use:
.if defined(PPC_ABI) && ${PPC_ABI} == ELFv2

There's no harm in committing it now, the port won't break.
Comment 24 Piotr Kubaj freebsd_committer 2019-11-13 06:11:05 UTC
(In reply to Gerald Pfeifer from comment #22)
https://reviews.freebsd.org/D22039
Comment 25 Gerald Pfeifer freebsd_committer 2019-11-14 16:10:22 UTC
Thank you, Piotr, for the update and pointers. That looks like an elegant
way of addressing this. I'll be patching the ports in the next days.
Comment 26 commit-hook freebsd_committer 2019-11-15 20:48:13 UTC
A commit references this bug:

Author: gerald
Date: Fri Nov 15 20:47:37 UTC 2019
New revision: 517702
URL: https://svnweb.freebsd.org/changeset/ports/517702

Log:
  On versions of FreeBSD that that are new enough and made that switch
  already, use ELFv2 ABI on powerpc64.

  PR:		239813
  Submitted by:	pkubaj
  Reported by:	linimon

Changes:
  head/lang/gcc9-devel/Makefile
Comment 27 Gerald Pfeifer freebsd_committer 2019-11-15 20:53:51 UTC
(In reply to Piotr Kubaj from comment #23)
> You could instead use:
> .if defined(PPC_ABI) && ${PPC_ABI} == ELFv2

That, plus swap the two arms of the .if statement, right? ;-)

I just updated lang/gcc9-devel. Can you - Mark and/or Piotr - please
confirm this addresses what you need? Once I have your confirmation,
I'll push the same change to lang/gcc9, which is the most important
of GCC ports in the Ports Collection.
Comment 28 Mark Millard 2019-11-15 21:31:40 UTC
(In reply to Gerald Pfeifer from comment #27)

There is more than Mark in the comments. I'm only set up for
ELFv1 and currently only get little bits of time here or there
for FreeBSD activity. So it is not likely that I'd test the
ELFv2 context in an appropriate time frame.

But you may well have meant Mark L. anyway.
Comment 29 Piotr Kubaj freebsd_committer 2019-11-15 22:40:31 UTC
(In reply to Gerald Pfeifer from comment #27)
This commit fixes ABI issue, but still doesn't fix the namespace issue:
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:4595:12: error: expected unqualified-id
      tree vec_step = build_vector_from_val (cr_index_vector_type, step);
           ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:4601:39: error: expected expression
      create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi,
                                      ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7260:27: error: expected unqualified-id
  tree new_vec, vec_init, vec_step, t;
                          ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7260:26: error: expected ';' at end of declaration
  tree new_vec, vec_init, vec_step, t;
                         ^
                         ;
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7452:16: error: expected expression
      vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL);
               ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7491:75: error: expected expression
          new_stmt = gimple_build_assign (vec_def, PLUS_EXPR, induc_def, vec_step);
                                                                                 ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7522:13: error: expected expression
          vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL);
                   ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7533:25: error: expected expression
                                              def, vec_step);
                                                           ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7653:3: error: use of undeclared identifier 't'
  t = unshare_expr (new_name);
  ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7656:45: error: use of undeclared identifier 't'
  new_vec = build_vector_from_val (vectype, t);
                                            ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7657:12: error: expected expression
  vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL);
           ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7679:74: error: expected expression
  new_stmt = gimple_build_assign (vec_def, PLUS_EXPR, induc_def, vec_step);
                                                                         ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7719:7: error: use of undeclared identifier 't'
      t = unshare_expr (new_name);
      ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7722:49: error: use of undeclared identifier 't'
      new_vec = build_vector_from_val (vectype, t);
                                                ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7723:16: error: expected expression
      vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL);
               ^
/tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7731:25: error: expected expression
                                          vec_def, vec_step);
                                                           ^



So lang/gcc9 misses ABI patch and lang/gcc9-devel misses namespace patch.
Comment 30 Gerald Pfeifer freebsd_committer 2019-11-16 08:25:52 UTC
(In reply to Piotr Kubaj from comment #29)
> This commit fixes ABI issue, but still doesn't fix the namespace issue:

The latter is a bug in clang; I'll ping the toolchain folks whether
they can get this fixed.
Comment 31 Piotr Kubaj freebsd_committer 2019-11-16 13:51:26 UTC
(In reply to Gerald Pfeifer from comment #30)
It is, but you committed the workaround to lang/gcc9 anyway:
r509718 | gerald | 2019-08-24 13:25:11 +0200 (Sat, 24 Aug 2019) | 3 lines

Properly push down lang/gcc9/patch-clang-vec_step into the files/
subdirectory.

------------------------------------------------------------------------
r509717 | gerald | 2019-08-24 13:04:34 +0200 (Sat, 24 Aug 2019) | 8 lines

clang on rs6000/powerpc* unfortunately poisons user namespace by default
(without any special options or include files being required).

Until that changes (or GCC changes) we need to avoid using vec_step as a
variable name.

PR:             239266

Can that workaround be added for other GCC ports along with the ABI patch?
Comment 32 Brandon Bergren freebsd_committer 2019-11-16 14:11:22 UTC
IIRC, it's more of a limitation regarding how clang implements the vector bits in the parser directly, making them equivilent to reserved keywords, so it would be relatively difficult to fix on the clang side.
Comment 33 Gerald Pfeifer freebsd_committer 2019-11-17 22:58:05 UTC
Does lang/gcc9-devel now build and work as desired?  (I forward
ported the patch that addresses clang's issue from lang/gcc9.)

Next step then will be lang/gcc9.  I'd just love confirmation from
a powerpc64 user. Thanks!
Comment 34 Brandon Bergren freebsd_committer 2019-11-18 01:19:09 UTC
Testing on ELFv2 -- compiles fine now w/ PPC_ABI=ELFv2 and the binaries it produces appear to be correct.
Comment 35 Mark Millard 2019-11-18 01:32:46 UTC
(In reply to Gerald Pfeifer from comment #33)

I do not know the intent for devel/powerpc64-gcc relative
to future ELFv2 ABI use. Does it need anything? (May be
it is updating to gcc9 or some such first?)

I do know that devel/powerpc64-gcc does not yet have the
vec_step patch. (I still have and use my old, local one.)

(I also force objdump:devel/binutils because of other
port(s) that presume to use objdump but I tried not
building the system binutils so the attempts got failed
activity, one port that the build did not report the
failure but something-built did not work. This was a
powerpc64-gcc as master port context where a slave
port had the problem. I just decided to provide objdump
for all the slave ports by putting this material in
devel/powerpc64-gcc .)
Comment 36 commit-hook freebsd_committer 2019-11-18 04:53:45 UTC
A commit references this bug:

Author: gerald
Date: Mon Nov 18 04:53:27 UTC 2019
New revision: 517855
URL: https://svnweb.freebsd.org/changeset/ports/517855

Log:
  Update to the 20191115 snapshot of GCC 8.3.1.

  This brings a fix on the Fortran side and addresses two corner cases
  for i386.

  On versions of FreeBSD that that are new enough and made that switch
  already, use ELFv2 ABI on powerpc64. [1]

  PR:		239813 [1]
  Submitted by:	pkubaj [1]
  Reported by:	linimon [1]

Changes:
  head/lang/gcc8-devel/Makefile
  head/lang/gcc8-devel/distinfo
Comment 37 commit-hook freebsd_committer 2019-11-19 17:18:46 UTC
A commit references this bug:

Author: gerald
Date: Tue Nov 19 17:17:52 UTC 2019
New revision: 517973
URL: https://svnweb.freebsd.org/changeset/ports/517973

Log:
  Forward port r517702 | gerald | 2019-11-15 from lang/gcc9-devel:

    On versions of FreeBSD that that are new enough and made that switch
    already, use ELFv2 ABI on powerpc64.

  PR:		239813
  Submitted by:	pkubaj
  Reported by:	linimon

Changes:
  head/lang/gcc9/Makefile
Comment 38 Gerald Pfeifer freebsd_committer 2019-11-19 17:32:52 UTC
(In reply to Mark Millard from comment #35)
> I do not know the intent for devel/powerpc64-gcc relative
> to future ELFv2 ABI use. Does it need anything? (May be
> it is updating to gcc9 or some such first?)

Updating to GCC 9 would be my recomendation, though I have no
involvement with that port.

lang/gcc9-devel should be fine now, both wrt. the new ABI as well
as building with clang.

Next I'll make the remaining equivalent changes to lang/gcc9 and
lang/gcc8-devel.
Comment 39 commit-hook freebsd_committer 2019-11-20 07:52:46 UTC
A commit references this bug:

Author: gerald
Date: Wed Nov 20 07:52:29 UTC 2019
New revision: 517994
URL: https://svnweb.freebsd.org/changeset/ports/517994

Log:
  Partially forward port r517855 | gerald | 2019-11-18 from lang/gcc8-devel:

    On versions of FreeBSD that that are new enough and made that switch
    already, use ELFv2 ABI on powerpc64.

  PR:		239813
  Submitted by:	pkubaj
  Reported by:	linimon

Changes:
  head/lang/gcc8/Makefile
Comment 40 Gerald Pfeifer freebsd_committer 2019-11-20 08:07:06 UTC
I believe everything should be in place now.  (lang/gcc8-devel needs the
workaround for clang poisioning namespace on powerpc which I'll take care
of later, and that is tracked separately.)

Thank you Piotr, and Mark and Brandon for testing and input!