Re: Building GCC 8 using 32-bit addressing on a 64-bit machine

Hello,

You are entirely correct.  My apologies for the oversight.  Details inline.

> On Apr 27, 2026, at 5:35=E2=80=AFAM, Segher Boessenkool <[email protected]=
shing.org> wrote:
>=20
> =EF=BB=BFOn Mon, Apr 27, 2026 at 04:32:18AM -0700, Gordon Steemson via Gcc=
-help wrote:
>> I had been encountering a strange problem when bootstrapping GCC 8 in 64-=
bit mode on my 20-year-old Power Mac G5, which seems to be due to an obscure=
 OS tooling bug and not easily addressed; so I decided to step back and buil=
d it for the 32-bit mode of that environment instead.  Alas, when I do, the s=
tage1 compiler chokes upon execution, because the stack frames generated by g=
cc/config/rs6000/rs6000.c do not match the hardcoded size expectations =E2=80=
=93 specifically, the four-register-sized allocation reserved for __builtin_=
eh_return()=E2=80=99s use takes twice as much space as the preset template e=
xpects, because UNITS_PER_WORD is eight rather than four on a PowerPC 970.  (=
I haven=E2=80=99t yet worked out how the same code somehow manages to build c=
orrectly when compiled in 64-bit mode ... it's not like any of that code is a=
djusted to suit the specs of the underlying machine.  I can=E2=80=99t locate=
 the definition of __builtin_eh_return(), either.)
>>=20
>> Does anyone have any insight into this?  If I could figure out where __bu=
iltin_eh_return() is defined, I could at least determine whether it=E2=80=99=
s safe to only allocate four octets per saved register (even if that would d=
o more to mask the problem than to actually _fix_ it).  If I just go by the r=
esults of grep=E2=80=99ing the source tree, __builtin_eh_return() doesn=E2=80=
=99t actually seem to EXIST.  The whole thing is very puzzling, especially s=
ince I have seen the project build correctly in the past when it was told to=
 expect a PowerPC 7400 as the default 32-bit target.
>>=20
>> I hypothesize that configuration does not work correctly when told to use=
 the 32-bit mode of a 64-bit processor as the default 32-bit target.  Is thi=
s a thing that can be tweaked, or have I encountered a hard limitation?
>=20
> You haven't said what you tried, only what you want the result to be.
> =46rom the few things you said you likely want --host=3Dpowerpc-linux ?

Not Linux, no.  I am running under Mac OS 10.5.8 (Darwin 9), though the setu=
p is intended to also work on other Mac OS versions from 10.4 onward.  (Back=
ground:  Around 2016, after Apple transitioned from PowerPC to Intel CPUs, a=
 fork of the Homebrew package manager [called Tigerbrew] was created to cont=
inue supporting PowerPC hardware.  I have been working on my own fork of tha=
t fork, with a different development focus; of particular relevance, I place=
 more emphasis on supporting 64-bit and universal [i.e., both 32- and 64-bit=
, and/or both PPC and Intel] builds.)

I am able to build a 64-bit native compiler, but for some obscure reason tha=
t appears to be the fault of the system linker, the native target libraries g=
et linked to the old libgcc_s in /usr/lib as well as the new one in the buil=
d tree, so function calls get dispatched to a version of that library that d=
oes not necessarily contain an implementation of them (some things were adde=
d to libgcc_s between releases 4.2 and 8 of GCC, but libgcc_s has always bee=
n versioned 1.0.0, regardless of changes made to it over time).

It is possible I could resolve this by bumping the library version number, b=
ut that would require making similar changes in all subsequent releases of G=
CC that I try to build, which sounds very troublesome to keep track of.  I a=
m instead going to build a tool for editing the Mach-O load commands, to rem=
ove the one that loads the obsolete version of the library.

In the meantime, I would like to build a version of the compiler that uses t=
he 32-bit system interfaces, just so I can get on with building other softwa=
re.  I know it works if you tell it to build as if running on a PPC7400; but=
 I have a PPC970, so ideally it would make use of that.  To restate my hesit=
ant question above:  Is there a way to properly configure for that, or will i=
t always try to use 64-bit addressing, regardless of settings, when told the=
re is a 64-bit-capable CPU?

Gordon S.