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 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

(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.

(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!

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 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 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)
      | ^~~~~~~~~~~~~~~~~~~~

(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.

(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.

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 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 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.

(In reply to Piotr Kubaj from comment #2)
Thank you Piotr, make USE_GCC=8 worked for me.

(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 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.

(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 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 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.

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 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.

(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.

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 2020-02-02 21:48:09 UTC

*** Bug 243666 has been marked as a duplicate of this bug. ***

Comment 24 Gerald Pfeifer 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 2020-04-05 02:33:47 UTC

@Gustavo
Any info about this patch?

(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

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 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 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