[DEV] applying patches to old version of gcc

[TimKelly]

Hello,
I am currently trying to build the Self-Boot Engine component natively on a Raptor Blackbird, running Debian

 # uname -a
Linux 99-224-155-23 6.1.0-37-powerpc64le #1 SMP Debian 6.1.140-1 (2025-05-22) ppc64le GNU/Linux

It has gcc/g++ 12.2.  Unfortunately, the SBE code has code that violates C++17 standards, which were implemented with g++ 11.  I need to build gcc/g++ 10, which is not supported so there not a binary package available.  However, the source code is available at

https://sources.debian.org/src/gcc-10/10.2.1-6/debian

It does not compile

 build/genhooks -d \
       ../.././gcc/doc/tm.texi.in > tmp-tm.texi
 genhooks: No place specified to document hook TARGET_ASM_OPEN_PAREN

The solution to this appears to apply patches as noted at

https://lists.debian.org/debian-gcc/2011/10/msg00002.html

Patches to Debian for gcc are available at

https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches

The problem is I can not see a unified patch that applies all of them, nor can I figure out which ones I will specifically need, since many of them are architecture and language specific.  I applied one patch, bootstrap-no-unneeded-libs.diff, but it failed on one of the two files.  It may be due to necessary changes that other patches apply.

Does anyone have any advice?  I am not particularly versed with Linux or gcc (not my preferred development environment).

Thank you,
tim

[ClassicHasClass]

I don't know off the top of my head what you'd do with genhooks, but does passing -std=c11 (or c++11, as appropriate) to the compiler help with the other issues?

[TimKelly]

I have made a significant mis-statement.  I said the SBE code had the C++ that failed C++17.  This is not correct, and I apologize for the confusion.  It is ppe42-gcc that has the C++ code.  ppe42-gcc is the default compiler for the SBE.  The error

../.././gcc/reload1.c: In function ‘void init_reload()’:
../.././gcc/reload1.c:89:24: error: use of an operand of type ‘bool’ in ‘operator++’ is forbidden in C++17
   89 |   (this_target_reload->x_spill_indirect_levels)
      |   ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
../.././gcc/reload1.c:444:7: note: in expansion of macro ‘spill_indirect_levels’
  444 |       spill_indirect_levels++;
      |       ^~~~~~~~~~~~~~~~~~~~~

from the following compile

g++ -c   -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../.././gcc/reload1.c

Oddly, reload1.c is not a C++ file, but it is embedded in a long list of files compiled with g++.

Changing the instruction manually to

g++ -c   -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo -std=c++11 ../.././gcc/reload1.c

did actually compile.  Thanks!!!

I wish I could say

 $ CFLAGS='-std=c11' CXXFLAGS='-std=c++11' ./configure

(after make distclean) solves the problem, but CXXFLAGS is not being passed, even though it is in the Makefile:

 ./Makefile:337:CXXFLAGS_FOR_BUILD = -std=c++11

The command remains

g++ -c   -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../.././gcc/reload1.c

Otherwise this is an encouraging gain on the problem.  I had been attempting to solve the problem by recreating a QEMU VM closer to the original build, with Debian 10 and gcc 8.  I've gotten libmpc and libmpfr installed, but there is an error in the Makefile construction.

Thanks again!
tim

[TimKelly]

There appears to be a bug in the transfer of CXXFLAGS to the out-of-tree build Makefile.  The master Makefile at the root level of ppe42-gcc has

CFLAGS = -std=c11
LDFLAGS =
LIBCFLAGS = $(CFLAGS)
CXXFLAGS = -std=c++11
LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)

but the Makefile in ./host-powerpc64le-unknown-linux-gnu/gcc has

CFLAGS = -g
CXXFLAGS = -g
LDFLAGS = -static-libstdc++ -static-libgcc

It doesn't matter if I pass CXXFLAGS on the command line or export to a shell variable, or use CXXFLAGS_FOR_BUILD, the -std=c++11 never gets passed to the actual build Makefile.  If I manually add it to the build Makefile and compiling in the out-of-tree build directory, things build until the next failure, in a different part of the compilation.

[cy384]

It's unlikely anyone has tried to manually build this outside of the full openpower build environment in forever.  Grab the talos or blackbird openpower repository to see what it's doing (https://scm.raptorcs.com/scm/git/blackbird-op-build).  There are probably tons of extra build flags and maybe patches being applied, along with a version specific version of the compiler.  I'm not very familiar with buildroot but it seems like there's some stuff in openpower/package/ppc42-gcc

If you don't really absolutely need to build it in isolation from the rest of the system, I'd recommend sticking with the full build and modifying just the parts you care about inside of it.

Please excuse me if this is a patronizing or X-Y problem response!

[TimKelly]

It's unlikely anyone has tried to manually build this outside of the full openpower build environment in forever.  Grab the talos or blackbird openpower repository to see what it's doing (https://scm.raptorcs.com/scm/git/blackbird-op-build).  There are probably tons of extra build flags and maybe patches being applied, along with a version specific version of the compiler.  I'm not very familiar with buildroot but it seems like there's some stuff in openpower/package/ppc42-gcc
[\quote]

I downloaded the sources from

https://git.raptorcs.com/git/ppe42-gcc/
https://git.raptorcs.com/git/ppe42-binutils/

as I documented in

https://forums.raptorcs.com/index.php/topic,616.0.html 

If you don't really absolutely need to build it in isolation from the rest of the system, I'd recommend sticking with the full build and modifying just the parts you care about inside of it.

My precise effort is to remove SBE from being dependent on the buildroot environment, by starting with making the Makefiles strict POSIX 2024.  That would make the SBE portable to any platform with C and C++ compilers that meet appropriate standards.  Some of the GNU make extensions do not translate well and I am trying to reproduce what it should do.
 
As a corollary, there is an admirable effort by Raptor to ensure Raptor computers are 100% open source and controllable from every moment after the proprietary microcode that initializes the OCC.  I am trying to put that to the test.  If there are parts that can not be built without restricting the build environment, it's no different than RISC-V, which claims to be 100% open source but almost every vendor locks you into their tools and libraries.

Please excuse me if this is a patronizing or X-Y problem response!

Not at all, I welcome the discussion.

[TimKelly]

I tracked down the failure to pass CXXFLAGS from the command line to the Makefile to a bug in Makefile.in, in the STAGE_CFLAGS variable.  It overrides the command line variables, but is used to restore CXXFLAGS later.  It appears that because CXXFLAGS is not resolved until it is used, the original ones are lost - and even the CXXFLAGS set in the Makefile is lost!

I made nine changes (admittedly a brute force solution)

line 420:
STAGE_CFLAGS = $(BOOT_CFLAGS) -std=c11 -std=c++11

and at each STAGE*_CXXFLAG (eight of them) I added  -std=c++11 (STAGE1_CXXFLAGS was where the lack of resolution means CXXFLAGS goes missing).  It might seem like this was redundant, but it would not pass the -std  without it.

The compiling of ppe42-gcc with gcc 12 now proceeds until another error in a different part.  Although this is not the same as the original thread (trying to patch older gcc), this will work until it doesn't.

I will document the full steps once I figure them all out, but I also might ask questions in the "Cross-build compiler environment for SBE" thread I started at

https://forums.raptorcs.com/index.php/topic,616.0.html

I don't know off the top of my head what you'd do with genhooks, but does passing -std=c11 (or c++11, as appropriate) to the compiler help with the other issues?

Thanks again for the suggestion,  ClassicHasClass!

tim

[TimKelly]

The compiling of ppe42-gcc with gcc 12 now proceeds until another error in a different part.  Although this is not the same as the original thread (trying to patch older gcc), this will work until it doesn't.

And it doesn't.  After compiling gcc, the build attempts to use it to build libgcc.  The following is the error message from configure:

Checking multilib configuration for libgcc...
Configuring stage 1 in powerpc64le-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking build system type... powerpc64le-unknown-linux-gnu
checking host system type... powerpc64le-unknown-linux-gnu
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for powerpc64le-unknown-linux-gnu-ar... ar
checking for powerpc64le-unknown-linux-gnu-lipo... lipo
checking for powerpc64le-unknown-linux-gnu-nm... /root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/nm
checking for powerpc64le-unknown-linux-gnu-ranlib... ranlib
checking for powerpc64le-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for powerpc64le-unknown-linux-gnu-gcc... /root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/xgcc -B/root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem /usr/local/powerpc64le-unknown-linux-gnu/include -isystem /usr/local/powerpc64le-unknown-linux-gnu/sys-include   
checking for suffix of object files... configure: error: in `/root/raptor/ppe42-gcc/powerpc64le-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

I dug into the config.log and created a file with the test code, then ran it manually with -v

  /* confdefs.h */
  #define PACKAGE_NAME "GNU C Runtime Library"
  #define PACKAGE_TARNAME "libgcc"
  #define PACKAGE_VERSION "1.0"
  #define PACKAGE_STRING "GNU C Runtime Library 1.0"
  #define PACKAGE_BUGREPORT ""
  #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
  /* end confdefs.h.  */
 
  int
  main ()
  {
 
    ;
    return 0;
  }


...
GNU C (GCC) version 4.9.2 (powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version 4.2.0, MPC version 1.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 29fbe43bf124570f80365dc213e4e677
conftest.c:1:0: internal compiler error: in i, at ira.c:503
   /* confdefs.h */
 ^
unrecognized DWARF version in .debug_info at 6

conftest.c:1:0: internal compiler error: Segmentation fault
unrecognized DWARF version in .debug_info at 6
xgcc: internal compiler error: Segmentation fault (program cc1)
unrecognized DWARF version in .debug_info at 6
Segmentation fault

The code in question

      for (n = 0, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if (TEST_HARD_REG_BIT (temp_hard_regset, i))
          ira_non_ordered_class_hard_regs[cl][n++] = i;
      ira_assert (ira_class_hard_regs_num[cl] == n);

The assertion fails.  I dug into FIRST_PSEUDO_REGISTER and found in this particular build it comes from gcc/config/rs6000/rs6000.h

 933: #define FIRST_PSEUDO_REGISTER 149

Adding some debugging code to gcc/ira.c

      for (n = 0, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if (TEST_HARD_REG_BIT (temp_hard_regset, i)) {
fprintf(stdout, "i = %d, cl = %d, n = %d\n", i, cl, n);
          ira_non_ordered_class_hard_regs[cl][n++] = i;
         }
fprintf(stdout, "after cl = %d, ira_class_hard_regs_num[cl] = %d,  n = %d\n", cl, ira_class_hard_regs_num[cl], n);
      ira_assert (ira_class_hard_regs_num[cl] == n);
    }


results in
FIRST_PSEUDO_REGISTER = 149, LIM_REG_CLASSES = 23
before cl = 22, ira_class_hard_regs_num[cl] = 48,  n = 48
i = 0, cl = 22, n = 0
i = 3, cl = 22, n = 1
...
i = 72, cl = 22, n = 51
i = 74, cl = 22, n = 52
i = 75, cl = 22, n = 53
after cl = 22, ira_class_hard_regs_num[cl] = 48,  n = 54
host-powerpc64le-unknown-linux-gnu/gcc/conftest.c:1:0: internal compiler error: in setup_class_hard_regs, at ira.c:509
   /* confdefs.h */

What appears to have happened is that an earlier setting of ira_class_hard_regs_num has been altered and a check has failed. Not all registers have TEST_HARD_REG_BIT set so some are skipped, and it appears that some do have the bit skipped but this is unexpected.

From reading the documentation in ira.c, I strongly suspect I need to set some additional flags during the build process, but I can not find instructions on this.  Anyone have suggestions?

tim

[ClassicHasClass]

This seems like the kind of thing that would have been fixed in a later gcc (the -std= flag should still work there, the backwards compatibility is generally good). I don't think the ICE here would be fixed with a compiler flag; the failure seems too specific.

[TimKelly]

I don't think this the -std issue.  It is in the register allocator used for coloring.  From my perspective, since this came from the Raptor git repository, and the code is compiling with gcc 12, but failing in a hardware backend part, I am missing something that helps configure the register allocator.  I'm thinking it should work out of the box once the -std flag is set, but it doesn't.

[TimKelly]

I think I am abandoning the efforts to build the SBE within ppe42-gcc.  The configure and Makefile files do not honor flags passed to them, which is making isolating the build failure very difficult.  I haven't even gotten to trying to cross-compile with the ppc eabi.  In addition to the previously documented issue where gcc 12 is not properly protecting flags passed on the command line to the top level make,

  ./configure --enable-stage1-languages=c,c++ --enable-languages=c,c++

shows up as

 Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14+deb12u1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 ...

I am not sure what that means for my overall effort to port SBE to strict POSIX 2024 standards, but at this point, I am spending more time debugging what may be endless errors than actually moving forward elsewhere.  I have no interest in becoming an expert on configure nor gcc, just to figure out how something is supposed to work in the actual environment I will be using.

tim