Software > Applications and Porting
[DEV] applying patches to old version of gcc
TimKelly:
--- Quote from: cy384 on September 12, 2025, 11:08:26 am ---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
--- Quote ---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.
--- End quote ---
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.
--- Quote ---Please excuse me if this is a patronizing or X-Y problem response!
--- End quote ---
Not at all, I welcome the discussion.
--- End quote ---
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
--- Quote from: ClassicHasClass on September 11, 2025, 03:38:39 pm ---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?
--- End quote ---
Thanks again for the suggestion, ClassicHasClass!
tim
TimKelly:
--- Quote from: TimKelly on September 13, 2025, 04:16:38 pm ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version