System: Vagrant 2.2.19 generic_debian11 Linux debian11.localdomain 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux Steps to reproduce the bug: Run the bootstrap-prefix.sh
Created attachment 857817 [details] full_generic_debian11_20230314184645.log.bz2
Created attachment 857819 [details] build_generic_debian11_20230314184645.log.bz2
*** Bug 901321 has been marked as a duplicate of this bug. ***
Created attachment 857827 [details] full_generic_debian11_20230314184645.log.bz2 fixed content type
Created attachment 857829 [details] build_generic_debian11_20230314184645.log.bz2 fixed content type
fails for generic_ubuntu2204 as well
Created attachment 857915 [details] build_generic_ubuntu2204_20230315213207.log.bz2
fails for generic_ubuntu1804 as well
Created attachment 857919 [details] build_generic_ubuntu1804_20230316013840.log.bz2
(In reply to APN-Pucky from comment #7) > Created attachment 857915 [details] > build_generic_ubuntu2204_20230315213207.log.bz2 {standard input}: Assembler messages: {standard input}:2092358: Warning: end of file not at end of a line; newline inserted {standard input}:2092549: Error: unknown .loc sub-directive `vie' {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive xg++: fatal error: Killed signal terminated program cc1plus compilation terminated. Looks like OOM.
Hmm, thanks. I'll check the vms, but similar fedora-37, centos-7 and gentoo did not run into this.
On OpenIndiana I see this for sys-devel/gcc-12.2.0-r2: out of memory allocating 4064 bytes after a total of 163218456 bytes gmake[3]: *** [Makefile:2477: s-automata] Error 1 So likely, yes.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=7a6b2d23ec02e75475a6123254ccd44d73827f39 commit 7a6b2d23ec02e75475a6123254ccd44d73827f39 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-26 02:26:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 02:26:36 +0000 13.2.0: backport split match.pd changes See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927#c21. This should improve (reduce) the peak RAM usage when building GCC as it builds gimple-match in smaller chunks (previously was one huge generated file) as well as speeding up parallel build when used. i.e. This has benefits for both people building on constrained hardware (because -j1 is more effective and just means each smaller chunk is built one-at-a-time, not the massive blob) and also for people building with many jobs, as there's one less synchronisation point so the build is less serial. Motivated in particular by the upstream report (PR109927) of this being an issue on m68k with RAM usage for the single GCC process building gimple-match. (IIRC immolo and possibly dilfridge had mentioned similar issues when building some arches in qemu as well.) Note that upstream are planning on splitting insn-* as well so there are further improvements in the pipeline (see PR54179, but discussion has occurred far more recently on IRC about this and tamar is likely to look at it.). Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 (old bug for splitting insn-*, will be revisited) Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 (tracker bug for parallelisation, interesting discussion) Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Bug: https://bugs.gentoo.org/891909 (not the same issue per-se but related to reduced resource usage) Bug: https://bugs.gentoo.org/894256 Bug: https://bugs.gentoo.org/901317 Signed-off-by: Sam James <sam@gentoo.org> ...l_match.pd-don-t-emit-label-if-not-needed.patch | 114 + ...move-commented-out-line-pragmas-unless-vv.patch | 41 + ...78_all_match.pd-CSE-the-dump-output-check.patch | 70 + ...lit-shared-code-to-gimple-match-exports.c.patch | 2560 ++++++++++++++++++++ ...pd-automatically-partition-match.cc-files.patch | 524 ++++ ...e-splits-in-makefile-and-make-configurabl.patch | 258 ++ 13.2.0/gentoo/README.history | 10 + 7 files changed, 3577 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa5725d7e4407bdfa4137cb0518c9d6ffaf5d8ae commit aa5725d7e4407bdfa4137cb0518c9d6ffaf5d8ae Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-26 02:40:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 02:40:51 +0000 sys-devel/gcc: backport split match.pd changes to 13.1.1_p20230520 See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927#c21. This should improve (reduce) the peak RAM usage when building GCC as it builds gimple-match in smaller chunks (previously was one huge generated file) as well as speeding up parallel build when used. i.e. This has benefits for both people building on constrained hardware (because -j1 is more effective and just means each smaller chunk is built one-at-a-time, not the massive blob) and also for people building with many jobs, as there's one less synchronisation point so the build is less serial. Motivated in particular by the upstream report (PR109927) of this being an issue on m68k with RAM usage for the single GCC process building gimple-match. (IIRC immolo and possibly dilfridge had mentioned similar issues when building some arches in qemu as well.) Note that upstream are planning on splitting insn-* as well so there are further improvements in the pipeline (see PR54179, but discussion has occurred far more recently on IRC about this and tamar is likely to look at it.). Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 (old bug for splitting insn-*, will be revisited) Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 (tracker bug for parallelisation, interesting discussion) Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Bug: https://bugs.gentoo.org/891909 (not the same issue per-se but related to reduced resource usage) Bug: https://bugs.gentoo.org/894256 Bug: https://bugs.gentoo.org/901317 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 2 +- sys-devel/gcc/gcc-13.1.1_p20230520.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The changes are too invasive to backport to 12, so please let me know if it happens with 13.
*** Bug 909524 has been marked as a duplicate of this bug. ***
https://bugs.gentoo.org/910194 passed stage3 so this seems to be resolved.
thanks
