Bug 242506

Summary: lang/gcc9: powerpc: cc1: internal compiler error: Segmentation fault (on FreeBSD 12.1-RELEASE-p1)
Product: Ports & Packages Reporter: canardo <canardo909>
Component: Individual Port(s)Assignee: Piotr Kubaj <pkubaj>
Status: Closed FIXED    
Severity: Affects Some People CC: frankenbox, gerald, gustavo.romero, lfmorrison, pkubaj, powerpc, tibikuera
Priority: --- Keywords: needs-patch
Version: LatestFlags: gerald: merge-quarterly-
Hardware: powerpc   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241125

Description canardo 2019-12-08 11:56:34 UTC
Problem found when compiling GCC9 on PowerPC with FreeBSD 12.1-RELEASE-p1 powerpc

# cd /usr/ports/lang/gcc9
# make install clean
...
...
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc9/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
gmake[5]: *** [/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/gcc'
gmake[4]: *** [Makefile:4662: all-stage1-gcc] Error 2
gmake[4]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[3]: *** [Makefile:22474: stage1-bubble] Error 2
gmake[3]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[2]: *** [Makefile:22806: bootstrap-lean] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
===> Compilation failed unexpectedly.



Following fix of bug #241125, I'm trying to compile GCC9 on a laptop Apple Powerbook G4 17" with 2x1GB ram, in command line, using root as user.

HARDWARE INFOS
# uname -mrs
FreeBSD 12.1-RELEASE-p1 powerpc

# getconf LONG_BIT
32

# sysctl -a hw.model
hw.model: Motorola PowerPC 7447A

# sysctl hw | egrep 'hw.(phys|user|real)'
hw.physmem: 2112737280
hw.usermem: 2061774848
hw.realmem: 2112737280

# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0s4       4194304        0  4194304     0%

# sysctl kern.maxssiz
kern.maxssiz: 67108864


SOFTWARE INFOS
# $SHELL --version
tcsh 6.20.00 (Astron) 2016-11-24 (powerpc-motorola-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec

# limits
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize              1048576 kB
  stacksize               65536 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked         infinity kB
  maxprocesses             6656
  openfiles               58023
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB
  kqueues              infinity
  umtxp                infinity


While running GCC9 compilation in one shell, I run following command in another shell

# ps -aO ssiz | sort -r -k 2 | more

 PID SSIZ TT  STAT    TIME COMMAND
1073  128 v7  Is+  0:00.01 /usr/libexec/getty Pc ttyv7
1072  128 v6  Is+  0:00.01 /usr/libexec/getty Pc ttyv6
1071  128 v5  Is+  0:00.01 /usr/libexec/getty Pc ttyv5
1070  128 v4  Is+  0:00.01 /usr/libexec/getty Pc ttyv4
1069  128 v3  Is+  0:00.01 /usr/libexec/getty Pc ttyv3
1068  128 v2  Is+  0:00.01 /usr/libexec/getty Pc ttyv2
1067  128 v1  Is+  0:00.01 /usr/libexec/getty Pc ttyv1
1066  128 v0  Is+  0:00.01 /usr/libexec/getty Pc ttyv0
1101  128  1  Ss   0:00.10 -csh (csh)
1778  128  1  S+   0:00.01 sort -r -k 2
1777  128  1  R+   0:00.01 ps -aO ssiz
1779  128  1  R+   0:00.01 more
1077  128  0  Ss   0:00.13 -csh (csh)
1484  128  0  S+   0:02.70 gmake DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=powerpc-portbld-freebsd12.1 bindir=/usr/local/bin datadir=/usr/local/share exec_prefix=/usr/local includedir=/usr/local/i
1179  128  0  S+   0:00.24 gmake DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=powerpc-portbld-freebsd12.1 bindir=/usr/local/bin datadir=/usr/local/share exec_prefix=/usr/local includedir=/usr/local/i
1164  128  0  S+   0:00.17 gmake DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=powerpc-portbld-freebsd12.1 bindir=/usr/local/bin datadir=/usr/local/share exec_prefix=/usr/local includedir=/usr/local/i
1154  128  0  S+   0:00.17 gmake -f Makefile -j1 MAKEINFOFLAGS=--no-split bootstrap-lean
1135  128  0  S+   0:00.11 make install clean
1148  128  0  S+   0:00.09 make CONFIG_DONE_GCC9=1 /usr/ports/lang/gcc9/work/.install_done.gcc._usr_local
1775  128  0  S+   0:00.04 /usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc9/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/t
1153  128  0  S+   0:00.01 /bin/sh -e -c (cd /usr/ports/lang/gcc9/work/.build; if ! /usr/bin/env PERL_USE_UNSAFE_INC=1 XDG_DATA_HOME=/usr/ports/lang/gcc9/work  XDG_CONFIG_HOME=/usr/ports/lang/gcc9/work  HOM
1776  128  0  R+   0:00.01 /usr/ports/lang/gcc9/work/.build/./gcc/cc1 -quiet -nostdinc -iprefix /usr/ports/lang/gcc9/work/.build/gcc/../lib/gcc9/gcc/powerpc-portbld-freebsd12.1/9.2.0/ -isystem /usr/ports/la


I tried to install /usr/ports/devel/libunwind/, but it is not available for powerpc arch
Comment 1 Tibikuera 2019-12-08 15:21:55 UTC
I have the same FreeBSD release, long_bit and hw.model as canardo's and got the same error message.

In addition, after that, in the port folder /usr/ports/lang/gcc9, I run ' make clean'   and run ' make install MAKE_JOBS_UNSAFE=yes'  and got, again, the same message.

Cheers
Comment 2 Piotr Kubaj freebsd_committer 2019-12-09 12:31:31 UTC
powerpc64 has the same issue, that's why it uses lang/gcc8 to build lang/gcc9.

Could you restart build after make clean with make USE_GCC=8? It will first build GCC8, then using that, GCC9.

Note that you could also try FreeBSD head with Clang (Clang is not used by default now, but it will be soon, for now some base patches are necessary). There are test images at https://1drv.ms/u/s!AkaL2-RoR7mimbUA9xlATFi5wo6BpQ?e=MgPDkJ
Comment 3 Gustavo Romero 2019-12-09 12:46:17 UTC
(In reply to canardo from comment #0)

Hello, canardo,

This is a segfault in gcc9 selftest framework due to a wrong use o singleton dump_context get() method.

This is the fix I intend to send upstream for review:

commit e02cbe3668cc63c8da1fed404c306c1ed50235f3
Author: Gustavo Romero <gromero@linux.vnet.ibm.com>
Date:   Mon Dec 9 07:37:49 2019 -0500

    devel/gcc9: Fix ICE due to wrong singleton get() use
    
    Currently get() method of singleton is being used in a way a new class is
    instantiated, which call singleton dtor's freeing memory that is referenced
    after free() is called generating an internal compiler error.
    
    Fix is simply call get() appropriately, i.e. call it directly since it's in
    fact an static method, just as usually any get method in a singleton is by
    design.

diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index 7ea8f85..fc17fe9 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -2076,7 +2076,7 @@ temp_dump_context::temp_dump_context (bool forcibly_enable_optinfo,
                                      bool forcibly_enable_dumping,
                                      dump_flags_t test_pp_flags)
 : m_context (),
-  m_saved (&dump_context ().get ())
+  m_saved(&dump_context::get())
 {
   dump_context::s_current = &m_context;
   if (forcibly_enable_optinfo)


Could you please try and check if it fixes the error you've posted?

Thanks.
Comment 4 Gustavo Romero 2019-12-09 12:48:23 UTC
(In reply to Piotr Kubaj from comment #2)

Hmm that's interesting, Piotr. I was not able to reproduce it on POWER8 VMs, that's way I'm not able yet to understand why it doesn't reproduce on 64-bit, but you're saying that actually it does reproduce on 64-bit. Would you mind to see if the fix I've pasted above also fixes the issue on 64-bit as you mentioned?

Thanks!
Comment 5 canardo 2019-12-09 13:28:09 UTC
In reply to comment #3, I manually updated dumpfile.c with the proposed fix, and I don't get the error anymore. Congratulations !

(GCC9 compilation is still running as I type)
Comment 6 Piotr Kubaj freebsd_committer 2019-12-09 13:38:32 UTC
With base GCC:
/usr/local/poudriere/ports/default/lang/gcc9/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/l
ang/gcc9/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld
-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include   -fno-checking -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -m32 -fPIC -mstrict-align -O2  -g -O2 -pipe  -DLIBICONV_PLUG -fno-strict-aliasing  -DIN_GCC    -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC -pthread -mno-minimal-toc -I. -I. -I../../.././gcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/. -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/../gcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/../include  -DHAVE_CC_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: store-merging
In file included from /usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.c:56:
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.c: In function '__muldi3':
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.h:219:20: internal compiler err
or: Segmentation fault
  219 | #define __NDW(a,b) __ ## a ## di ## b
      |                    ^~
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.h:273:18: note: in expansion of
 macro '__NDW'
  273 | #define __muldi3 __NDW(mul,3)
      |                  ^~~~~
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.c:548:1: note: in expansion of 
macro '__muldi3'
  548 | __muldi3 (DWtype u, DWtype v)
      | ^~~~~~~~


Same after adding to MAKE_ARGS parameters that allow GCC8 to build (CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" BOOT_CFLAGS="-O1").
Comment 7 Piotr Kubaj freebsd_committer 2019-12-09 13:52:23 UTC
I tried to build with -O0 in those parameters instead and it errored later on:
/usr/local/poudriere/ports/default/lang/gcc9/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc9/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include   -fno-checking -O0 -m32 -fPIC -mstrict-align -O2  -O0 -DIN_GCC    -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC -pthread -mno-minimal-toc -I. -I. -I../../.././gcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/. -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/../gcc -I/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/../include  -DHAVE_CC_TLS  -o _clear_cache.o -MT _clear_cache.o -MD -MP -MF _clear_cache.dep -DL_clear_cache -c /usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: uncprop
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c: In function '__do_global_ctors_aux':
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c:663:1: internal compiler error: Segmentation fault
  663 | __do_global_ctors_aux (void)
      | ^~~~~~~~~~~~~~~~~~~~~
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
during GIMPLE pass: uncprop
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c: In function 'deregister_tm_clones':
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c:275:1: internal compiler error: Segmentation fault
  275 | deregister_tm_clones (void)
      | ^~~~~~~~~~~~~~~~~~~~
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
during GIMPLE pass: uncprop
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c: In function '__do_global_ctors_aux':
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c:663:1: internal compiler error: Segmentation fault
  663 | __do_global_ctors_aux (void)
      | ^~~~~~~~~~~~~~~~~~~~~
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
during GIMPLE pass: uncprop
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c: In function 'deregister_tm_clones':
/usr/local/poudriere/ports/default/lang/gcc9/work/gcc-9.2.0/libgcc/crtstuff.c:275:1: internal compiler error: Segmentation fault
  275 | deregister_tm_clones (void)
      | ^~~~~~~~~~~~~~~~~~~~
Comment 8 Gustavo Romero 2019-12-09 15:28:46 UTC
(In reply to Piotr Kubaj from comment #6)

Hi Piotr. Thanks for trying the patch.

So, on 64-bit if the patch is not applied you get the ICE exactly as in Canardo's first comment in this bug, i.e. on gcc9 selftest code?

Is it G5 or a different machine?

I'm asking because it looks a different ICE than the one reported by Canardo in this bug.
Comment 9 Gustavo Romero 2019-12-09 15:30:56 UTC
(In reply to canardo from comment #5)

Hi Canardo,

Thanks for trying the patch. Please let us know if you manage to finish the gcc9 build. I was able to finish and get a sane gcc9 (it seems) and with it I've built several packages for test, like git and all its dependencies.
Comment 10 canardo 2019-12-10 11:08:57 UTC
GCC9 compilation finished successfully, after 18 hours (yes eighteen) !
Next step is now xorg :o

Congratulations, and thanks for your help.
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-13 02:44:01 UTC
@All Could we get any proposed patch included as an attachment to this issue please, such that it may be QA'd, approved (explicitly by maintainer, or by maintainer timeout), committed and merged

@Gerald If you'd like another committer (such as pkubaj) to coordinate resolution, please ask them to assign themselves if they're able to
Comment 12 Piotr Kubaj freebsd_committer 2019-12-15 12:08:13 UTC
(In reply to Gustavo Romero from comment #8)
Yes, I get similar error.

This is on POWER9 workstation.
Comment 13 Tibikuera 2019-12-16 21:47:35 UTC
(In reply to Piotr Kubaj from comment #2)
Thank you Piotr, make USE_GCC=8 worked for me.
Comment 14 Gustavo Romero 2019-12-16 22:18:54 UTC
(In reply to Tibikuera from comment #13)

Hi. So does it mean that the patch above that Canardo tried and was able to build gcc9 using base gcc did not work for you?
Comment 15 Gerald Pfeifer freebsd_committer 2019-12-22 01:05:58 UTC
Hej Piotr (et al): I have been completely off the grid, unexpectedly, 
for the last two weeks, but do not have infrastructure to verify things
on powerpc/powerpc64 platforms.

Would you mind proposing a fix, should there be any needed (i.e., this
is not specific to a local configuration or system)?

If this is about adding powerpc along powerpc64 somewhere, definitely
pre-approved. If it's something else, let's understand what it is?

Thank you.
Comment 16 Tibikuera 2019-12-25 19:37:05 UTC
(In reply to Gustavo Romero from comment #14)
Hi, no. I tried Piotr's advice before your advice was posted and, since it worked, I preferred to keep it that way and do nothing further about it.
Comment 17 Piotr Kubaj freebsd_committer 2020-01-04 12:14:51 UTC
(In reply to Gerald Pfeifer from comment #15)
Gustavo's patch (from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242506#c3) seems ok (the port builds on ppc32) but I had to build with MAKE_JOBS_UNSAFE=yes. It segfaults somewhere in the middle of the build otherwise and I couldn't find the exact error.
Comment 18 Piotr Kubaj freebsd_committer 2020-01-14 20:03:11 UTC
@Gustavo, @gerald:

FYI, I compiled this port on head with powerpc (32-bit) with no patches at all, so it seems to be necessary only on 11 and 12.
Comment 19 Gustavo Romero 2020-01-15 15:00:24 UTC
Hi Piotr and Tibukuera,

Thanks for the additional information.

Piotr, thanks. I was only able to reproduce the issue related to the patch I proposed on 12 indeed (ppc32), on the environment promptly provided by a fresh install from a 12 ISO. I'll give a try to head when possible.

Finally, on comment #17, I'm wondering what MAKE_JOBS_UNSAFE=yes would change exactly on the build process? I never used it on my builds, so I don't know how it could help the build.

Cheers.
Comment 20 Piotr Kubaj freebsd_committer 2020-01-15 17:19:18 UTC
(In reply to Gustavo Romero from comment #19)
MAKE_JOBS_UNSAFE=yes forces -j 1 instead of using all the threads that CPU provides.
Comment 21 lfmorrison 2020-01-15 21:57:43 UTC
(In reply to Gustavo Romero from comment #19)

I can confirm that the problem you addressed in your patch is reliably reproduced with a 12.1-RELEASE poudriere jail on a Mac Mini G4 (32-bit powerpc) running 12.1-RELEASE.

The patch you proposed does yield a successful build.
Comment 22 MikeH 2020-01-31 17:58:34 UTC
I should have been more clear. Sorry for that.
I have an AMD64 system.
I did try it multiple times (after seeing your earlier suggestion) with/without PLUGINS enabled.
Mine fails with, and succeeds without it enabled.

I know this doesn't line up with the other reports above, but I wanted to mention it.  Looks like the OP is getting the seg fault with it disabled, so I don't know that my info is much help.
Comment 23 Gerald Pfeifer freebsd_committer 2020-02-02 21:48:09 UTC
*** Bug 243666 has been marked as a duplicate of this bug. ***
Comment 24 Gerald Pfeifer freebsd_committer 2020-02-02 22:45:35 UTC
(In reply to Gustavo Romero from comment #3)
> This is the fix I intend to send upstream for review:
>
> commit e02cbe3668cc63c8da1fed404c306c1ed50235f3
> Author: Gustavo Romero <gromero@linux.vnet.ibm.com>
> Date:   Mon Dec 9 07:37:49 2019 -0500
>
>   devel/gcc9: Fix ICE due to wrong singleton get() use
 
I have not seen this on gcc-patches in December or January, Gustavo.

Are you still planning to submit it there? Any hold-off?
Comment 25 Piotr Kubaj freebsd_committer 2020-04-05 02:33:47 UTC
@Gustavo
Any info about this patch?
Comment 26 Gustavo Romero 2020-04-06 19:32:05 UTC
(In reply to Piotr Kubaj from comment #25)

Hi guys,

I'm really sorry for the delay. It's been hard to catch up this things ...

I'm posting it for review today.

Best regards,
Gustavo
Comment 27 Gustavo Romero 2020-04-06 23:51:47 UTC
Gerald, sorry, I was traveling abroad and missed your first ping.

Piotr, thanks for pinging me again and apologies for the delay since the first ping on IRC, things piled up on my desk and I'm catching up with them.

Stay safe, folks :)

For the records, patch posted upstream for review:

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543388.html


Kind regards,
Gustavo
Comment 28 Piotr Kubaj freebsd_committer 2020-04-07 09:28:24 UTC
(In reply to Gustavo Romero from comment #27)
Thanks!

Also, I just checked with base GCC on powerpc64 again. It doesn't fix the build, but it makes the build progress further, so when this patch is committed, I might be able to ditch gcc8 dependency. So you should state in your commit that it's also relevant on 64 bits.

BTW, I saw you mentioned we have GCC 4.7 in base. This is incorrect, we have 4.2.1, the last GPLv2 release.
Comment 29 commit-hook freebsd_committer 2020-04-25 12:26:59 UTC
A commit references this bug:

Author: pkubaj
Date: Sat Apr 25 12:26:35 UTC 2020
New revision: 532950
URL: https://svnweb.freebsd.org/changeset/ports/532950

Log:
  lang/gcc9: build with base GCC on powerpc64 elfv1

  Instead of using lang/gcc8 for bootstrapping gcc9 on powerpc64 elfv1, use directly base gcc.
  Necessary changes:
  - CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0" in CONFIGURE_ENV and MAKE_ENV. Otherwise bootstrapped compiler fails later in the build with segfault.
  - CRTSTUFF_T_CFLAGS has changed optimizations to -O0, instead of -O2. -O2 worked in gcc8, because there was no -fno-asynchronous-unwind-tables flag added to CRTSTUFF_T_CFLAGS. Since this works when building with clang on powerpc64 elfv2, this patch is added to EXTRA_PATCHES, only on powerpc64 elfv1,
  - BOOT_CFLAGS has added ? before =. This is to allow overriding BOOT_CFLAGS in CONFIGURE_ENV and MAKE_ENV.
  - A patch by Gustavo Romero to gcc/dumpfile.c is necessary to allow compiling with base GCC, otherwise base GCC hits ICE. Incidentally, this patch alone also fixes build for powerpc (32 bits) with base GCC.

  Bump PORTREVISION for dependency change.

  PR:		245511, 242506
  Approved by:	gerald (maintainer timeout)

Changes:
  head/lang/gcc9/Makefile
  head/lang/gcc9/files/extra-patch-libgcc_config_rs6000_t-crtstuff
  head/lang/gcc9/files/patch-Makefile.in
  head/lang/gcc9/files/patch-gcc_dumpfile.c