*** Bug 47907 has been marked as a duplicate of this bug. ***

*** Bug 47902 has been marked as a duplicate of this bug. ***

AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is wrong and was fixed in later versions. You have a work-around. I am not aware of anyone else trying to use recent versions of GCC on ancient versions of AIX. Customers who continue to use an old version generally freeze all software on the system. Patches are welcome.

(In reply to comment #3)
> AIX 4.3.2 was announced in 1998 and end of service in 2003. The AIX header is
> wrong and was fixed in later versions. You have a work-around. I am not aware
> of anyone else trying to use recent versions of GCC on ancient versions of AIX.
> Customers who continue to use an old version generally freeze all software on
> the system. Patches are welcome.

So if I understand correctly: GCC may still nominally support AIX 4.3, but no one here really wants to spend time dealing with it.

If that's the case, could you set these PRs to WAITING/IN_PROGRESS, and assign them to me? I'll gladly try my hand at some patches, as long as someone here is willing to review them and get them in if they're good.

I was under the impression that fast-integer types could be N bits or more in size, so e.g. "typedef int32_t int_fast16_t" would be valid (and may make sense for the architecture). So you're saying that's not it, and sys/inttypes.h needs fixincluding?

I am willing to review patches, although I do not have access to AIX 4.3 systems to test.

More recent versions of AIX define inttypes that correspond to the current definition in GCC. The 4.3.2 definitions are not invalid, but probably are not the best choices or consistent with current definitions.

Changing AIX headers with fixincludes may introduce inconsistencies. This could be fixed in aix-stdint.h, but I am concerned about complicating that file to support current GCC on a 15 year old system that few people are interested in. This isn't zero cost for future maintenance. You can change aix-stdint.h yourself and continue to apply the patches if you care about building GCC 4.8 and later.

My first thought had been to put in AIX-version-dependent cpp conditionals in aix-stdint.h, but admittedly, that would have been an ugly way to go.

I have an AIX 5.3 system here as well. There is no sys/inttypes.h, but [u]int_fastNN_t is defined in sys/stdint.h, and all the types are the same size as [u]intNN_t. This is presumably the case for newer AIXes as well.

Fixincluding sys/inttypes.h should be safe IMO, and any bad fallout from that should be limited to AIX releases that still have this header, and use the unequal-sized-types, and somehow depend on those types. I'll double-check that this isn't the case for 4.3.

Created attachment 27821 [details]
Patch against GCC SVN trunk

Hi David,

The attached patch is everything I've got so far to address issues in building GCC on AIX 4.3. This covers issues beyond this bug report, but I figured you'd rather take care of everything in one go. A walk-through of the changes:

++ gcc/opt-functions.awk

* Escape "{" characters to not annoy older awk programs

++ gcc/config/rs6000/rs6000.c

* legitimate_indirect_address_p() was coming up as undefined when declared with the "inline" keyword

* ASM_WEAKEN_DECL() was coming up undefined, too, even though the call is in a section of code not actually used on this platform

++ fixincludes/tests/base/*.h

* Updates to the test suite

++ fixincludes/inclhack.def

* Fixinclude for the oddly-sized fast-integer types

* Fixinclude for the broken PRIxNN macros in inttypes.h

* Fixinclude for an incomplete PTHREAD_ONCE_INIT (breaks -Werror builds)

* Tweaked the aix_pthread hack, as pthread.h has a tab character immediately after the "#define" on my system

* Fixinclude for an strtof() declaration lacking a const keyword (bug #48009)


Please let me know what you think.

Patches are reviewed on gcc-patches mailinglist, not in Bugzilla

> The attached patch is everything I've got so far to address issues in
> building GCC on AIX 4.3. This covers issues beyond this bug report, but I
> figured you'd rather take care of everything in one go. A walk-through of
> the changes:
> 
> ++ gcc/opt-functions.awk
> 
> * Escape "{" characters to not annoy older awk programs

Prerequisites for GCC explicitly states that POSIX or SVR4 awk is required, so I don't think that this work-around would be accepted.  For example, you can install GNU Awk.

> 
> ++ gcc/config/rs6000/rs6000.c
> 
> * legitimate_indirect_address_p() was coming up as undefined when declared
> with the "inline" keyword

This already has been changed.

> * ASM_WEAKEN_DECL() was coming up undefined, too, even though the call is in
> a section of code not actually used on this platform
> 
> ++ fixincludes/tests/base/*.h
> 
> * Updates to the test suite
> 
> ++ fixincludes/inclhack.def
> 
> * Fixinclude for the oddly-sized fast-integer types
> 
> * Fixinclude for the broken PRIxNN macros in inttypes.h
> 
> * Fixinclude for an incomplete PTHREAD_ONCE_INIT (breaks -Werror builds)
> 
> * Tweaked the aix_pthread hack, as pthread.h has a tab character immediately
> after the "#define" on my system
> 
> * Fixinclude for an strtof() declaration lacking a const keyword (bug #48009)

The fixincludes changes are the most plausible ones.

Author: dje
Date: Sat Feb  7 02:55:03 2015
New Revision: 220502

URL: https://gcc.gnu.org/viewcvs?rev=220502&root=gcc&view=rev
Log:
        PR bootstrap/53348
        * inclhack.def (aix_pthread): Accept tab after define.
        * fixincl.x: Regenerate.

Modified:
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/fixincl.x
    trunk/fixincludes/inclhack.def

Author: dje
Date: Mon Feb 16 15:19:20 2015
New Revision: 220736

URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
Log:
Daniel Richard G. <skunk@iskunk.org>
        PR bootstrap/48009
        PR bootstrap/53348
        * inclhack.def (aix_strtof_const): New fix.
        * fixincl.x: Regenerate.
        * tests/base/inttypes.h: New test.

Modified:
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/fixincl.x
    trunk/fixincludes/inclhack.def

Author: dje
Date: Mon Feb 16 15:33:09 2015
New Revision: 220737

URL: https://gcc.gnu.org/viewcvs?rev=220737&root=gcc&view=rev
Log:
2015-02-16  Michael Haubenwallner  <michael.haubenwallner@ssi-schaefer.com>
            David Edelsohn  <dje.gcc@gmail.com>

        PR target/65058
        * config/rs6000/rs6000.c (rs6000_output_symbol_ref): Append storage
        mapping class to external variable or function reference.
        * config/rs6000/xcoff.h (ASM_OUTPUT_EXTERNAL): Do not append storage
        mapping class.

2015-02-16  David Eelsohn  <dje.gcc@gmail.com>

        PR target/53348
        * config/rs6000/rs6000.c (rs6000_declare_alias): Only use
        ASM_WEAKEN_DECL if defined.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/config/rs6000/xcoff.h

(In reply to David Edelsohn from comment #8)
> Patches are reviewed on gcc-patches mailinglist, not in Bugzilla

Sorry, I'm not properly set up for mailing lists at the moment...

> > * Escape "{" characters to not annoy older awk programs
> 
> Prerequisites for GCC explicitly states that POSIX or SVR4 awk is required,
> so I don't think that this work-around would be accepted.  For example, you
> can install GNU Awk.

POSIX/SVR4 is significant if the system awk is missing major features that would make the script awkward/impossible to maintain. But a small syntax tweak like this, so long as it doesn't hurt other awk implementations, is no big deal. Especially for a script that is run by users who are only compiling the code, as opposed to developers.

> This already has been changed.
> 
[...]
> 
> The fixincludes changes are the most plausible ones.

As an aside, is there documentation somewhere on how to generate a GCC dist tarball from SVN? "make dist" doesn't do it, Web searches turn up nothing, and I'd rather not have to wait a few days for the next snapshot...

The GCC build process has requirements, including SVR4/POSIX awk.  GCC works on a wide variety of systems, but needs to have a base set of requirements and limit accommodation to prevent things from getting out of control.  Building and installing Gawk or Nawk or another implementation is not an unreasonable burden.

(In reply to David Edelsohn from comment #13)
> The GCC build process has requirements, including SVR4/POSIX awk.  GCC works
> on a wide variety of systems, but needs to have a base set of requirements
> and limit accommodation to prevent things from getting out of control. 

I understand that; my point is, escaping a couple of characters falls under the rubric of "limited accommodation." It would be a different story if I wanted GCC to build with an awk that, say, doesn't support variables.

> Building and installing Gawk or Nawk or another implementation is not an
> unreasonable burden.

It's less reasonable than a two-line patch.

(Any info on building a dist tarball? I don't have enough space on my AIX 4.3 system to take the entire SVN tree)

Can the bug be marked as resolved?

Workarounds are available.