Building gcc 4.9.2 on AIX 7.1

Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

Hello GCC community.

I am looking for help building GCC 4.9.2 (also tried 4.9.4 and 5.4.0) on
IBM AIX Unix 7.1. Each attempt freezes during the run of build/genmddeps.
This appears to be related to two ld warnings:

ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
            The branch at address 0x3cc is not followed by a recognized
no-op
            or TOC-reload instruction. The unrecognized instruction is
0x7C691B78.

ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
            The branch at address 0x3cc is not followed by a recognized
no-op
            or TOC-reload instruction. The unrecognized instruction is
0x7C691B78.

The compile/link of genmddeps was this:

g++   -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 -DGENERATOR_FILE
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 -o
build/genmddeps \
    build/genmddeps.o build/read-md.o build/errors.o
../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a

OS version:

$ oslevel -s
7100-05-05-1939

Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Tom Kacvinsky]

> On Jun 11, 2023, at 08:26, Randy Galbraith via Gcc-help <gcc-help@gcc.gnu.org> wrote:
> 
> Hello GCC community.
> 
> I am looking for help building GCC 4.9.2 (also tried 4.9.4 and 5.4.0) on
> IBM AIX Unix 7.1. Each attempt freezes during the run of build/genmddeps.
> This appears to be related to two ld warnings:
> 
> ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
>            The branch at address 0x3cc is not followed by a recognized
> no-op
>            or TOC-reload instruction. The unrecognized instruction is
> 0x7C691B78.
> 
> ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
>            The branch at address 0x3cc is not followed by a recognized
> no-op
>            or TOC-reload instruction. The unrecognized instruction is
> 0x7C691B78.
> 
> The compile/link of genmddeps was this:
> 
> g++   -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 -DGENERATOR_FILE
> -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 -o
> build/genmddeps \
>    build/genmddeps.o build/read-md.o build/errors.o
> ../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a
> 
> OS version:
> 
> 

Those aren't binutils linker warnings.  Those are coming from the system linker.  Which probably means you are using the system assembler, too.  Or maybe even the odd case where you're using binutils for the assembler but the system linker.

Can you try with using binutils for the assembler and linker?  I am assuming you either have an older version of GCC for building the newer version of it, or perhaps you have the Sun Pro compilers.  In any case, you could use whichever bootstrap compiler you have to build binutils, and then put they binutils in PATH.  The GCC configure script should then chose those for building.

Re: Building gcc 4.9.2 on AIX 7.1

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

HI,

For some reason my follow-up hasn't made it through.

On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@gmail.com> wrote:

<snip>


> Those aren't binutils linker warnings.  Those are coming from the system
> linker.  Which probably means you are using the system assembler, too.  Or
> maybe even the odd case where you're using binutils for the assembler but
> the system linker.
>
> Can you try with using binutils for the assembler and linker?  I am
> assuming you either have an older version of GCC for building the newer
> version of it, or perhaps you have the Sun Pro compilers.  In any case, you
> could use whichever bootstrap compiler you have to build binutils, and then
> put they binutils in PATH.  The GCC configure script should then chose
> those for building.


I missed that you're on AIX.  So either you're using an older version of
GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap.

Here is a thought I had up re-thinking this.  This might be an
architecture problem.  Which version of the POWER chips are you using?
YOu might have to force the GCC configuration process to use -march to
specify the right processor.  But as far as I know, the configure script
should be smart enough to figure that out.

It's been about ten years since I used the xlc/xlC compilers, so I am
not sure how one would select the architecture they want.

Re: Building gcc 4.9.2 on AIX 7.1

[Kai Ruottu]

Randy Galbraith via Gcc-help kirjoitti 11.6.2023 klo 15.26:
> Hello GCC community.
>
> I am looking for help building GCC 4.9.2 (also tried 4.9.4 and 5.4.0) on
> IBM AIX Unix 7.1. Each attempt freezes during the run of build/genmddeps.
> This appears to be related to two ld warnings:
>
> ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
>              The branch at address 0x3cc is not followed by a recognized
> no-op
>              or TOC-reload instruction. The unrecognized instruction is
> 0x7C691B78.
>
> ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function .ferror:
>              The branch at address 0x3cc is not followed by a recognized
> no-op
>              or TOC-reload instruction. The unrecognized instruction is
> 0x7C691B78.
>
> The compile/link of genmddeps was this:
>
> g++   -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 -DGENERATOR_FILE
> -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 -o
> build/genmddeps \
>      build/genmddeps.o build/read-md.o build/errors.o
> ../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a
So you have the link command via the g++ compiler driver here...
If you add the '-v' option into it you and others will see which linker 
was used.
So please try this command in the build directory :

g++ -v -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 -DGENERATOR_FILE \
-static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 \
-o build/genmddeps \
build/genmddeps.o build/read-md.o build/errors.o \
../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a

Is the 'ld' one from the GNU binutils possible nowadays? Maybe it works...

If the GNU binutils could be used then also cross-compiling things for 
IBM AIX Unix 7.1
could be tried - others could try get the same $target compiler for 
their Linux etc hosts.
These "gen*" things will be built for the $build system and be run in it 
to generate stuff
to be compiled for the $host system. They may succeed on a cross host 
but not on the
native IBM AIX host.

But I remember also getting the "proprietary" standard C library for IBM 
AIX being a problem.
It being copyrighted and not being available for others, only for those 
who own the IBM AIX
target system.

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]

On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help <
gcc-help@gcc.gnu.org> wrote:

> HI,
>
> For some reason my follow-up hasn't made it through.
>
> On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@gmail.com> wrote:
>
> <snip>
>
>
> > Those aren't binutils linker warnings.  Those are coming from the system
> > linker.  Which probably means you are using the system assembler, too.
> Or
> > maybe even the odd case where you're using binutils for the assembler but
> > the system linker.
> >
> > Can you try with using binutils for the assembler and linker?  I am
> > assuming you either have an older version of GCC for building the newer
> > version of it, or perhaps you have the Sun Pro compilers.  In any case,
> you
> > could use whichever bootstrap compiler you have to build binutils, and
> then
> > put they binutils in PATH.  The GCC configure script should then chose
> > those for building.
>
>
> I missed that you're on AIX.  So either you're using an older version of
> GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap.
>
> Here is a thought I had up re-thinking this.  This might be an
> architecture problem.  Which version of the POWER chips are you using?
> YOu might have to force the GCC configuration process to use -march to
> specify the right processor.  But as far as I know, the configure script
> should be smart enough to figure that out.
>
> It's been about ten years since I used the xlc/xlC compilers, so I am
> not sure how one would select the architecture they want.
>

Hi Tom.

Our sys-admin team is upgrading AIX 7.1 to 7.2. This broke gcc (an issue
with IBM delivering non-ansi-standard header files). So my first step is an
attempt to bootstrap gcc 4.9.2 (or later) on a non-upgraded (7.1) system.
This would be using our existing install of gcc.

$ gcc --version
gcc (GCC) 4.9.2

Here are the CPU details:

$ prtconf
System Model: IBM,9040-MR9
Machine Serial Number: XXXXXXX
Processor Type: PowerPC_POWER9
Processor Implementation Mode: POWER 8
Processor Version: PV_8_Compat
Number Of Processors: 4
Processor Clock Speed: 2850 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 12 XXXXXXXX
Memory Size: 31744 MB
Good Memory Size: 31744 MB
Platform Firmware level: VM930_145
Firmware Version: IBM,FW930.50 (VM930_145)
Console Login: enable
Auto Restart: true
Full Core: false
NX Crypto Acceleration: Capable and Enabled
<snip>

Details on "ld" and "as" as per configure:

$ ./configure
checking build system type... powerpc-ibm-aix7.1.0.0
<snip>
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
<snip>
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
<snip>
checking for as... as
checking for dlltool... no
checking for ld... ld
<snip>
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
<snip>
checking for as... no
checking for as... as
<snip>
checking for ld... no
checking for ld... ld
<snip>
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... host tool
checking where to find the target gcc... just compiled
checking where to find the target gcj... just compiled
<snip>
checking where to find the target ld... host tool
<snip>

And "ld" and "as" I see at the command line:

$ which ld
/usr/bin/ld

$ file /usr/bin/ld
/usr/bin/ld: symbolic link to /usr/ccs/bin/ld

$ file /usr/ccs/bin/ld
/usr/ccs/bin/ld: executable (RISC System/6000 V3.1) or obj module

$ which as
/usr/bin/as

$ file /usr/bin/as
/usr/bin/as: symbolic link to /usr/ccs/bin/as

$ file /usr/ccs/bin/as
/usr/ccs/bin/as: executable (RISC System/6000 V3.1) or obj module

Because gcc 4.9.2 is broken on our AIX 7.2 I am interested (though not as a
first step) in how to boostrap gcc using native C (xlc) compiler. Alas, I
am still in the process of learning what options can be sent to configure
to direct it to use xlc.

I just saw Kai's -v suggestion. I'll try that and reply with the details.

Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

On Sun, 11 Jun 2023, 22:05 Randy Galbraith via Gcc-help, <
gcc-help@gcc.gnu.org> wrote:

> On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help <
> gcc-help@gcc.gnu.org> wrote:
>
> > HI,
> >
> > For some reason my follow-up hasn't made it through.
> >
> > On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@gmail.com>
> wrote:
> >
> > <snip>
> >
> >
> > > Those aren't binutils linker warnings.  Those are coming from the
> system
> > > linker.  Which probably means you are using the system assembler, too.
> > Or
> > > maybe even the odd case where you're using binutils for the assembler
> but
> > > the system linker.
> > >
> > > Can you try with using binutils for the assembler and linker?  I am
> > > assuming you either have an older version of GCC for building the newer
> > > version of it, or perhaps you have the Sun Pro compilers.  In any case,
> > you
> > > could use whichever bootstrap compiler you have to build binutils, and
> > then
> > > put they binutils in PATH.  The GCC configure script should then chose
> > > those for building.
> >
> >
> > I missed that you're on AIX.  So either you're using an older version of
> > GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap.
> >
> > Here is a thought I had up re-thinking this.  This might be an
> > architecture problem.  Which version of the POWER chips are you using?
> > YOu might have to force the GCC configuration process to use -march to
> > specify the right processor.  But as far as I know, the configure script
> > should be smart enough to figure that out.
> >
> > It's been about ten years since I used the xlc/xlC compilers, so I am
> > not sure how one would select the architecture they want.
> >
>
> Hi Tom.
>
> Our sys-admin team is upgrading AIX 7.1 to 7.2. This broke gcc (an issue
> with IBM delivering non-ansi-standard header files). So my first step is an
> attempt to bootstrap gcc 4.9.2 (or later) on a non-upgraded (7.1) system.
> This would be using our existing install of gcc.
>
> $ gcc --version
> gcc (GCC) 4.9.2
>
> Here are the CPU details:
>
> $ prtconf
> System Model: IBM,9040-MR9
> Machine Serial Number: XXXXXXX
> Processor Type: PowerPC_POWER9
> Processor Implementation Mode: POWER 8
> Processor Version: PV_8_Compat
> Number Of Processors: 4
> Processor Clock Speed: 2850 MHz
> CPU Type: 64-bit
> Kernel Type: 64-bit
> LPAR Info: 12 XXXXXXXX
> Memory Size: 31744 MB
> Good Memory Size: 31744 MB
> Platform Firmware level: VM930_145
> Firmware Version: IBM,FW930.50 (VM930_145)
> Console Login: enable
> Auto Restart: true
> Full Core: false
> NX Crypto Acceleration: Capable and Enabled
> <snip>
>
> Details on "ld" and "as" as per configure:
>
> $ ./configure
> checking build system type... powerpc-ibm-aix7.1.0.0
> <snip>
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> <snip>
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> <snip>
> checking for as... as
> checking for dlltool... no
> checking for ld... ld
> <snip>
> checking for cc... cc
> checking for c++... c++
> checking for gcc... gcc
> <snip>
> checking for as... no
> checking for as... as
> <snip>
> checking for ld... no
> checking for ld... ld
> <snip>
> checking where to find the target ar... host tool
> checking where to find the target as... host tool
> checking where to find the target cc... just compiled
> checking where to find the target c++... just compiled
> checking where to find the target c++ for libstdc++... just compiled
> checking where to find the target dlltool... host tool
> checking where to find the target gcc... just compiled
> checking where to find the target gcj... just compiled
> <snip>
> checking where to find the target ld... host tool
> <snip>
>
> And "ld" and "as" I see at the command line:
>
> $ which ld
> /usr/bin/ld
>
> $ file /usr/bin/ld
> /usr/bin/ld: symbolic link to /usr/ccs/bin/ld
>
> $ file /usr/ccs/bin/ld
> /usr/ccs/bin/ld: executable (RISC System/6000 V3.1) or obj module
>
> $ which as
> /usr/bin/as
>
> $ file /usr/bin/as
> /usr/bin/as: symbolic link to /usr/ccs/bin/as
>
> $ file /usr/ccs/bin/as
> /usr/ccs/bin/as: executable (RISC System/6000 V3.1) or obj module
>
> Because gcc 4.9.2 is broken on our AIX 7.2 I am interested (though not as a
> first step) in how to boostrap gcc using native C (xlc) compiler. Alas, I
> am still in the process of learning what options can be sent to configure
> to direct it to use xlc.
>

Bootstrapping gcc 13 works on AIX, is there a reason you have to use an
ancient gcc?



> I just saw Kai's -v suggestion. I'll try that and reply with the details.
>
> Cheers, -Randy
>

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

On Sun, Jun 11, 2023 at 2:31 PM Kai Ruottu <kai.ruottu@wippies.com> wrote:

> Randy Galbraith via Gcc-help kirjoitti 11.6.2023 klo 15.26:
> > Hello GCC community.
> >
> > I am looking for help building GCC 4.9.2 (also tried 4.9.4 and 5.4.0) on
> > IBM AIX Unix 7.1. Each attempt freezes during the run of build/genmddeps.
> > This appears to be related to two ld warnings:
> >
> > ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function
> .ferror:
> >              The branch at address 0x3cc is not followed by a recognized
> > no-op
> >              or TOC-reload instruction. The unrecognized instruction is
> > 0x7C691B78.
> >
> > ld: 0711-768 WARNING: Object build/genmddeps.o, section 1, function
> .ferror:
> >              The branch at address 0x3cc is not followed by a recognized
> > no-op
> >              or TOC-reload instruction. The unrecognized instruction is
> > 0x7C691B78.
> >
> > The compile/link of genmddeps was this:
> >
> > g++   -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 -DGENERATOR_FILE
> > -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 -o
> > build/genmddeps \
> >      build/genmddeps.o build/read-md.o build/errors.o
> > ../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a
> So you have the link command via the g++ compiler driver here...
> If you add the '-v' option into it you and others will see which linker
> was used.
> So please try this command in the build directory :
>
> g++ -v -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 -DGENERATOR_FILE \
> -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x40000000 \
> -o build/genmddeps \
> build/genmddeps.o build/read-md.o build/errors.o \
> ../../build-powerpc-ibm-aix7.1.0.0/libiberty/libiberty.a
>
> Is the 'ld' one from the GNU binutils possible nowadays? Maybe it works...
>
> If the GNU binutils could be used then also cross-compiling things for
> IBM AIX Unix 7.1
> could be tried - others could try get the same $target compiler for
> their Linux etc hosts.
> These "gen*" things will be built for the $build system and be run in it
> to generate stuff
> to be compiled for the $host system. They may succeed on a cross host
> but not on the
> native IBM AIX host.
>
> But I remember also getting the "proprietary" standard C library for IBM
> AIX being a problem.
> It being copyrighted and not being available for others, only for those
> who own the IBM AIX
> target system.
>

Hi Kai. When I add -v to g++ I see it runs collect2. When I capture the
collect2 command and add -v to it, I can see it runs /usr/bin/ld. So IBM's
"ld" is being called. Thanks for that suggestion nonetheless since it
reveals lots of details. Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 5710 bytes --]

On Sun, Jun 11, 2023, 5:05 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

>
>
> On Sun, 11 Jun 2023, 22:05 Randy Galbraith via Gcc-help, <
> gcc-help@gcc.gnu.org> wrote:
>
>> On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help <
>> gcc-help@gcc.gnu.org> wrote:
>>
>> > HI,
>> >
>> > For some reason my follow-up hasn't made it through.
>> >
>> > On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@gmail.com>
>> wrote:
>> >
>> > <snip>
>> >
>> >
>> > > Those aren't binutils linker warnings.  Those are coming from the
>> system
>> > > linker.  Which probably means you are using the system assembler, too.
>> > Or
>> > > maybe even the odd case where you're using binutils for the assembler
>> but
>> > > the system linker.
>> > >
>> > > Can you try with using binutils for the assembler and linker?  I am
>> > > assuming you either have an older version of GCC for building the
>> newer
>> > > version of it, or perhaps you have the Sun Pro compilers.  In any
>> case,
>> > you
>> > > could use whichever bootstrap compiler you have to build binutils, and
>> > then
>> > > put they binutils in PATH.  The GCC configure script should then chose
>> > > those for building.
>> >
>> >
>> > I missed that you're on AIX.  So either you're using an older version of
>> > GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap.
>> >
>> > Here is a thought I had up re-thinking this.  This might be an
>> > architecture problem.  Which version of the POWER chips are you using?
>> > YOu might have to force the GCC configuration process to use -march to
>> > specify the right processor.  But as far as I know, the configure script
>> > should be smart enough to figure that out.
>> >
>> > It's been about ten years since I used the xlc/xlC compilers, so I am
>> > not sure how one would select the architecture they want.
>> >
>>
>> Hi Tom.
>>
>> Our sys-admin team is upgrading AIX 7.1 to 7.2. This broke gcc (an issue
>> with IBM delivering non-ansi-standard header files). So my first step is
>> an
>> attempt to bootstrap gcc 4.9.2 (or later) on a non-upgraded (7.1) system.
>> This would be using our existing install of gcc.
>>
>> $ gcc --version
>> gcc (GCC) 4.9.2
>>
>> Here are the CPU details:
>>
>> $ prtconf
>> System Model: IBM,9040-MR9
>> Machine Serial Number: XXXXXXX
>> Processor Type: PowerPC_POWER9
>> Processor Implementation Mode: POWER 8
>> Processor Version: PV_8_Compat
>> Number Of Processors: 4
>> Processor Clock Speed: 2850 MHz
>> CPU Type: 64-bit
>> Kernel Type: 64-bit
>> LPAR Info: 12 XXXXXXXX
>> Memory Size: 31744 MB
>> Good Memory Size: 31744 MB
>> Platform Firmware level: VM930_145
>> Firmware Version: IBM,FW930.50 (VM930_145)
>> Console Login: enable
>> Auto Restart: true
>> Full Core: false
>> NX Crypto Acceleration: Capable and Enabled
>> <snip>
>>
>> Details on "ld" and "as" as per configure:
>>
>> $ ./configure
>> checking build system type... powerpc-ibm-aix7.1.0.0
>> <snip>
>> checking for gcc... gcc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> <snip>
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking for g++... g++
>> checking whether we are using the GNU C++ compiler... yes
>> <snip>
>> checking for as... as
>> checking for dlltool... no
>> checking for ld... ld
>> <snip>
>> checking for cc... cc
>> checking for c++... c++
>> checking for gcc... gcc
>> <snip>
>> checking for as... no
>> checking for as... as
>> <snip>
>> checking for ld... no
>> checking for ld... ld
>> <snip>
>> checking where to find the target ar... host tool
>> checking where to find the target as... host tool
>> checking where to find the target cc... just compiled
>> checking where to find the target c++... just compiled
>> checking where to find the target c++ for libstdc++... just compiled
>> checking where to find the target dlltool... host tool
>> checking where to find the target gcc... just compiled
>> checking where to find the target gcj... just compiled
>> <snip>
>> checking where to find the target ld... host tool
>> <snip>
>>
>> And "ld" and "as" I see at the command line:
>>
>> $ which ld
>> /usr/bin/ld
>>
>> $ file /usr/bin/ld
>> /usr/bin/ld: symbolic link to /usr/ccs/bin/ld
>>
>> $ file /usr/ccs/bin/ld
>> /usr/ccs/bin/ld: executable (RISC System/6000 V3.1) or obj module
>>
>> $ which as
>> /usr/bin/as
>>
>> $ file /usr/bin/as
>> /usr/bin/as: symbolic link to /usr/ccs/bin/as
>>
>> $ file /usr/ccs/bin/as
>> /usr/ccs/bin/as: executable (RISC System/6000 V3.1) or obj module
>>
>> Because gcc 4.9.2 is broken on our AIX 7.2 I am interested (though not as
>> a
>> first step) in how to boostrap gcc using native C (xlc) compiler. Alas, I
>> am still in the process of learning what options can be sent to configure
>> to direct it to use xlc.
>>
>
> Bootstrapping gcc 13 works on AIX, is there a reason you have to use an
> ancient gcc?
>
>
>
>> I just saw Kai's -v suggestion. I'll try that and reply with the details.
>>
>> Cheers, -Randy
>>
>
We have a need to match gcc version on Red Hat GNU/Linux 7. I am looking
forward to newer GCC once Red Hat is upgraded. However, that will likely
break our build. We elevate every warning in gcc to error status that stops
the building. Thus we need to plan for that. At the moment I just need to
support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been
completed this would not be an issue. Cheers, -Randy

>

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 6412 bytes --]

On Sun, Jun 11, 2023 at 6:37 PM Randy Galbraith <randy.galbraith@gmail.com>
wrote:

>
>
> On Sun, Jun 11, 2023, 5:05 PM Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 11 Jun 2023, 22:05 Randy Galbraith via Gcc-help, <
>> gcc-help@gcc.gnu.org> wrote:
>>
>>> On Sun, Jun 11, 2023 at 12:27 PM Tom Kacvinsky via Gcc-help <
>>> gcc-help@gcc.gnu.org> wrote:
>>>
>>> > HI,
>>> >
>>> > For some reason my follow-up hasn't made it through.
>>> >
>>> > On Sun, Jun 11, 2023 at 11:27 AM Tom Kacvinsky <tkacvins@gmail.com>
>>> wrote:
>>> >
>>> > <snip>
>>> >
>>> >
>>> > > Those aren't binutils linker warnings.  Those are coming from the
>>> system
>>> > > linker.  Which probably means you are using the system assembler,
>>> too.
>>> > Or
>>> > > maybe even the odd case where you're using binutils for the
>>> assembler but
>>> > > the system linker.
>>> > >
>>> > > Can you try with using binutils for the assembler and linker?  I am
>>> > > assuming you either have an older version of GCC for building the
>>> newer
>>> > > version of it, or perhaps you have the Sun Pro compilers.  In any
>>> case,
>>> > you
>>> > > could use whichever bootstrap compiler you have to build binutils,
>>> and
>>> > then
>>> > > put they binutils in PATH.  The GCC configure script should then
>>> chose
>>> > > those for building.
>>> >
>>> >
>>> > I missed that you're on AIX.  So either you're using an older version
>>> of
>>> > GCC to bootstrap, or IBM's xlc/xlC compilers to bootstrap.
>>> >
>>> > Here is a thought I had up re-thinking this.  This might be an
>>> > architecture problem.  Which version of the POWER chips are you using?
>>> > YOu might have to force the GCC configuration process to use -march to
>>> > specify the right processor.  But as far as I know, the configure
>>> script
>>> > should be smart enough to figure that out.
>>> >
>>> > It's been about ten years since I used the xlc/xlC compilers, so I am
>>> > not sure how one would select the architecture they want.
>>> >
>>>
>>> Hi Tom.
>>>
>>> Our sys-admin team is upgrading AIX 7.1 to 7.2. This broke gcc (an issue
>>> with IBM delivering non-ansi-standard header files). So my first step is
>>> an
>>> attempt to bootstrap gcc 4.9.2 (or later) on a non-upgraded (7.1) system.
>>> This would be using our existing install of gcc.
>>>
>>> $ gcc --version
>>> gcc (GCC) 4.9.2
>>>
>>> Here are the CPU details:
>>>
>>> $ prtconf
>>> System Model: IBM,9040-MR9
>>> Machine Serial Number: XXXXXXX
>>> Processor Type: PowerPC_POWER9
>>> Processor Implementation Mode: POWER 8
>>> Processor Version: PV_8_Compat
>>> Number Of Processors: 4
>>> Processor Clock Speed: 2850 MHz
>>> CPU Type: 64-bit
>>> Kernel Type: 64-bit
>>> LPAR Info: 12 XXXXXXXX
>>> Memory Size: 31744 MB
>>> Good Memory Size: 31744 MB
>>> Platform Firmware level: VM930_145
>>> Firmware Version: IBM,FW930.50 (VM930_145)
>>> Console Login: enable
>>> Auto Restart: true
>>> Full Core: false
>>> NX Crypto Acceleration: Capable and Enabled
>>> <snip>
>>>
>>> Details on "ld" and "as" as per configure:
>>>
>>> $ ./configure
>>> checking build system type... powerpc-ibm-aix7.1.0.0
>>> <snip>
>>> checking for gcc... gcc
>>> checking for C compiler default output file name... a.out
>>> checking whether the C compiler works... yes
>>> <snip>
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether gcc accepts -g... yes
>>> checking for gcc option to accept ISO C89... none needed
>>> checking for g++... g++
>>> checking whether we are using the GNU C++ compiler... yes
>>> <snip>
>>> checking for as... as
>>> checking for dlltool... no
>>> checking for ld... ld
>>> <snip>
>>> checking for cc... cc
>>> checking for c++... c++
>>> checking for gcc... gcc
>>> <snip>
>>> checking for as... no
>>> checking for as... as
>>> <snip>
>>> checking for ld... no
>>> checking for ld... ld
>>> <snip>
>>> checking where to find the target ar... host tool
>>> checking where to find the target as... host tool
>>> checking where to find the target cc... just compiled
>>> checking where to find the target c++... just compiled
>>> checking where to find the target c++ for libstdc++... just compiled
>>> checking where to find the target dlltool... host tool
>>> checking where to find the target gcc... just compiled
>>> checking where to find the target gcj... just compiled
>>> <snip>
>>> checking where to find the target ld... host tool
>>> <snip>
>>>
>>> And "ld" and "as" I see at the command line:
>>>
>>> $ which ld
>>> /usr/bin/ld
>>>
>>> $ file /usr/bin/ld
>>> /usr/bin/ld: symbolic link to /usr/ccs/bin/ld
>>>
>>> $ file /usr/ccs/bin/ld
>>> /usr/ccs/bin/ld: executable (RISC System/6000 V3.1) or obj module
>>>
>>> $ which as
>>> /usr/bin/as
>>>
>>> $ file /usr/bin/as
>>> /usr/bin/as: symbolic link to /usr/ccs/bin/as
>>>
>>> $ file /usr/ccs/bin/as
>>> /usr/ccs/bin/as: executable (RISC System/6000 V3.1) or obj module
>>>
>>> Because gcc 4.9.2 is broken on our AIX 7.2 I am interested (though not
>>> as a
>>> first step) in how to boostrap gcc using native C (xlc) compiler. Alas, I
>>> am still in the process of learning what options can be sent to configure
>>> to direct it to use xlc.
>>>
>>
>> Bootstrapping gcc 13 works on AIX, is there a reason you have to use an
>> ancient gcc?
>>
>>
>>
>>> I just saw Kai's -v suggestion. I'll try that and reply with the details.
>>>
>>> Cheers, -Randy
>>>
>>
> We have a need to match gcc version on Red Hat GNU/Linux 7. I am looking
> forward to newer GCC once Red Hat is upgraded. However, that will likely
> break our build. We elevate every warning in gcc to error status that stops
> the building. Thus we need to plan for that. At the moment I just need to
> support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been
> completed this would not be an issue. Cheers, -Randy
>

Hi Jonathan. Even though using GCC 13 may not work for us, I decided to
test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1):

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

Alas it seems to run into the same issue wherein ./conftest runs forever
(>1hr, 40min, with 32:22 of cpu time). I'm now going to try export CC=xlc
and see if I can get gcc 5.4.0 to build. Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Christer Solskogen]

On 12.06.2023 17:54, Randy Galbraith via Gcc-help wrote:

> Hi Jonathan. Even though using GCC 13 may not work for us, I decided to
> test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1):
> 
> ./configure --enable-languages=c,c++
> make
> 
> Alas it seems to run into the same issue wherein ./conftest runs forever
> (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export CC=xlc
> and see if I can get gcc 5.4.0 to build. Cheers, -Randy
> 

Don't build gcc from the source directory. This is not supported.
https://gcc.gnu.org/wiki/InstallingGCC

-- 
chs

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Tue, Jun 13, 2023 at 3:43 AM Christer Solskogen via Gcc-help <
gcc-help@gcc.gnu.org> wrote:

> On 12.06.2023 17:54, Randy Galbraith via Gcc-help wrote:
>
> > Hi Jonathan. Even though using GCC 13 may not work for us, I decided to
> > test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1):
> >
> > ./configure --enable-languages=c,c++
> > make
> >
> > Alas it seems to run into the same issue wherein ./conftest runs forever
> > (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export CC=xlc
> > and see if I can get gcc 5.4.0 to build. Cheers, -Randy
> >
>
> Don't build gcc from the source directory. This is not supported.
> https://gcc.gnu.org/wiki/InstallingGCC
>
> --
> chs
>
> Interesting! I watched a Youtube video wherein an individual built GCC
(14.0 actually) from git repo. He stepped outside the source directory, but
I assumed he was just wanting to avoid building right where .git exists.
I'm being tripped up by the learned habit of ./configure && make used by
many packages. Thanks for the wiki link. Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On Tue, Jun 13, 2023 at 6:35 AM Randy Galbraith <randy.galbraith@gmail.com>
wrote:

>
>
> On Tue, Jun 13, 2023 at 3:43 AM Christer Solskogen via Gcc-help <
> gcc-help@gcc.gnu.org> wrote:
>
>> On 12.06.2023 17:54, Randy Galbraith via Gcc-help wrote:
>>
>> > Hi Jonathan. Even though using GCC 13 may not work for us, I decided to
>> > test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1):
>> >
>> > ./configure --enable-languages=c,c++
>> > make
>> >
>> > Alas it seems to run into the same issue wherein ./conftest runs forever
>> > (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export
>> CC=xlc
>> > and see if I can get gcc 5.4.0 to build. Cheers, -Randy
>> >
>>
>> Don't build gcc from the source directory. This is not supported.
>> https://gcc.gnu.org/wiki/InstallingGCC
>>
>> --
>> chs
>>
>> Interesting! I watched a Youtube video wherein an individual built GCC
> (14.0 actually) from git repo. He stepped outside the source directory, but
> I assumed he was just wanting to avoid building right where .git exists.
> I'm being tripped up by the learned habit of ./configure && make used by
> many packages. Thanks for the wiki link. Cheers, -Randy
>

Quick reply to drop off this note. Running make outside the gcc source
directory (objdir, as per following the wiki) did not help here.
Nonetheless the step: ./contrib/download_prerequisites did show what GCC
5.4.0 wants in terms of gmp, mpfr, mpc and isl). I'm now going to run some
of the build steps we use to compile our own software. That may reveal ld
(or CFLAGS) options that are needed to make g++ and ld agree upon object
code. Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Jonathan Wakely]

On Thu, 15 Jun 2023 at 17:45, Randy Galbraith via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> On Tue, Jun 13, 2023 at 6:35 AM Randy Galbraith <randy.galbraith@gmail.com>
> wrote:
>
> >
> >
> > On Tue, Jun 13, 2023 at 3:43 AM Christer Solskogen via Gcc-help <
> > gcc-help@gcc.gnu.org> wrote:
> >
> >> On 12.06.2023 17:54, Randy Galbraith via Gcc-help wrote:
> >>
> >> > Hi Jonathan. Even though using GCC 13 may not work for us, I decided to
> >> > test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and mpc-1.3.1):
> >> >
> >> > ./configure --enable-languages=c,c++
> >> > make
> >> >
> >> > Alas it seems to run into the same issue wherein ./conftest runs forever
> >> > (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export
> >> CC=xlc
> >> > and see if I can get gcc 5.4.0 to build. Cheers, -Randy
> >> >
> >>
> >> Don't build gcc from the source directory. This is not supported.
> >> https://gcc.gnu.org/wiki/InstallingGCC
> >>
> >> --
> >> chs
> >>
> >> Interesting! I watched a Youtube video wherein an individual built GCC
> > (14.0 actually) from git repo. He stepped outside the source directory, but
> > I assumed he was just wanting to avoid building right where .git exists.
> > I'm being tripped up by the learned habit of ./configure && make used by
> > many packages. Thanks for the wiki link. Cheers, -Randy
> >
>
> Quick reply to drop off this note. Running make outside the gcc source
> directory (objdir, as per following the wiki) did not help here.
> Nonetheless the step: ./contrib/download_prerequisites did show what GCC
> 5.4.0 wants in terms of gmp, mpfr, mpc and isl). I'm now going to run some
> of the build steps we use to compile our own software. That may reveal ld
> (or CFLAGS) options that are needed to make g++ and ld agree upon object
> code. Cheers, -Randy

Did you try running the mkheaders script for the existing gcc installation?

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

On Thu, Jun 15, 2023 at 6:06 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Thu, 15 Jun 2023 at 17:45, Randy Galbraith via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > On Tue, Jun 13, 2023 at 6:35 AM Randy Galbraith <
> randy.galbraith@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Tue, Jun 13, 2023 at 3:43 AM Christer Solskogen via Gcc-help <
> > > gcc-help@gcc.gnu.org> wrote:
> > >
> > >> On 12.06.2023 17:54, Randy Galbraith via Gcc-help wrote:
> > >>
> > >> > Hi Jonathan. Even though using GCC 13 may not work for us, I
> decided to
> > >> > test the build of gcc-13.1.0 (with gmp-6.2.1, mpfr-4.2.0 and
> mpc-1.3.1):
> > >> >
> > >> > ./configure --enable-languages=c,c++
> > >> > make
> > >> >
> > >> > Alas it seems to run into the same issue wherein ./conftest runs
> forever
> > >> > (>1hr, 40min, with 32:22 of cpu time). I'm now going to try export
> > >> CC=xlc
> > >> > and see if I can get gcc 5.4.0 to build. Cheers, -Randy
> > >> >
> > >>
> > >> Don't build gcc from the source directory. This is not supported.
> > >> https://gcc.gnu.org/wiki/InstallingGCC
> > >>
> > >> --
> > >> chs
> > >>
> > >> Interesting! I watched a Youtube video wherein an individual built GCC
> > > (14.0 actually) from git repo. He stepped outside the source
> directory, but
> > > I assumed he was just wanting to avoid building right where .git
> exists.
> > > I'm being tripped up by the learned habit of ./configure && make used
> by
> > > many packages. Thanks for the wiki link. Cheers, -Randy
> > >
> >
> > Quick reply to drop off this note. Running make outside the gcc source
> > directory (objdir, as per following the wiki) did not help here.
> > Nonetheless the step: ./contrib/download_prerequisites did show what GCC
> > 5.4.0 wants in terms of gmp, mpfr, mpc and isl). I'm now going to run
> some
> > of the build steps we use to compile our own software. That may reveal ld
> > (or CFLAGS) options that are needed to make g++ and ld agree upon object
> > code. Cheers, -Randy
>
> Did you try running the mkheaders script for the existing gcc installation?
>

Running mkheaders does indeed seem to bring GCC 4.9.2 back to life on AIX
7.2:

$
/xxx/xxxx/gcc-4.9.2/powerpc-AIX7.1/libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.2/install-tools/mkheaders
Cannot access arm.h from /usr/include
        error 2 (No such file or directory)
Cannot access swclock.h from /usr/include
        error 2 (No such file or directory)

The post 7.2 gcc break was this:

/usr/include/sys/time.h:110:16: error: redefinition of 'struct sigset_t'

Once I run mkheaders the include-fixed directory has a fresh set of .h
files. The sigset error no longer appears.

Most of the mkheaders changes seem to be picking up changes made by IBM.
For example, assert.h has new comments:

-/* bos71L src/bos/usr/include/assert.h 1.17.1.3
*/
+/* bos72X src/bos/usr/include/assert.h 1.17.1.7
*/

This _NOTHROW() macro now appears in several places:

-extern void __assert();
-extern void __assert_c99();
+extern _NOTHROW(_NORETURN(void, __assert), ());
+extern _NOTHROW(_NORETURN(void, __assert_c99), ());

While this brings gcc back to life, I am still unable to build a new
version of gcc on AIX.
Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On Tue, 13 Jun 2023, 13:36 Randy Galbraith via Gcc-help, <
gcc-help@gcc.gnu.org> wrote:

> On Mon, Jun 12, 2023 at 6:50 PM David Edelsohn <dje.gcc@gmail.com> wrote:
>
> > >>> Randy Galbraith wrote:
> >
> > > We have a need to match gcc version on Red Hat GNU/Linux 7. I am
> looking
> > > forward to newer GCC once Red Hat is upgraded. However, that will
> likely
> > > break our build. We elevate every warning in gcc to error status that
> > stops
> > > the building. Thus we need to plan for that. At the moment I just need
> to
> > > support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been
> > > completed this would not be an issue. Cheers, -Randy
> >
> > Red Hat provides newer releases of GCC through the GCC Toolset
> > package, but that may be limited to RHEL 8.  RHEL 7 is quite old.
> >
> > Does your AIX 7.2 system have all of the latest Technology Levels
> > (TLs) and Service Packs (SPs) installed? There have been many
> > assembler and linker fixes.
> >
> > If you still have GCC 4.9.2 from the AIX 7.1 system, you should be
> > able to continue to use it.  You can rebuild the "fixed" headers
> > without rebuilding the entire compiler.  I don't believe that anyone
> > has tried bootstrapping GCC with XLC in a very long time.
> >
> > GCC builds and works with AIX Assembler and AIX Linker.  Until
> > recently, GNU Assembler and GNU Linker were out of date on AIX 7.x and
> > produced corrupted object files. The latest GNU Binutils functions.
> > It might be better to ensure that the AIX tools are used (AIX as, ld,
> > ar).
> >
> > GCC 4.9 is very old. I don't have any intuition about why GCC (without
> > any optimization) would generate unusual code for ferror().  Again, I
> > would ensure that you are not using the GNU Assembler for your
> > bootstrap.
> >
> > Thanks, David
> >
>
> I am trying to land a new GCC compiler to address the break related to
> fixed headers. If these could be rebuilt without having to land a new
> compiler I would be most interested in the steps to do that! Any advice on
> where to start with that? Cheers, -Randy
>


See https://gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html which describes
the mkheaders script. That is installed as part of the GCC installation,
and running it will update the fixed headers.

Re: Building gcc 4.9.2 on AIX 7.1

[Randy Galbraith]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

On Mon, Jun 12, 2023 at 6:50 PM David Edelsohn <dje.gcc@gmail.com> wrote:

> >>> Randy Galbraith wrote:
>
> > We have a need to match gcc version on Red Hat GNU/Linux 7. I am looking
> > forward to newer GCC once Red Hat is upgraded. However, that will likely
> > break our build. We elevate every warning in gcc to error status that
> stops
> > the building. Thus we need to plan for that. At the moment I just need to
> > support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been
> > completed this would not be an issue. Cheers, -Randy
>
> Red Hat provides newer releases of GCC through the GCC Toolset
> package, but that may be limited to RHEL 8.  RHEL 7 is quite old.
>
> Does your AIX 7.2 system have all of the latest Technology Levels
> (TLs) and Service Packs (SPs) installed? There have been many
> assembler and linker fixes.
>
> If you still have GCC 4.9.2 from the AIX 7.1 system, you should be
> able to continue to use it.  You can rebuild the "fixed" headers
> without rebuilding the entire compiler.  I don't believe that anyone
> has tried bootstrapping GCC with XLC in a very long time.
>
> GCC builds and works with AIX Assembler and AIX Linker.  Until
> recently, GNU Assembler and GNU Linker were out of date on AIX 7.x and
> produced corrupted object files. The latest GNU Binutils functions.
> It might be better to ensure that the AIX tools are used (AIX as, ld,
> ar).
>
> GCC 4.9 is very old. I don't have any intuition about why GCC (without
> any optimization) would generate unusual code for ferror().  Again, I
> would ensure that you are not using the GNU Assembler for your
> bootstrap.
>
> Thanks, David
>

I am trying to land a new GCC compiler to address the break related to
fixed headers. If these could be rebuilt without having to land a new
compiler I would be most interested in the steps to do that! Any advice on
where to start with that? Cheers, -Randy

Re: Building gcc 4.9.2 on AIX 7.1

[David Edelsohn]

>>> Randy Galbraith wrote:

> We have a need to match gcc version on Red Hat GNU/Linux 7. I am looking
> forward to newer GCC once Red Hat is upgraded. However, that will likely
> break our build. We elevate every warning in gcc to error status that stops
> the building. Thus we need to plan for that. At the moment I just need to
> support the AIX 7.2 upgrade. Ironically had our port to GNU/Linux been
> completed this would not be an issue. Cheers, -Randy

Red Hat provides newer releases of GCC through the GCC Toolset
package, but that may be limited to RHEL 8.  RHEL 7 is quite old.

Does your AIX 7.2 system have all of the latest Technology Levels
(TLs) and Service Packs (SPs) installed? There have been many
assembler and linker fixes.

If you still have GCC 4.9.2 from the AIX 7.1 system, you should be
able to continue to use it.  You can rebuild the "fixed" headers
without rebuilding the entire compiler.  I don't believe that anyone
has tried bootstrapping GCC with XLC in a very long time.

GCC builds and works with AIX Assembler and AIX Linker.  Until
recently, GNU Assembler and GNU Linker were out of date on AIX 7.x and
produced corrupted object files. The latest GNU Binutils functions.
It might be better to ensure that the AIX tools are used (AIX as, ld,
ar).

GCC 4.9 is very old. I don't have any intuition about why GCC (without
any optimization) would generate unusual code for ferror().  Again, I
would ensure that you are not using the GNU Assembler for your
bootstrap.

Thanks, David