[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #276 from Larkin Nickle  ---
Created attachment 51215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51215=edit
How I'm attempting to build GCC 11.1

For what it's worth, here's exactly how I'm attempting to build 11.1. This is
based on The Written Word's script from comment #246.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #275 from dave.anglin at bell dot net ---
On 2021-07-21 12:55 p.m., me at larbob dot org wrote:
> Here's `disas $pc-256,$pc+256`'s output.
Maybe r47 contains garbage.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #274 from Larkin Nickle  ---
Created attachment 51190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51190=edit
disas of cc1 with more context

Here's `disas $pc-256,$pc+256`'s output.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #273 from John Buddery  ---
If you go back a bit further, is there a speculative load of one of those
registers
 (probably r47 / r59 ) ?
A speculative load will have a .s I think.

I believe ILL_REGNAT should actually be a SEGV, not SIGILL - not sure why
that's the signal being generated.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #272 from Larkin Nickle  ---
(In reply to dave.anglin from comment #271)
> On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> > Reading symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol 
> > number
> > 7215 references nonexistent SHT_SYMTAB_SHNDX section
> > Can't read symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
> > wrong format
> This seems to be a problem with the symbol table in cc1.  It's not a problem
> with the dwarf info.
> 
> Can readelf read symbols?  What does file command show?  If you strip cc1,
> does gdb start?

On system with a modern `file`:

cc1: ELF 32-bit MSB executable, IA-64, version 1 (HP-UX), dynamically linked,
interpreter /usr/lib/hpux32/uld.so:/usr/lib/hpux32/dld.so, with debug_info, not
stripped, too many notes (256)

Readelf is seemingly able to read them.

> 
> disasm $pc-16,$pc+16 should show faulting instruction.

(gdb) disas $pc-16,$pc+16
Dump of assembler code from 0x54af7e1 to 0x54af801:
   0x054af7e1:  st8 [r41]=r0
   0x054af7e2:  nop.i 0x0;;
   0x054af7f0:  [MMI]   ld1.a r87=[r14]
=> 0x054af7f1:  st8 [r47]=r59
   0x054af7f2:  nop.i 0x0
   0x054af800:  [MMI]   st4 [r46]=r0;;
End of assembler dump.

This issue happens in stage3.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #271 from dave.anglin at bell dot net ---
On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol 
> number
> 7215 references nonexistent SHT_SYMTAB_SHNDX section
> Can't read symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
> wrong format
This seems to be a problem with the symbol table in cc1.  It's not a problem
with the dwarf info.

Can readelf read symbols?  What does file command show?  If you strip cc1, does
gdb start?

disasm $pc-16,$pc+16 should show faulting instruction.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #270 from Larkin Nickle  ---
Reading symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol number
7215 references nonexistent SHT_SYMTAB_SHNDX section
Can't read symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
wrong format

No dice with 7.9.1 either. I've now tried both dwarf2 and dwarf4 to no avail,
and have verified that gdb is able to read, for example, dwarf4 symbols from a
previous gcc 4.9.2 build that I did.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #269 from Larkin Nickle  ---
(In reply to The Written Word from comment #268)
> (In reply to Larkin Nickle from comment #262)
> > Created attachment 51182 [details]
> > GCC 11.1 patch to net dwarf2 debugging symbols
> > 
> > Rebuilding with this patch. Should hopefully net me actual dwarf2 debug
> > symbols.
> 
> What if you use the GCC --gdwarf-2 option instead of this patch? Does the
> patch just set the default DWARF version? Seems like if GCC supports DWARF
> >2, --gdwarf-2 should generate just v2 DWARF info.

Yes, I think that should work fine too.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #268 from The Written Word  
---
(In reply to Larkin Nickle from comment #262)
> Created attachment 51182 [details]
> GCC 11.1 patch to net dwarf2 debugging symbols
> 
> Rebuilding with this patch. Should hopefully net me actual dwarf2 debug
> symbols.

What if you use the GCC --gdwarf-2 option instead of this patch? Does the patch
just set the default DWARF version? Seems like if GCC supports DWARF >2,
--gdwarf-2 should generate just v2 DWARF info.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #267 from The Written Word  
---
(In reply to Larkin Nickle from comment #266)
> I'll try that 7.9.1 as a last resort; I noticed that 7.3.1 was able to read
> dwarf4 symbols from a previous 4.9.2 build I did so I'm testing building
> 11.1 patched to produce debug symbols similarly.

7.9.1 was the last version that had support for HP-UX.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #266 from Larkin Nickle  ---
I'll try that 7.9.1 as a last resort; I noticed that 7.3.1 was able to read
dwarf4 symbols from a previous 4.9.2 build I did so I'm testing building 11.1
patched to produce debug symbols similarly.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #265 from The Written Word  
---
(In reply to Larkin Nickle from comment #264)
> Oh, and I should mention this is what I get with 7.3.1 or 7.5.1:
> 
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1...BFD:
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol
> number 7214 references nonexistent SHT_SYMTAB_SHNDX section
> Can't read symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
> wrong format

There's a GDB 7.9.1 at http://hpux.connect.org.uk/hppd/hpux/Gnu/gdb-7.9.1/.
Does it work better?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #263 from Larkin Nickle  ---
I'm having trouble actually getting a GDB that can read the resulting symbols
properly. 

readelf --debug-dump=info cc1 | grep -A 2 'Compilation Unit @'
  Compilation Unit @ offset 0x0:
   Length:0xa390 (32-bit)
   Version:   2

As shown above, using readelf, I've confirmed I am now getting DWARF2 symbols,
but I'm unable to read them with my own built GDB 7.3.1 or GDB 7.5.1 from
http://ftp.nluug.nl/os/HPUX/itrc/gcc-4.7.2-11.31.sd.bz. HP GDB 6.7 is able to
handle them somewhat:

Object file is generated with GNU compiler: GNU C++17 11.1.0 -g -O2 -fno-PIE
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
HP WDB does not support debugging of programs compiled with GNU compiler.
Some features may work, but it is not guaranteed.
HP recommends using HP aCC compiler, Refer:  http://www.hp.com/go/aCC
Refer http://www.hp.com/go/wdb for the support statement

done.

Running cc1 w/ the arguments that lead to the illegal instruction error (as
verified with -v):

Program received signal SIGILL, Illegal instruction
  si_code: 9 - ILL_REGNAT - Register NaT Consumption.
0x54af7f0:1 in get_ref_base_and_extent (exp=,
poffset=, psize=, pmax_size=,
preverse=) at ../../gcc/tree-dfa.c:525
525   maxsize = wi::to_poly_offset (asize) - bit_offset;

However, trying to get a backtrace with `bt` results in HP GDB core dumping:

#0  0x54af7f0:1 in get_ref_base_and_extent (exp=,
poffset=, psize=, pmax_size=,
preverse=) at ../../gcc/tree-dfa.c:525
Assertion failed: stacki == 0, file ../../../Src/gnu/gdb/dwarf2read.c, line
1579
ABORT instruction (core dumped)

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #264 from Larkin Nickle  ---
Oh, and I should mention this is what I get with 7.3.1 or 7.5.1:

Reading symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1...BFD:
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol number
7214 references nonexistent SHT_SYMTAB_SHNDX section
Can't read symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in
wrong format

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #262 from Larkin Nickle  ---
Created attachment 51182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51182=edit
GCC 11.1 patch to net dwarf2 debugging symbols

Rebuilding with this patch. Should hopefully net me actual dwarf2 debug
symbols.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #261 from Larkin Nickle  ---
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=59447

Argh, it seems that `--with-dwarf2` basically just means use dwarf2 *or later*,
at least in GCCs this new. Will patch gcc/common.opt and rebuild.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #260 from Larkin Nickle  ---
(In reply to dave.anglin from comment #259)
> The compiler being used to compile mkstemps.c is broken.  If core dumps are
> enabled,
> you should be able to use gdb (wdb) directly to find the illegal instruction.
> 
> If not, one can find the illegal instruction by adding "-save-temps -v" to
> the compile command.
> This will give the information needed to run the compilation under gdb (wdb)
> 
> If I was to guess, the illegal instruction is likely to be an out of range
> branch.
> 
> I would check HP patch for HP ld.  There may be version dependent
> differences in weak support.

Indeed, I'm trying to get a working gdb up now. I have the latest ld version.

ld: 92453-07 linker ld HP Itanium(R) B.12.67  IPF/IPF

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #259 from dave.anglin at bell dot net ---
On 2021-07-19 5:00 p.m., me at larbob dot org wrote:
> I've now tried 11.1.0 almost exactly as The Written Word builds it, and still
> get:
>
> during GIMPLE pass: dce
> ../../libiberty/mkstemps.c: In function 'mkstemps':
> ../../libiberty/mkstemps.c:80:1: internal compiler error: Illegal instruction
>80 | mkstemps (char *pattern, int suffix_len)
>   | ^~~~
The compiler being used to compile mkstemps.c is broken.  If core dumps are
enabled,
you should be able to use gdb (wdb) directly to find the illegal instruction.

If not, one can find the illegal instruction by adding "-save-temps -v" to the
compile command.
This will give the information needed to run the compilation under gdb (wdb)

If I was to guess, the illegal instruction is likely to be an out of range
branch.

I would check HP patch for HP ld.  There may be version dependent differences
in weak support.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #258 from Larkin Nickle  ---
I've now attached the configure log as well as the build log for GCC 11.1 with
`-j1` passed to make so as to make the log more readable.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #257 from Larkin Nickle  ---
Created attachment 51180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51180=edit
Build log for GCC 11.1 with -j1

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #256 from Larkin Nickle  ---
Created attachment 51179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51179=edit
Configure log for gcc 11.1.0

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #255 from Larkin Nickle  ---
Here's the log from the attempted 11.1 build against binutils 2.30. Built with
4.8.5. I'm not able to attach this as it's over the max size limit.

https://gist.githubusercontent.com/larb0b/f3a855892f7b16f4676444f2c056947e/raw/e94e0a3b54a555e6111ecef634d082d78d983ee9/gcc-11.1.0.b

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #254 from Larkin Nickle  ---
I've now tried 11.1.0 almost exactly as The Written Word builds it, and still
get:

during GIMPLE pass: dce
../../libiberty/mkstemps.c: In function 'mkstemps':
../../libiberty/mkstemps.c:80:1: internal compiler error: Illegal instruction
   80 | mkstemps (char *pattern, int suffix_len)
  | ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This happens against binutils 2.30 as TWW builds it, and against 2.36 or 2.37.
I also have to enable a version of gcc-11.1.0-PR64919.patch with #undef
MAKE_DECL_ONE_ONLY removed in order to build libgcov at a lower optimization
level to even get to this point. TWW gets this issue with 10.3, but not 11.1
for some reason.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #253 from The Written Word  
---
(In reply to The Written Word from comment #245)
> (In reply to John Buddery from comment #238)
> > Was your 11.1 build successful ?
> 
> Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I
> am going to try earlier GCC releases and build on 11.23/IA as well.

A build on 11.23/IA worked using similar patches to 11.31/IA.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #252 from The Written Word  
---
(In reply to Larkin Nickle from comment #249)
> Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
> eventually run into other errors:
> 
> ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c: In function
> 'gcov_clear':
> ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c:143:1:
> internal compiler error: Illegal instruction
>   143 | }
>   | ^
> libbacktrace could not find executable to open 

I tried building 10.3.0 using the same patches as in 11.1.0 and ran into the
above for the 10.3.0 build.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #251 from dave.anglin at bell dot net ---
On 2021-07-15 2:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #243 from The Written Word  com> ---
> (In reply to John Buddery from comment #238)
>> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
>> later require a 64 bit build for 64 bit objects to work reliably.
> I can build up to and including 2.32 with the HP C compiler. Starting with
> 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry
> with 2.32.
Adding -std=gnu99 unilaterally seems like a bug.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #250 from Larkin Nickle  ---
I should probably note that my PATH is set to the standard path, appended with
the PATH to whichever GCC's bin folder as well as a folder I have with some
utilities:

awk   gawk  make  mksh  sed   tar

I use mksh as my CONFIG_SHELL as the system shells don't play nicely with some
configure scripts, e.g. binutils' in my experience.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #249 from Larkin Nickle  ---
I am still unable to replicate a proper 11.1 build against 2.36 gas. Here's my
process:

HP GCC 4.7.1 -> GCC 4.7.4:

../../sources/gcc-4.7.4/configure --prefix=/usr/util/toolchain/gcc-4.7.4 --w
ith-as=/opt/hp-gcc/bin/as --enable-languages=c,c++ --disable-nls

-> 4.9.2:

../../sources/gcc-4.9.2/configure --disable-libgomp --with-as=/opt/hp-gcc/bi
n/as --enable-languages=c,c++ --prefix=/usr/util/toolchain/gcc-4.9.2
--disable-n
ls

Then, I compiled binutils 2.36 (w/ -mlp64), gmp 6.2.1, mpfr 4.1.0, and mpc
1.2.1 with HP GCC 4.7.1. All GMP tests passed except for `t-printf`, all mpfr
tests passed except `tasprintf`, and all mpc tests passed. These results are
the same as John's except his `t-printf` passes with GMP.

Then, I compile GCC 11.1.0 with GCC 4.9.2:

../../sources/gcc-11.1.0/configure --prefix=/usr/util/toolchain/gcc-11.1.0 -
-enable-comdat --disable-libgomp --disable-nls
--with-as=/usr/util/toolchain/bin
utils-2.36/bin/as --with-gmp=/usr/util/toolchain/gmp-6.2.1
--with-mpfr=/usr/util
/toolchain/mpfr-4.1.0 --with-mpc=/usr/util/toolchain/mpc-1.2.1
--enable-language
s=c,c++ --with-dwarf2

First it errors out when compiling charset.c:

../../../sources/gcc-11.1.0-new/libcpp/charset.c: In function 'cset_converter
init_iconv_desc(cpp_reader*, const char*, const char*)':
../../../sources/gcc-11.1.0-new/libcpp/charset.c:695:1: internal compiler
error: in plus_constant, at explow.c:101
  695 | }
  | ^
libbacktrace could not find executable to open 

Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
eventually run into other errors:

../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c: In function
'gcov_clear':
../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c:143:1: internal
compiler error: Illegal instruction
  143 | }
  | ^
libbacktrace could not find executable to open 

After making that compile with -O1:

../../../sources/gcc-11.1.0/zlib/inftrees.c: In function 'inflate_table':
../../../sources/gcc-11.1.0/zlib/inftrees.c:32:19: internal compiler error:
Illegal instruction
   32 | int ZLIB_INTERNAL inflate_table(type, lens, codes, table, bits, work)
  |   ^
libbacktrace could not find executable to open

I am only able to get a build of 11.1 with BOOT_CFLAGS="-g -O1"
BOOT_CXXFLAGS="-g -O1".

It's worth noting that I have rebuilt gmp with the -O1'd 11.1 build and it
fixed the `t-printf` test not passing. I then rebuilt mpfr and mpc against it
with 4.7.1 (4.9.2 and 11.1 can't seem to properly compile mpfr) and then tried
to build 11.1 against the new builds and still ran into the same issues.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #248 from The Written Word  
---
(In reply to John Buddery from comment #247)
> For clarification, I assume this is using the HP aCC compiler for binutils
> etc., rather than the bundled /usr/ccs/bin cc ?

Correct.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #247 from John Buddery  ---
Looks good, that's a lot of gcc versions!

For clarification, I assume this is using the HP aCC compiler for binutils
etc., rather than the bundled /usr/ccs/bin cc ?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #246 from The Written Word  
---
Created attachment 51163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51163=edit
Build script and patches

Build script for zlib, gmp, mpfr, mpc, binutils 2.25.1, 2.30, 2.32, and GCC
4.4.6, 4.6.4, 4.7.4, 4.8.5, 4.9.5, and 11.1.0. Build instructions for GCC 9.4.0
and 10.3.0 included but not tested yet.

Patches for all of the above included as well.

Work-in-progress.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #245 from The Written Word  
---
(In reply to John Buddery from comment #238)
> Was your 11.1 build successful ?

Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I am
going to try earlier GCC releases and build on 11.23/IA as well.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #244 from John Buddery  ---
I tried a gcc 11 build with patched 2.30 binutils and it worked.

I also tried building binutils 2.36 with just /opt/aCC/bin and no gcc.

I didn't get any gnu99 errors, but it did fail because plugin-api.h couldn't
work out the endianism.

Configuring with:

  CFLAGS="-O -D__BIG_ENDIAN__=1" ./configure --prefix=/u
sr/local/binutils-test --enable-obsolete

allowed gas to build, but the build then failed later on in libctf. It looks
like libtool is inserting +Maked into the command line for some reason, which
breaks things.

I don't know if this gas build would work for gcc, probably it would have the
same issues as a 32 bit gcc build. +DD64 might fix this.

Probably not worth updating though just for gcc if you have a working 2.30
build, since that works OK.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #243 from The Written Word  
---
(In reply to John Buddery from comment #238)
> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
> later require a 64 bit build for 64 bit objects to work reliably.

I can build up to and including 2.32 with the HP C compiler. Starting with
2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry
with 2.32.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #242 from dave.anglin at bell dot net ---
On 2021-07-15 11:01 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #241 from The Written Word  com> ---
> (In reply to John Buddery from comment #240)
>> One question about PR66319 - it's marked as resolved, so is this committed
>> as a patch in the trunk ?
> It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed.
Patch for PR66319 needs submission to gcc-patches list with cc to ia64 and/or
hpux maintainer.  Patch must be submitted
by someone with copyright assignment or DOC.  See:
https://gcc.gnu.org/contribute.html

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #241 from The Written Word  
---
(In reply to John Buddery from comment #240)
> One question about PR66319 - it's marked as resolved, so is this committed
> as a patch in the trunk ?

It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #240 from John Buddery  ---
Yeah, it sure eats up the space.

One question about PR66319 - it's marked as resolved, so is this committed as a
patch in the trunk ?

I'm hoping that eventually there will be a way to get all the edits here
committed so that future versions will build out of the box.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #239 from The Written Word  
---
(In reply to John Buddery from comment #238)
> Thanks, I'll give it a go.
> 
> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
> later require a 64 bit build for 64 bit objects to work reliably.
> 
> Was your 11.1 build successful ?

Ran out of disk space so had to restart :(

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #238 from John Buddery  ---
Thanks, I'll give it a go.

It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
later require a 64 bit build for 64 bit objects to work reliably.

Was your 11.1 build successful ?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #237 from The Written Word  
---
(In reply to John Buddery from comment #228)
> gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you
> hit errors but may need tidying up.

Instead of this patch, try the patch for PR66319 instead.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #236 from The Written Word  
---
(In reply to John Buddery from comment #235)
> Interesting - that's with a 32 bit gas?

$ file bin/gcc111/ia64-hp-hpux11.31/bin/as
bin/gcc111/ia64-hp-hpux11.31/bin/as:ELF-32 executable object file - IA64
$% bin/gcc111/ia64-hp-hpux11.31/bin/as --version
GNU assembler (GNU Binutils) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `ia64-hp-hpux11.31'.

> It could be a change between 2.30 and 2.36 I guess, I might see if I can
> narrow it down.

We prefer to build with HP C and only use GCC when we must. 2.36 didn't build
as easily out-of-the-box with HP C and we haven't tried to fix it so we've
stuck with 2.30 for newer GCC releases.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #235 from John Buddery  ---
Interesting - that's with a 32 bit gas ?
It does look like you have got past the point in stage1 where ld was crashing.

It could be a change between 2.30 and 2.36 I guess, I might see if I can narrow
it down.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #234 from The Written Word  
---
(In reply to John Buddery from comment #233)
> One additional note - when building the patched binutils 2.36, it must be
> built as 64 bit executables.
> 
> It seems that a 32 bit gas does not produce 64 bit object files properly on
> this platform, causing the linker to crash when making the 64 bit
> libstdc++.so.
> 
> Build binutils as 64 bit, by using a configure something like:
> 
>   CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local

Odd. We currently have a build of 11.1.0 going with as from binutils-2.30 built
using the HP C compiler and:
$ file ./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so
./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so
./.o/prev-ia64-hp-hpux11.31/libstdc++-v3/src/.libs/libstdc++.so:ELF-32
shared object file - IA64
./.o/prev-ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs/libstdc++.so: ELF-64
shared object file - IA64

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #233 from John Buddery  ---
One additional note - when building the patched binutils 2.36, it must be built
as 64 bit executables.

It seems that a 32 bit gas does not produce 64 bit object files properly on
this platform, causing the linker to crash when making the 64 bit libstdc++.so.

Build binutils as 64 bit, by using a configure something like:

  CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #232 from John Buddery  ---
The #undef MAKE_DECL_ONE_ONLY is only for older builds, it's not needed with
the gcc 11 patches.

It was an alternative single line fix which works for 4.7.2 and 4.9.4, which
you need to build if you're starting from scratch.

This was never really the right fix, and as support for systems without
MAKE_DECL_ONE_ONLY has deteriorated in later versions it became harder and
harder to  follow this route. I did get some intermediate versions working with
a lot of hacking, but for any vaguely recent release I would recommend using
the 11.1 patches instead.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #231 from The Written Word  
---
(In reply to John Buddery from comment #228)
> These patches are for 11.1.0, but should work on earlier versions too. With
> this I have a working gcc which I've tested on several large projects.

You don't #undef MAKE_DECL_ONE_ONLY in gcc/config/ia64/hpux.h? If you skip it,
do you skip it on earlier GCC builds as well?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #230 from John Buddery  ---
The mpfr issue seems to be an issue with gcc 4.9.2 compiling later mpfr
versions.

It builds with 4.7.2, so as a workaround try building mpfr outside the gcc tree
using 4.7.2. This may mean you need to build gmp and mpc outside the tree as
well.

I don't know about the ld crash - see if it occurs when building 11.1 after you
get past the mpfr issue.

If it does, that binutils patch will probably work with older binutils
versions, so you might be able to find one compatible with your ld. I don't
think it's the patch itself, as that only affects brl instructions which gcc
won't be generating until the 11.1 patch.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Larkin Nickle  changed:

   What|Removed |Added

 CC||me at larbob dot org

--- Comment #229 from Larkin Nickle  ---
I have not been able to reproduce a working GCC 4.7.4, 4.9.2, or 4.9.3 build
against binutils 2.36. Using HP's GCC 4.7.1 distribution, I am able to compile
4.7.4 against /opt/hp-gcc/bin/as and build a 4.9.2 or 4.9.3 against that same
as. However, building against a patched binutils 2.36 or 2.36.1 (comment #215)
results in an error when linking:

libtool: link: /home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/./gcc/xgcc
-shared-libgcc -B/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/./gcc
-nostdinc++ -L/home/larbob/Projects/gcc/confdirs/gcc-4
.9.3-2/ia64-hp-hpux11.31/hpux64/libstdc++-v3/src
-L/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/ia64-hp-hpux11.31/hpux64/libstdc++-v3/src/.libs
-L/home/larbob/Projects/gcc/confdirs/gcc-4.9.3-2/ia
64-hp-hpux11.31/hpux64/libstdc++-v3/libsupc++/.libs
-B/usr/util/gcc-4.9.3/ia64-hp-hpux11.31/bin/
-B/usr/util/gcc-4.9.3/ia64-hp-hpux11.31/lib/ -isystem
/usr/util/gcc-4.9.3/ia64-hp-hpux11.31/include
-isystem /usr/util/gcc-4.9.3/ia64-hp-hpux11.31/sys-include  -mlp64 -shared
-nostdlib -fPIC -Wl,+h -Wl,libstdc++.so.6 -Wl,+nodefaultrpath -o
.libs/libstdc++.so.6.20   .libs/compatibility.o .libs/com
patibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compa
tibility-condvar.o  
.libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o
.libs/libstdc++.lax/libsupc++convenience.a/atexit_thread.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_alloc.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_array_length.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_array_new.o
.libs/libstdc++.lax/l
ibsupc++convenience.a/bad_cast.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_typeid.o
.libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/del_
op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opv.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o
.libs/libstdc++.lax/libsupc++c
onvenience.a/dyncast.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o .libs/li
bstdc++.lax/libsupc++convenience.a/eh_call.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o
.libs/libstdc++.lax/libsupc++convenience
.a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_ptr.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_term_handler.o .libs/li
bstdc++.lax/libsupc++convenience.a/eh_terminate.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_tm.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_throw.o
.libs/libstdc++.lax/libsupc++convenience.a
/eh_type.o .libs/libstdc++.lax/libsupc++convenience.a/eh_unex_handler.o
.libs/libstdc++.lax/libsupc++convenience.a/enum_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/function_type_info.o .
libs/libstdc++.lax/libsupc++convenience.a/fundamental_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/guard.o
.libs/libstdc++.lax/libsupc++convenience.a/guard_error.o
.libs/libstdc++.lax/libsupc++convenience.a/hash_bytes.o
.libs/libstdc++.lax/libsupc++convenience.a/nested_exception.o
.libs/libstdc++.lax/libsupc++convenience.a/new_handler.o
.libs/libstdc++.lax/libsupc++convenience.a/n$w_op.o
.libs/libstdc++.lax/libsupc++convenience.a/new_opnt.o
.libs/libstdc++.lax/libsupc++convenience.a/new_opv.o
.libs/libstdc++.lax/libsupc++convenience.a/new_opvnt.o
.libs/libstdc++.lax/libsupc$+convenience.a/pbase_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/pmem_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/pointer_type_info.o
.libs/libstdc++.lax/libsupc++convenience$a/pure.o
.libs/libstdc++.lax/libsupc++convenience.a/si_class_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/tinfo.o
.libs/libstdc++.lax/libsupc++convenience.a/tinfo2.o
.libs/libstdc++.lax/$ibsupc++convenience.a/vec.o
.libs/libstdc++.lax/libsupc++convenience.a/vmi_class_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/vterminate.o
.libs/libstdc++.lax/libsupc++convenience.a/cp-d$mangle.o 
.libs/libstdc++.lax/libc++98convenience.a/bitmap_allocator.o
.libs/libstdc++.lax/libc++98convenience.a/pool_allocator.o
.libs/libstdc++.lax/libc++98convenience.a/mt_allocator.o
.libs/lib$tdc++.lax/libc++98convenience.a/codecvt.o
.libs/libstdc++.lax/libc++98convenience.a/complex_io.o
.libs/libstdc++.lax/libc++98convenience.a/ctype.o

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #227 from John Buddery  ---
Created attachment 50970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50970=edit
Patches for gcc-11.1.0, hp-ia64

Mostly patches from this thread, apart from ia64.md which adds support for
using long calls (brl).

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #228 from John Buddery  ---
Sorry it took a while, I've been away for a bit and have lots to catch up on.

These patches are for 11.1.0, but should work on earlier versions too. With
this I have a working gcc which I've tested on several large projects.

Most of the patch is a cumulation of the patches posted earlier in this thread
- unsigned pointer extension, reverting @gprel changes etc.

gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you hit
errors but may need tidying up.

ia64.md is the patch for long calls, to avoid the 25 bit limit which prevents
linking gcc. It's still a work in progress as the instruction bundling is
wrong, but it does work.

Note that you must apply the binutils patch (or build the current binutils
master, or a release after 2.36) to get an assembler that will work with brl
and the HP linker. Do not apply the ia64.md patch without building a patched
gnu assembler first!

Also note that you need a working C++ compiler to bootstrap. That sounds
obvious, but is harder than you think - as far as I  know, none of the
distributed g++ versions work sufficiently.

One way to get a working 4.9.2 g++ is described in my post in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 but there may be other
solutions as well. I've never tried to bootstrap with aCC.

My configure command is:

../gcc-11.1.0/configure --enable-comdat --disable-libgomp --with
-as=/usr/local/binutils/bin/as --enable-languages=c,c++
--prefix=/usr/local/gcc-
11.1.0 --with-gmp=/usr/local_32 --with-mpc=/usr/local_32
--with-mpfr=/usr/local_
32 --with-dwarf2

The --enable-comdat I think is required. I think libgomp doesn't build, I've
never investigated though and disable it. I use dwarf2 as recent gdb versions
won't work. The assembler I use is a patched binutils 2.36.

Good luck!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #226 from dave.anglin at bell dot net ---
John, would you please post your full patch set for ia64-hpux?  This will help
others.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #225 from John Buddery  ---
Yes, I looked briefly at that - I added a new class, but then started hitting
bundling errors because it wasn't being positioned correctly in the 3
instruction bundle.

It will need more changes to itanium2.md, which looks at the actual
itanium_class rather than just the derived type as I was expecting, and fixes
the bundling for long_i only (rather than type L).

For now I've reverted to scall to test the other changes - this seems to work,
probably because the assembler is fixing up any bundling issues

This isn't really right though, as you say it needs combined long_i and scall
behaviour for a new type.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #224 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> but I need to work out how to vary the attribute, as you were right: scall 
> maps
> to a "B" type attribute, but brl is an L+X instruction not a pure B unit
> instruction, so I think it should be type "L".
I think brl needs its own class.  Currently, long_i (for movl) and nop_x (for
nop.x) map to type "L".
The brl class should also map to type "L" but its bypass behavior should be
similar to scall.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #223 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> The simplest variant I have is:
>
> (define_insn "call_nogp"
>   [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
>  (const_int 0))
>(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
>   ""
> {
>   if (TARGET_HPUX && which_alternative == 1 )
> return "brl.call%+.many %1 = %0";
>   else
> return "br.call%+.many %1 = %0";
> }
This looks good.

I agree it should be possible to get the attribute right for brl.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #222 from dave.anglin at bell dot net ---
On 2021-05-20 10:02 a.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #220 from dave.anglin at bell dot net ---
> On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>>
>> --- Comment #219 from John Buddery  ---
>> Great, thanks - I'll look at ia64.c and build and test with that change.
> Instead of creating a separate HPUX pattern, another way might be to setup
> an instruction alternative table.  See define_insn for prefetch.
There is a which_alternative variable that could be used to check for "s"
constraint
(e.g., "which_alternative == 1").

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #221 from John Buddery  ---
Thanks - that is neater, as it avoids the need to change the calls in ia64.c,
which gets messy.

The simplest variant I have is:

(define_insn "call_nogp"
  [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
 (const_int 0))
   (clobber (match_operand:DI 1 "register_operand" "=b,b"))]
  ""
{
  if (TARGET_HPUX && which_alternative == 1 )
return "brl.call%+.many %1 = %0";
  else
return "br.call%+.many %1 = %0";
}
  [(set_attr "itanium_class" "br,scall")])

but I need to work out how to vary the attribute, as you were right: scall maps
to a "B" type attribute, but brl is an L+X instruction not a pure B unit
instruction, so I think it should be type "L".

Looks like cond and match-test are valid for attributes, so it should be
possible to get this right.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #220 from dave.anglin at bell dot net ---
On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #219 from John Buddery  ---
> Great, thanks - I'll look at ia64.c and build and test with that change.
Instead of creating a separate HPUX pattern, another way might be to setup
an instruction alternative table.  See define_insn for prefetch.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #219 from John Buddery  ---
Great, thanks - I'll look at ia64.c and build and test with that change.

Yes, "b" on ia64 seems to be a branch register, and the brl op only accepts
immediate values not registers. Initially I hoped the assembler would patch
this up and accept both, but it doesn't so the two variants are needed.

I'll look into the scall attribute as well.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #218 from dave.anglin at bell dot net ---
On 2021-05-20 5:19 a.m., jvb at cyberscience dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #217 from John Buddery  ---
> Thanks very much for adding the binutils patch.
>
> Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you
> mean something like:
>
> (define_insn "call_nogp_longcall"
>   [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
>  (const_int 0))
>(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
>   "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2"
>   "@
>br.call%+.many %1 = %0
>brl.call%+.many %1 = %0"
>   [(set_attr "itanium_class" "br,scall")])
>
> (define_insn "call_nogp"
>   [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
>  (const_int 0))
>(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
>   ""
>   "br.call%+.many %1 = %0"
>   [(set_attr "itanium_class" "br,scall")])
>
> I assume you need a second instruction to catch the case where the condition
> doesn't match ?
Yes.  Note that the call_nogp pattern is output directly in a couple of places
in ia64.c.  These
will need adjustment for hpux.

I'm not a ia64 maintainer.  I can only apply changes specific to hpux.

I have limited knowledge of the ia64 instruction set.  In the above, the
"brl.call" alternative
apples to the "s" constraint for operand 0.  Is that what you want?  The
"br.call" form is used
for the disparaged "b" constraint for operand 0.

I'm not sure that the scall call attribute is correct for brl.
>
> Itanium 1 support seems to have been dropped at some point, so -mtune only
> accepts options mapping to Itanium2. So, I couldn't test the br case on HP.
Then, we don't need to check the ia64_tune in the above.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #217 from John Buddery  ---
Thanks very much for adding the binutils patch.

Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you
mean something like:

(define_insn "call_nogp_longcall"
  [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
 (const_int 0))
   (clobber (match_operand:DI 1 "register_operand" "=b,b"))]
  "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2"
  "@
   br.call%+.many %1 = %0
   brl.call%+.many %1 = %0"
  [(set_attr "itanium_class" "br,scall")])

(define_insn "call_nogp"
  [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
 (const_int 0))
   (clobber (match_operand:DI 1 "register_operand" "=b,b"))]
  ""
  "br.call%+.many %1 = %0"
  [(set_attr "itanium_class" "br,scall")])

I assume you need a second instruction to catch the case where the condition
doesn't match ?

Itanium 1 support seems to have been dropped at some point, so -mtune only
accepts options mapping to Itanium2. So, I couldn't test the br case on HP.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #216 from dave.anglin at bell dot net ---
On 2021-05-17 5:56 a.m., jvb at cyberscience dot com wrote:
> With the working as, I changed gcc to use brl instructions for calls, 
> including
> tail calls:
>
> --- gcc-11.1.0/gcc/config/ia64/ia64.md  2021-04-27 11:00:13.0 +0100
> +++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md2021-05-13 14:49:21.0
> +0100
> @@ -4410,7 +4410,9 @@
>  (const_int 0))
> (clobber (match_operand:DI 1 "register_operand" "=b,b"))]
>""
> -  "br.call%+.many %1 = %0"
> +  "@
> +   br.call%+.many %1 = %0
> +   brl.call%+.many %1 = %0"
>[(set_attr "itanium_class" "br,scall")])
>
>  (define_insn "call_value_nogp"
> @@ -4419,14 +4421,18 @@
>   (const_int 0)))
> (clobber (match_operand:DI 2 "register_operand" "=b,b"))]
>""
> -  "br.call%+.many %2 = %1"
> +  "@
> +   br.call%+.many %2 = %1
> +   brl.call%+.many %2 = %1"
>[(set_attr "itanium_class" "br,scall")])
>
>  (define_insn "sibcall_nogp"
>[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
>  (const_int 0))]
>""
> -  "br%+.many %0"
> +  "@
> +   br%+.many %0
> +   brl%+.many %0"
>[(set_attr "itanium_class" "br,scall")])
>
>  (define_insn "call_gp"
We only should use brl when TARGET_HPUX and ia64_tune == PROCESSOR_ITANIUM2.  I
wouldn't worry too much
about it being slightly less efficient.  You can use the pattern constraint to
implement this.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jvb at cyberscience dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

John Buddery  changed:

   What|Removed |Added

 CC||jvb at cyberscience dot com

--- Comment #215 from John Buddery  ---
I recently upgraded my hp-ix ia64 gcc build to 11.1.0, and I thought I'd share
what I did in case it's useful for anyone still following this thread.

I started with the patches in this thread, and soon got to the 21 bit
relocation errors.

Thanks to the excellent PCREL60B analysis above, I applied this simple edit to
binutils 2.36 (you have to enable obsoletes to get a build):

--- binutils-2.36/gas/config/tc-ia64.c  2021-01-09 10:47:33.0 +
+++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
+0100
@@ -6892,7 +6892,13 @@
   for (j = 0; j < md.slot[curr].num_fixups; ++j)
{
  ifix = md.slot[curr].fixup + j;
- fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
+  
+  unsigned long where = frag_now_fix () - 16 + i;
+#ifdef TE_HPUX
+  if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
+#endif
+   
+ fix = fix_new_exp (frag_now, where, 8,
 >expr, ifix->is_pcrel, ifix->code);
  fix->tc_fix_data.opnd = ifix->opnd;
  fix->fx_file = md.slot[curr].src_file;

This fixes, for HP only, the PCTEL60B offset to be what the HP linker expects.
I don't know if the same is appropriate for Linux ia-64 or not, as I don't have
access to that environment. I'll add that to the binutils bug report as well,
but I've included it here so people can find it for gcc more easily.

With the working as, I changed gcc to use brl instructions for calls, including
tail calls:

--- gcc-11.1.0/gcc/config/ia64/ia64.md  2021-04-27 11:00:13.0 +0100
+++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md2021-05-13 14:49:21.0
+0100
@@ -4410,7 +4410,9 @@
 (const_int 0))
(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
   ""
-  "br.call%+.many %1 = %0"
+  "@
+   br.call%+.many %1 = %0
+   brl.call%+.many %1 = %0"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "call_value_nogp"
@@ -4419,14 +4421,18 @@
  (const_int 0)))
(clobber (match_operand:DI 2 "register_operand" "=b,b"))]
   ""
-  "br.call%+.many %2 = %1"
+  "@
+   br.call%+.many %2 = %1
+   brl.call%+.many %2 = %1"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "sibcall_nogp"
   [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
 (const_int 0))]
   ""
-  "br%+.many %0"
+  "@
+   br%+.many %0
+   brl%+.many %0"
   [(set_attr "itanium_class" "br,scall")])

 (define_insn "call_gp"

You have to be careful only to use brl on immediate calls, the assembler does
not accept brl with registers.

The above unconditionally uses brl - on hp-ux and other platforms. This would
work very badly (if at all) on an Itanium 1 (but I'm not sure they are still
around), and is slightly less efficient even on Itanium 2. So, possibly this
should be more limited, maybe using -mlong-call as requesting in Bug 20819 ?

Anyway, with the assembler patch and the brl patch, along with the other
patches in this thread, gcc 11.1.0 will successfully bootstrap in both 32 and
64 bits, and seems to work well - I've built a large 64 bit project with no
problems so far.

There are a lot of fails from the testsuite, but I suspect that's normal for
this os (I'll post results to the testresults list).

---
John

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter at int19h dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #214 from Peter Bisroev  ---
(In reply to Andrew Pinski from comment #213)
> Does this still happen with GCC 8 or above?

Hi Andrew, yes it does from my last tests. As we have found out here, before
newer versions of GCC can work on HP-UX we need to get a working gas. Please
refer to this gas Bugzilla ticket for details:

https://sourceware.org/bugzilla/show_bug.cgi?id=25599

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #213 from Andrew Pinski  ---
Does this still happen with GCC 8 or above?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared  ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: The value 0xfe38a260 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 222 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
> ld: The value 0xfe587970 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 2125 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file2.o]
Yes.  Most likely these are references to weak symbols.  Compiling with -Os
might help.
>  
>
>
> Using gcc version 4.2.3.  On 64 bit HP-UX
> Here is the raw command line.
> /usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
> -L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
> L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
> -L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
> y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
> /library/home/build/tapecut5/code/bin/spectrum 
>
> Is there a fix for this?  Newer compiler or an option?
>
No.  They block building latter versions of gcc that require g++.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jared.martinsen at fiserv dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Jared  changed:

   What|Removed |Added

 CC||jared.martinsen at fiserv dot 
com

--- Comment #211 from Jared  ---
Are these errors the same as described above?

It give the following 2 errors:
ld: The value 0xfe38a260 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 222 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
ld: The value 0xfe587970 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 2125 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file2.o] 


Using gcc version 4.2.3.  On 64 bit HP-UX
Here is the raw command line.
/usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
-L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
-L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
/library/home/build/tapecut5/code/bin/spectrum 

Is there a fix for this?  Newer compiler or an option?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #210 from dave.anglin at bell dot net ---
On 2020-05-02 12:14 a.m., peter.bisroev at groundlabs dot com wrote:
> Looks like we might have to get the fix into GNU AS first to get PCREL60B
> working. I will try to look into how we can get this done hopefully next
> weekend.
I agree.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #209 from Peter Bisroev  ---
(In reply to dave.anglin from comment #206)
> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
> cc1plus?

Hi Dave,

Sorry for the delayed response. I have tried linker option "-Wl,-O" but it does
not seem to make any difference. I used gcc 4.7.4 compiled with --enable-comdat
option as per my comment 181 and get the same number of PCREL21B errors as
before. I wonder if HPs linker does garbage collection after it deals with all
the relocations first.

Looks like we might have to get the fix into GNU AS first to get PCREL60B
working. I will try to look into how we can get this done hopefully next
weekend.

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #208 from dave.anglin at bell dot net ---
On 2020-04-23 11:48 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> Peter Bisroev  changed:
>
>What|Removed |Added
> 
>  CC||peter.bisroev at groundlabs 
> dot co
>||m
>
> --- Comment #207 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #206)
>> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
>> cc1plus?
> Hi Dave, sorry for the delayed response. That is a good catch, I missed that
> option before. I will be able to test this out this weekend. Will let you know
> asap.
I saw it perusing the comments for weak support on PA-RISC.  I believe that I
found that shared libraries
are automatically garbage collected but applications are not.

Dave

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Peter Bisroev  changed:

   What|Removed |Added

 CC||peter.bisroev at groundlabs 
dot co
   ||m

--- Comment #207 from Peter Bisroev  ---
(In reply to dave.anglin from comment #206)
> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
> cc1plus?

Hi Dave, sorry for the delayed response. That is a good catch, I missed that
option before. I will be able to test this out this weekend. Will let you know
asap.

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #206 from dave.anglin at bell dot net ---
Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
cc1plus?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #205 from Peter Bisroev  ---
Hi Dave,

I have submitted bug 25599
(https://sourceware.org/bugzilla/show_bug.cgi?id=25599) to binutils with a
slightly simplified test case and CCed you as well.

Additionally, I was also able to verify that current binutils (2.34), can now
be compiled with our bootstrapped gcc 4.7.4 (I was not able to do so using aCC
before). So hopefully once the bug is fixed we can continue testing it here.

Thanks again for your help!

--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #204 from Peter Bisroev  ---
(In reply to dave.anglin from comment #203)
> On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > Now looking at the main.o generated by gcc, the relocation seems to be as
> > expected but the relocation address seems to be off:
> > --
> > 20:   04 00 00 00 01 00   [MLX]   nop.m 0x0
> >   21: PCREL60Bhello
> > 26:   00 00 00 00 00 00   brl.call.sptk.many b0=20 
> > 
> > 2c:   08 00 00 d0
> > --
> >
> > As can be seen above, GNU as is telling HP's ld to do the relocation at 
> > 0x21,
> > which falls into slot 1 and 0. However the relocation needs to be done at 
> > 0x26
> > to cover slots 2 and 1.
> Comparing with HP as, it looks to me like the relocation should be at 0x22
> and that's why
> the preceding nop.m instruction is being clobbered.
> 
> Would you file a binutils bug report with the main.s gcc source?  It looks
> like gcc doesn't
> generate brl branches and this never got tested.  You can add me to the cc
> list.

Thank you Dave, you are 100% correct, it needs to be at 0x22. I was looking at
the same screen for too long yesterday.

Anyway, I have manually patched my object to use 0x22 as reloc offset as well
as another brl related offset to a weakfunc() and everything linked and worked
perfectly.
--
...
4000950:   04 00 00 00 01 00   [MLX]   nop.m 0x0
4000956:   00 00 00 00 00 00   brl.call.sptk.many
b0=40009d0 
400095c:   88 00 00 d0 
...
4000970:   04 00 00 00 01 00   [MLX]   nop.m 0x0
4000976:   00 00 00 00 00 00   brl.call.sptk.many
b0=4000ac0 
400097c:   58 01 00 d0 
...
--

I will file a bug with binutils.

Thanks again for catching my offset mistake.

--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #203 from dave.anglin at bell dot net ---
On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> Now looking at the main.o generated by gcc, the relocation seems to be as
> expected but the relocation address seems to be off:
> --
> 20:   04 00 00 00 01 00   [MLX]   nop.m 0x0
>   21: PCREL60Bhello
> 26:   00 00 00 00 00 00   brl.call.sptk.many b0=20 
> 2c:   08 00 00 d0
> --
>
> As can be seen above, GNU as is telling HP's ld to do the relocation at 0x21,
> which falls into slot 1 and 0. However the relocation needs to be done at 0x26
> to cover slots 2 and 1.
Comparing with HP as, it looks to me like the relocation should be at 0x22 and
that's why
the preceding nop.m instruction is being clobbered.

Would you file a binutils bug report with the main.s gcc source?  It looks like
gcc doesn't
generate brl branches and this never got tested.  You can add me to the cc
list.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #202 from Peter Bisroev  ---
(In reply to dave.anglin from comment #201)
> On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote:
> > They both seem to be ELF32
> Maybe run failing program under gdb to find faulting instruction.  Compare
> with executable that works.

Hi Dave,

Well, decoding IA-64 instruction bundles by hand is not fun :) But at least we
know what is going on here now.

Looking at main.o generated by aCC, the relocation is as expected:
--
30:   05 00 00 00 01 00   [MLX]   nop.m 0x0
32: PCREL60Bhello
36:   00 00 00 00 00 00   brl.call.dptk.many b0=30
;;
3c:   08 00 00 d2
--

Once ld takes care of relocation everything is as expected as well:
--
40009b0:   05 00 00 00 01 00   [MLX]   nop.m 0x0
40009b6:   00 00 00 00 00 00   brl.call.dptk.many
b0=4000a40 ;;
40009bc:   98 00 00 d2
--

I've decoded this instruction bundle by hand and verified that immediate value
is 0x90 (0x9 << 4) which matches our relative offset of 0x4000a40−0x40009b0 as
expected.


Now looking at the main.o generated by gcc, the relocation seems to be as
expected but the relocation address seems to be off:
--
20:   04 00 00 00 01 00   [MLX]   nop.m 0x0
  21: PCREL60Bhello
26:   00 00 00 00 00 00   brl.call.sptk.many b0=20 
2c:   08 00 00 d0
--

As can be seen above, GNU as is telling HP's ld to do the relocation at 0x21,
which falls into slot 1 and 0. However the relocation needs to be done at 0x26
to cover slots 2 and 1.


Now looking at the linked binary we are getting the following:
--
4000950:   04 00 00 00 00 00   [MLX]   break.m 0x0
4000956:   00 40 00 00 00 00   brl.call.sptk.many
b0=4000950 <_end+0xc3ff0908>
400095c:   08 00 00 d0
--

As can be seen above, the slot 0 instruction changed from nop.m to break.m, and
this is where we are getting the illegal instruction. In this linked binary,
hello() is located at 0x40009d0. So based on this, we expect the offset to be
0x80 (0x40009d0 - 0x4000950). So the expected immediate value for brl.call
should be 0x08 (0x80>>4).

I decided to double check that HP's ld is doing this relocation properly but at
the wrong offset requested by GNU as. Based on our relocation offset of 0x21, I
have interpreted slots 1 and 0 by hand as if they were slots 2 and 1. Once we
do that, we get the immediate value of 0x08 as expected. The nop.m changes to
break.m because ld cleared bits of imm39 (bits 20-58) that form the 60 bit
immediate.

Based on the above, unless I am mistaken, it looks like a bug in GNU as. Once I
get a bit of time this week I will try to look through it to see what is going
on there.

Just out of curiosity, I have also tried to patch the reloc offset to 0x26 in
the object file just to see what happens :). After that, objdump shows expected
relocation offset. However HP's linker dies with bus error when I try to link
the executable. 

But I think we are making some progress here. What do you think?

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #201 from dave.anglin at bell dot net ---
On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote:
> They both seem to be ELF32
Maybe run failing program under gdb to find faulting instruction.  Compare with
executable that works.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #200 from Peter Bisroev  ---
(In reply to dave.anglin from comment #199)
> On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote:
> > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but 
> > when
> > I try to run the binary I get an "Illegal instruction" and a core dump. The
> > illegal instruction seems to be the brl. I know almost nothing of IA-64
> > assembly, so will read up a bit more and try to figure out what is going on
> > there.
> That suggests to me that HP's aCC generates 64-bit ELF code and gcc
> generates 32-bit code.
> Compare header info of the two executable files with readelf.
> 
> I'm not sure why we are struggling with the 32-bit runtime.

They both seem to be ELF32
--
$ readelf -h hello
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, big endian
  Version:   1 (current)
  OS/ABI:UNIX - HP-UX
  ABI Version:   1
  Type:  EXEC (Executable file)
  Machine:   Intel IA-64
  Version:   0x1
  Entry point address:   0x4000980
  Start of program headers:  52 (bytes into file)
  Start of section headers:  69184 (bytes into file)
  Flags: 0x8, 32-bit
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 12
  Size of section headers:   40 (bytes)
  Number of section headers: 37
  Section header string table index: 36

$ readelf -h hello-gcc 
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, big endian
  Version:   1 (current)
  OS/ABI:UNIX - HP-UX
  ABI Version:   1
  Type:  EXEC (Executable file)
  Machine:   Intel IA-64
  Version:   0x1
  Entry point address:   0x4000930
  Start of program headers:  52 (bytes into file)
  Start of section headers:  67824 (bytes into file)
  Flags: 0x8, 32-bit
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 12
  Size of section headers:   40 (bytes)
  Number of section headers: 34
  Section header string table index: 33
--

I am looking for any other differences now.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #199 from dave.anglin at bell dot net ---
On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote:
> Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when
> I try to run the binary I get an "Illegal instruction" and a core dump. The
> illegal instruction seems to be the brl. I know almost nothing of IA-64
> assembly, so will read up a bit more and try to figure out what is going on
> there.
That suggests to me that HP's aCC generates 64-bit ELF code and gcc generates
32-bit code.
Compare header info of the two executable files with readelf.

I'm not sure why we are struggling with the 32-bit runtime.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #198 from Peter Bisroev  ---
(In reply to dave.anglin from comment #196)
> If you create a second object file with a second instance of hello, the
> linker should not
> complain about the second definition of hello since it is weak.  It would
> complain about
> two global instances.
Hi Dave,

I have created a new object hello2.o, and when I tried to link I got
--
"ld: Duplicate symbol "hello" in files hello.o and hello2.o "
--
Then I realized that in hello.s hello is defined as ".global hello". Changing
that to '.weak hello', reassembling and relinking all worked. I guess this
confirms what I have seen in comment 187. So this seems to work as expected.
This worked both with aCC and gcc.

> Could you test whether the "brl" branch works?  Simply take your main.s file
> and edit the branch
> to hello.  This should show whether the assembler can handle it.  If it
> assembles, look at relocation
> and see if program will link.
I took main.s generated by aCC. Made the following changes:
--
$ diff main-aCC.s main-aCC-weak-brl.s 
7c7
<   .global hello
---
>   .weak   hello
41c41
< br.call.dptk.many rp = hello#   ;; // B [main.cc: 10/5]
---
> brl.call.dptk.many rp = hello#   ;; // B [main.cc: 10/5]
--

Reassembled with HP's as, relinked and the test ran fine. With this change when
hello was global PCREL21B relocation was used. When I changed hello to weak,
PCREL21B was still used. When I changed this to weak with a brl, PCREL60B was
used.


I have then tried to do a similar thing with main.s generated by gcc. 
--
$ diff main-gcc.s main-gcc-brl.s 
19c19
<   br.call.sptk.many b0 = hello#
---
>   brl.call.sptk.many b0 = hello#
--

Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when
I try to run the binary I get an "Illegal instruction" and a core dump. The
illegal instruction seems to be the brl. I know almost nothing of IA-64
assembly, so will read up a bit more and try to figure out what is going on
there.

Please let me know if I have missed anything.

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #197 from dave.anglin at bell dot net ---
On 2020-02-21 11:43 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #195 from Peter Bisroev  ---
> Hi Dave,
>
> I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX
> Porting Guide"
> (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577=rep1=pdf).
> I know it is not from hpe.com but seems to be an official HP document HP-UX 
> 11i
> v2 and later.
>
> Anyway, on page 56, it states:
> --
> In Solaris, symbols can be set with a pragma to be weak, which means that 
> these
> symbols are always overridden by any global definition. If an undefined weak
> symbol is never satisfied by a global definition, it is set to 0 before the
> program starts execution. HP_SECONDARY_DEF symbols are similar to Solaris weak
> symbols, but there are some differences. You can use the _HP_SECONDARY_DEF
> pragma to connect a weak and a strong definition (for example, _fopen and
> fopen). The weak definition can be overridden by other strong definitions.
> --
>
> I guess that confirms your statement about sdef.
>
> On page 85, it states:
> --
> The ELF file format provides support for global, local, and weak symbols.
> Creating these symbols requires support from the compiler. The HP C and HP C++
> compilers do not provide support for weak symbols.
>
> The HP-UX 11i v2 and later assembler (/usr/ccs/bin/as) provides support using
> the .weak directive. Example 7-3 “Weak Function Binding Using ASM” defines
> weakfunc to be a weak binding to func. Details on the assembler can be found 
> in
> the Itanium Architecture Assembly Language Reference Guide.
> --
> I guess that confirms your suspicion that aCC does not support weak symbols 
> and
> my results that .weak is supported by HP's assembler.
Yes.

Thus, ia64 running hpux is essentially the same as hppa64 running hpux in its
support for
weak (sdef) symbols.  We didn't hit the long branch issue I guess because
pc-relative branches
go a factor of two further, and maybe the -O0 code generation is denser.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #196 from dave.anglin at bell dot net ---
On 2020-02-21 10:55 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #194 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #193)
>> I presume that if you compile main.cc with g++, hello() becomes weak.  You
>> could test with a second instance of hello.
> Yes, sorry forgot to mention that. When I compile with gcc hello() becomes 
> weak
> as expected. One question though, what do you mean with the second instance of
> hello?
If you create a second object file with a second instance of hello, the linker
should not
complain about the second definition of hello since it is weak.  It would
complain about
two global instances.

One major difference between GNU weak definitions and HP sdef definitions is
that the
HP linker and dynamic loader don't like undefined sdef symbols.  In PA-RISC,
there's no
way to override this in the dynamic loader.
> The comdat testing that I have performed in comment 181 and comment 185 by
> forcing the use of comdat with --enable-comdat definitely made things better 
> as
> we got a significant reduction in PCREL21B linking errors. However some still
> remained. Is it because the use of --enable-comdat did not apply to all the
> code (such as libraries), or even when usage of comdat is forced, HP's ld 
> still
> keeps unnecessary instances around?
I don't know whether HP's ld removes unecessary comdat instances.  Even with
comdat
groups enabled, I think we still have some use of weak because of how
MAKE_DECL_ONE_ONLY
is defined.

Could you test whether the "brl" branch works?  Simply take your main.s file
and edit the branch
to hello.  This should show whether the assembler can handle it.  If it
assembles, look at relocation
and see if program will link.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #195 from Peter Bisroev  ---
Hi Dave,

I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX
Porting Guide"
(http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577=rep1=pdf).
I know it is not from hpe.com but seems to be an official HP document HP-UX 11i
v2 and later.

Anyway, on page 56, it states:
--
In Solaris, symbols can be set with a pragma to be weak, which means that these
symbols are always overridden by any global definition. If an undefined weak
symbol is never satisfied by a global definition, it is set to 0 before the
program starts execution. HP_SECONDARY_DEF symbols are similar to Solaris weak
symbols, but there are some differences. You can use the _HP_SECONDARY_DEF
pragma to connect a weak and a strong definition (for example, _fopen and
fopen). The weak definition can be overridden by other strong definitions.
--

I guess that confirms your statement about sdef.

On page 85, it states:
--
The ELF file format provides support for global, local, and weak symbols.
Creating these symbols requires support from the compiler. The HP C and HP C++
compilers do not provide support for weak symbols.

The HP-UX 11i v2 and later assembler (/usr/ccs/bin/as) provides support using
the .weak directive. Example 7-3 “Weak Function Binding Using ASM” defines
weakfunc to be a weak binding to func. Details on the assembler can be found in
the Itanium Architecture Assembly Language Reference Guide.
--
I guess that confirms your suspicion that aCC does not support weak symbols and
my results that .weak is supported by HP's assembler.

--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #194 from Peter Bisroev  ---
(In reply to dave.anglin from comment #193)
> I presume that if you compile main.cc with g++, hello() becomes weak.  You
> could test with a second instance of hello.
Yes, sorry forgot to mention that. When I compile with gcc hello() becomes weak
as expected. One question though, what do you mean with the second instance of
hello?

> It is clear aCC doesn't support although I think HP as and ld do with some
> caveats.  HP's weak
> support evolved from secondary definition symbols (sdef).  This was never
> well documented and
> the use we make of these symbols on 32-bit pa came from looking at HP's
> linker code.
> 
> I'm thinking that the call to printf goes through PLT because it is resolved
> in a shared library.
This theory makes sense based on my testing so far.

> The R_IA64_PCREL21B relocation works except for code size issues.  HP ld
> doesn't remove unnecessary
> weak instances and for some reason it doesn't do calls to weak functions
> through the PLT when they
> aren't resolved in a shared library.
>
> So, I think we either need to use a long branch (brl) to weak functions or
> we need to change the define
> of MAKE_DECL_ONE_ONLY to avoid the use of weak.  We can try replacing weak
> functions with comdat
> functions, etc.  Currently, we have
> 
> #define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) = 1)
> 
> The latter is probably the better solution as it will result in smaller
> code, but it's trickier.  I'm not sure about
> using brl in the 32-bit hpux runtime.
> 
> Dave

The comdat testing that I have performed in comment 181 and comment 185 by
forcing the use of comdat with --enable-comdat definitely made things better as
we got a significant reduction in PCREL21B linking errors. However some still
remained. Is it because the use of --enable-comdat did not apply to all the
code (such as libraries), or even when usage of comdat is forced, HP's ld still
keeps unnecessary instances around?

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #193 from dave.anglin at bell dot net ---
On 2020-02-21 7:36 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #192 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #191)
>> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
>> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
>> correctly when it refers
>> to a weak function (i.e., it doesn't direct the call through the PLT).  At
>> the same time, weak references
>> don't seem to work with aCC.
>>
>> As far as I can tell, the PCREL21B is generated by gas in
>> gas/config/tc-ia64.c at line 5919.  You could try
>> changing it to PCREL21BI to see if that helps (run binutils testsuite before
>> installing) but the change doesn't
>> seem correct.  We might need to generate a 32-bit branch to weak functions
>> in gcc.
> Hi Dave, thanks for the hint! I have patched by binutils 2.32 as shown in the
> diff below.
> --
> *** ./gas/config/tc-ia64.c.orig Fri Feb 21 23:52:59 2020
> --- ./gas/config/tc-ia64.c  Fri Feb 21 23:54:04 2020
> ***
> *** 5919,5925 
>   else if (opnd == IA64_OPND_TGT25b)
> fix->code = BFD_RELOC_IA64_PCREL21M;
>   else if (opnd == IA64_OPND_TGT25c)
> !   fix->code = BFD_RELOC_IA64_PCREL21B;
>   else if (opnd == IA64_OPND_TGT64)
> fix->code = BFD_RELOC_IA64_PCREL60B;
>   else
> --- 5919,5925 
>   else if (opnd == IA64_OPND_TGT25b)
> fix->code = BFD_RELOC_IA64_PCREL21M;
>   else if (opnd == IA64_OPND_TGT25c)
> !   fix->code = BFD_RELOC_IA64_PCREL21BI;
>   else if (opnd == IA64_OPND_TGT64)
> fix->code = BFD_RELOC_IA64_PCREL60B;
>   else
> --
>
> After recompiling binutils gas failed only two more unit tests than before:
> --
> FAIL: ia64 tls
> FAIL: ia64 relocations
> --
> After looking at both of these I guess it is expected as both of them expect
> PCREL21B instead of PCREL21BI.
>
> I have then attempted to recompile gcc 4.7.4 with this patched gas.
> Unfortunately that fails during linking when xgcc tries to build
> hpux64/libgcc_s.so.0.tmp in 64bit mode during stage 1. An example of an error
> is:
> --
> ld: Unsatisfied symbol"calloc" in file "emutls_s.o": Expect to be defined in
> the load module.
> --
>
> Taking a quick look at emutls_s.o I can see the expected reallocation
> --
> $ readelf -r ./ia64-hp-hpux11.31/hpux64/libgcc/emutls_s.o | grep calloc
> 04d2  00220079 R_IA64_PCREL21BI   calloc + 0
> --
>
> But I have not dug dipper as to why the HP linker is unhappy there. Please let
> me know if you want me to do so.
This was expected.  R_IA64_PCREL21BI is only supposed to be used for local
symbols.
This test confirms it.

Changing gas isn't going to help.
>
>> It would be useful to find out why weak doesn't work with aCC.
> I wanted to see if there is some offical docs on this from HP.
>
> Going through aCC's programmers guide
> (https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=emr_na-c05054285)
> for my version of aCC ("HP C/aC++ B3910B A.06.29 [Oct 18 2016]", "as: HP
> Itanium Assembler B.11.31 (HP-UX/itanium)", "ld: 92453-07 linker ld HP
> Itanium(R) B.12.65  IPF/IPF"). I cannot find anything relevant to 'weak' in
> section 3, or generally in that reference guide.
>
> "Intel(R) Itanium(R) Architecture Assembly Language Reference Guide"
> (https://software.intel.com/sites/default/files/m/d/4/1/d/8/asm_lan.pdf) does
> mention weak symbols. This is also the same syntax that HP's as seems to
> accept.
>
> However in "HP-UX Linker and Libraries User Guide"
> (https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=a00055697en_us)
> on page 59, for nm, it states:
> --
> Distinguish between weak and global symbols by appending * to the key letterof
> weak symbols. 
> --
>
> So it looks like HP's as and ld should support weak symbols so I have decided
> to test it.
>
> --
> // main.cc
>
> extern "C" {
> void hello() __attribute__ ((weak));
> }
>
> int main() {
> hello();
> return 0;
> }
> --
>
> --
> // hello.s
> //   Adapted from "Hello World" Function Without
> //   Unwind Directives from Intel Itanium Architecture
> //   Assembly Language Reference Guide.
>
> .section .rdata, "a", "progbits"
> .align 8
> .STRING1:
> stringz "Hello World!!!\n"
>
>
> .text
> .global hello
> .proc hello
> hello: alloc loc2 = ar.pfs, 0, 4, 1, 0
> mov loc3 = sp
> mov loc1 = b0
> addl out0 = @ltoff(.STRING1), gp

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #192 from Peter Bisroev  ---
(In reply to dave.anglin from comment #191)
> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
> correctly when it refers
> to a weak function (i.e., it doesn't direct the call through the PLT).  At
> the same time, weak references
> don't seem to work with aCC.
> 
> As far as I can tell, the PCREL21B is generated by gas in
> gas/config/tc-ia64.c at line 5919.  You could try
> changing it to PCREL21BI to see if that helps (run binutils testsuite before
> installing) but the change doesn't
> seem correct.  We might need to generate a 32-bit branch to weak functions
> in gcc.

Hi Dave, thanks for the hint! I have patched by binutils 2.32 as shown in the
diff below.
--
*** ./gas/config/tc-ia64.c.orig Fri Feb 21 23:52:59 2020
--- ./gas/config/tc-ia64.c  Fri Feb 21 23:54:04 2020
***
*** 5919,5925 
  else if (opnd == IA64_OPND_TGT25b)
fix->code = BFD_RELOC_IA64_PCREL21M;
  else if (opnd == IA64_OPND_TGT25c)
!   fix->code = BFD_RELOC_IA64_PCREL21B;
  else if (opnd == IA64_OPND_TGT64)
fix->code = BFD_RELOC_IA64_PCREL60B;
  else
--- 5919,5925 
  else if (opnd == IA64_OPND_TGT25b)
fix->code = BFD_RELOC_IA64_PCREL21M;
  else if (opnd == IA64_OPND_TGT25c)
!   fix->code = BFD_RELOC_IA64_PCREL21BI;
  else if (opnd == IA64_OPND_TGT64)
fix->code = BFD_RELOC_IA64_PCREL60B;
  else
--

After recompiling binutils gas failed only two more unit tests than before:
--
FAIL: ia64 tls
FAIL: ia64 relocations
--
After looking at both of these I guess it is expected as both of them expect
PCREL21B instead of PCREL21BI.

I have then attempted to recompile gcc 4.7.4 with this patched gas.
Unfortunately that fails during linking when xgcc tries to build
hpux64/libgcc_s.so.0.tmp in 64bit mode during stage 1. An example of an error
is:
--
ld: Unsatisfied symbol"calloc" in file "emutls_s.o": Expect to be defined in
the load module.
--

Taking a quick look at emutls_s.o I can see the expected reallocation
--
$ readelf -r ./ia64-hp-hpux11.31/hpux64/libgcc/emutls_s.o | grep calloc
04d2  00220079 R_IA64_PCREL21BI   calloc + 0
--

But I have not dug dipper as to why the HP linker is unhappy there. Please let
me know if you want me to do so.

> It would be useful to find out why weak doesn't work with aCC.
I wanted to see if there is some offical docs on this from HP.

Going through aCC's programmers guide
(https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=emr_na-c05054285)
for my version of aCC ("HP C/aC++ B3910B A.06.29 [Oct 18 2016]", "as: HP
Itanium Assembler B.11.31 (HP-UX/itanium)", "ld: 92453-07 linker ld HP
Itanium(R) B.12.65  IPF/IPF"). I cannot find anything relevant to 'weak' in
section 3, or generally in that reference guide.

"Intel(R) Itanium(R) Architecture Assembly Language Reference Guide"
(https://software.intel.com/sites/default/files/m/d/4/1/d/8/asm_lan.pdf) does
mention weak symbols. This is also the same syntax that HP's as seems to
accept.

However in "HP-UX Linker and Libraries User Guide"
(https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US=a00055697en_us)
on page 59, for nm, it states:
--
Distinguish between weak and global symbols by appending * to the key letterof
weak symbols. 
--

So it looks like HP's as and ld should support weak symbols so I have decided
to test it.

--
// main.cc

extern "C" {
void hello() __attribute__ ((weak));
}

int main() {
hello();
return 0;
}
--

--
// hello.s
//   Adapted from "Hello World" Function Without
//   Unwind Directives from Intel Itanium Architecture
//   Assembly Language Reference Guide.

.section .rdata, "a", "progbits"
.align 8
.STRING1:
stringz "Hello World!!!\n"


.text
.global hello
.proc hello
hello: alloc loc2 = ar.pfs, 0, 4, 1, 0
mov loc3 = sp
mov loc1 = b0
addl out0 = @ltoff(.STRING1), gp
;;
ld8 out0 = [out0]
mov loc0 = gp
br.call.sptk.many b0 = printf
;;
mov gp = loc0
mov ar.pfs = loc2
mov b0 = loc1
mov sp = loc3
br.ret.sptk.many b0
.endp hello

.weak printf
.type printf, @function
--

--
$ aCC +w -g0 +O0 +d -c -o main.o main.cc
$ aCC +w -g0 +O0 +d -S -o main.s main.cc
$ as -o hello.o hello.s
$ aCC +w -g0 +O0 +d -o hello main.o hello.o
--

Now if I dump hello.o I get printf as a weak symbol as expected:

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #191 from dave.anglin at bell dot net ---
On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #190 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #189)
>> On 2020-02-16 4:21 p.m., John David Anglin wrote:
>>> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
 I have not had a chance to look through these in great detail, will do this
 later today, but some things I've noticed (not sure how important they are
 yet):
 - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
>>> That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need 
>>> to look at when
>>> GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is 
>>> done in assembler.
>> Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
>> calls.
> Hi Dave, I apologize for the delay in response, been a busy week so far.
> However I should be able to take a look at this further tomorrow.
>
> As per your recommendation I will try and find out when GNU as generates
> PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want
> in order to match aCC behavior, right?
I Peter, no problem.  I've been busy...

The problem seems to be that HP ld doesn't handle the PCREL21B relocation
correctly when it refers
to a weak function (i.e., it doesn't direct the call through the PLT).  At the
same time, weak references
don't seem to work with aCC.

As far as I can tell, the PCREL21B is generated by gas in gas/config/tc-ia64.c
at line 5919.  You could try
changing it to PCREL21BI to see if that helps (run binutils testsuite before
installing) but the change doesn't
seem correct.  We might need to generate a 32-bit branch to weak functions in
gcc.

It would be useful to find out why weak doesn't work with aCC.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #190 from Peter Bisroev  ---
(In reply to dave.anglin from comment #189)
> On 2020-02-16 4:21 p.m., John David Anglin wrote:
> > On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
> >> I have not had a chance to look through these in great detail, will do this
> >> later today, but some things I've noticed (not sure how important they are
> >> yet):
> >> - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
> > That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need 
> > to look at when
> > GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is 
> > done in assembler.
> Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
> calls.

Hi Dave, I apologize for the delay in response, been a busy week so far.
However I should be able to take a look at this further tomorrow.

As per your recommendation I will try and find out when GNU as generates
PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want
in order to match aCC behavior, right?

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #189 from dave.anglin at bell dot net ---
On 2020-02-16 4:21 p.m., John David Anglin wrote:
> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
>> I have not had a chance to look through these in great detail, will do this
>> later today, but some things I've noticed (not sure how important they are
>> yet):
>> - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
> That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need to 
> look at when
> GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is done 
> in assembler.
Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
calls.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #188 from dave.anglin at bell dot net ---
On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
> I have not had a chance to look through these in great detail, will do this
> later today, but some things I've noticed (not sure how important they are
> yet):
> - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need to
look at when
GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is done in
assembler.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #187 from Peter Bisroev  ---
(In reply to dave.anglin from comment #183)
> On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
> >
> > --- Comment #180 from Peter Bisroev  
> > ---
> > (In reply to dave.anglin from comment #177)
> >> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> >>> I have tried playing around with weak using aCC, however even though it 
> >>> accepts
> >>> both attribute and pragma (and complains if you misspell "weak"), both 
> >>> compiler
> >>> and linker seem to ignore it. But I might have made some mistake there, 
> >>> will
> >>> double check tonight.
> >> Did you look at .s output?  You could also test a simple program with a 
> >> weak
> >> function
> >> in two objects.
> > Sorry Dave, not 100% sure what kind of test you are talking about. Something
> > like this?
> > --
> > // func0.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 1;
> > }
> >
> > // main.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 10;
> > }
> >
> > int main(int argc, char * argv[]) {
> > return func0(argc);
> > }
> > --
> >
> Yes.  Does it link okay?

Hi Dave,

No it does not link, the error I get is "ld: Duplicate symbol "func0(int)" in
files test0.o and func0.o". However it links perfectly fine when compiled with
GCC.

I have attached the results of the test above and another basic C++ one using
an inline virtual method in attachment 47847. In there you will find three
directories for results with aCC, gcc 4-7-4 and gcc 4.7.4 built with
--enable-comdat.

Additionally, in each directory you will find a build.log of how exactly was
the test built, as well as *.objdump disassembly and other info and *.readelf
dumps.

I have not had a chance to look through these in great detail, will do this
later today, but some things I've noticed (not sure how important they are
yet):
- aCC seems to use PCREL21BI relocations while GCC PCREL21B.
- When objdumping C++ test1 for comdat enabled gcc, I get "objdump: test1
symbol number 48 references nonexistent SHT_SYMTAB_SHNDX section". 

Will come back to this a little later today.

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #186 from Peter Bisroev  ---
Created attachment 47847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47847=edit
Basic compiler tests v00

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #185 from Peter Bisroev  ---
(In reply to dave.anglin from comment #184)
> On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> > stage bootstrap went fine (running 'make check' now). Using that tried to
> > bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues
> > when linking cc1plus. For example:
> So, it looks like we have garbage collection for COMDAT functions but not
> for weak functions.

I finished running 'make check' tests for gcc 4.7.4 that was compiled with
--enable-comdat. I get exactly the same results as before, exactly the same
tests pass and fail that you have reviewed previously. So I guess we can say
this build works as good as the one without --enable-comdat.

The difference however is in reduced number of PCREL21B errors as show in my
comment before. Additionally I have tried compiling 8.3.0 with comdat enabled
4.7.4 (just like I tried with 4.9.4). In this case we also get a significantly
reduced number of PCREL21B errors. For example, originally for cc1plus, we went
from 569 errors to 58.

> I think we need to look at branch types - "br.call.sptk.many" versus
> "br.call.dptk.many".  I suspect using
> the latter would fix the PCREL21B relocation issues.
Sorry for my lack of knowledge here, would you be able to explain this a bit
more if you get a chance? I looked up IA-64 arch manual, and the diff between
these two branch types is that '.sptk' one uses static taken prediction
strategy and '.dptk' uses dynamic taken prediction strategy. The mechanics here
make sense to me but I am not sure I understand how they relate to the
relocation issue here.

Thanks!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #184 from dave.anglin at bell dot net ---
On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> stage bootstrap went fine (running 'make check' now). Using that tried to
> bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues
> when linking cc1plus. For example:
So, it looks like we have garbage collection for COMDAT functions but not for
weak functions.

I think we need to look at branch types - "br.call.sptk.many" versus
"br.call.dptk.many".  I suspect using
the latter would fix the PCREL21B relocation issues.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #183 from dave.anglin at bell dot net ---
On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #180 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #177)
>> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
>>> I have tried playing around with weak using aCC, however even though it 
>>> accepts
>>> both attribute and pragma (and complains if you misspell "weak"), both 
>>> compiler
>>> and linker seem to ignore it. But I might have made some mistake there, will
>>> double check tonight.
>> Did you look at .s output?  You could also test a simple program with a weak
>> function
>> in two objects.
> Sorry Dave, not 100% sure what kind of test you are talking about. Something
> like this?
> --
> // func0.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 1;
> }
>
> // main.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 10;
> }
>
> int main(int argc, char * argv[]) {
> return func0(argc);
> }
> --
>
Yes.  Does it link okay?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #182 from dave.anglin at bell dot net ---
On 2020-02-14 11:04 p.m., peter.bisroev at groundlabs dot com wrote:
> However just below this check, configure looks for GNU linker, and if one not
> found, disables COMDAT group support even though the second test passed.
>
> However `--enable-comdat` configure flag seems to override this behavior. I
> will try to recompile 4.7.4 with it to see what happens.
That's useful information.  I'll bet same applies to hppa64.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #181 from Peter Bisroev  ---
(In reply to Peter Bisroev from comment #179)
> (In reply to dave.anglin from comment #178)
> > The configure test didn't find support for COMDAT groups even though aCC and
> > HP ld
> > support them.  So, there's likely something incompatible with the default
> > support for COMDAT
> > groups.
> > 
> > Could you look at configure test and see why it fails?
> 
> Looking at configure in 4.9.4, there are two COMDAT related tests.
> 
> First test "checking assembler for .nsubspa comdat" fails when it tries to
> assemble:
> --
>   .SPACE $TEXT$
>   .NSUBSPA $CODE$,COMDAT
> --
> The errors are:
> --
> conftest.s:2: Error: unknown pseudo-op: `.nsubspa'
> conftest.s:1: Error: .space specifies non-absolute value
> --
> Looking through gas manual it looks like '.nsubspa' and that variation of
> '.space' are only supported for HPPA.
> 
> The second test "checking assembler for COMDAT group support (GNU as)"
> passes when it tries to assemble:
> --
>   .section .text,"axG",@progbits,.foo,comdat
> --
> 
> However just below this check, configure looks for GNU linker, and if one
> not found, disables COMDAT group support even though the second test passed.
> 
> However `--enable-comdat` configure flag seems to override this behavior. I
> will try to recompile 4.7.4 with it to see what happens.
> 
> Thanks!

So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
stage bootstrap went fine (running 'make check' now). Using that tried to
bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues
when linking cc1plus. For example:

With --enable-comdat:
ld: The value 0xfdfd38c0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x92 in section index 139 of file
libbackend.a[gcse.o]
ld: The value 0xfdfea070 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 402 of file
libbackend.a[gimple.o]


Without --enable-comdat:
ld: The value 0xfdf6d810 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 74 of file
libbackend.a[function.o]
ld: The value 0xfdeeb8b0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 79 of file
libbackend.a[function.o]
ld: The value 0xfdfd81f0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 60 of file
libbackend.a[gimple.o]
ld: The value 0xfdf562a0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 65 of file
libbackend.a[gimple.o]
ld: The value 0xfde4c890 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 207 of file
libbackend.a[gimple.o]
ld: The value 0xfde4ae90 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 212 of file
libbackend.a[gimple.o]
ld: The value 0xfdf81640 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file
libbackend.a[gimple-expr.o]
ld: The value 0xfde83ea0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 21 of file
libbackend.a[gimple-iterator.o]
ld: The value 0xfde82940 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 26 of file
libbackend.a[gimple-iterator.o]
ld: The value 0xfdf96310 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 85 of file
libbackend.a[gimple-fold.o]
ld: The value 0xfde8cde0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 106 of file
libbackend.a[gimple-fold.o]
ld: The value 0xfde8b440 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 111 of file
libbackend.a[gimple-fold.o]
ld: The value 0xfdec46b0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in section index 172 of file
libbackend.a[gimple-pretty-print.o]
ld: The value 0xfdff2690 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0xc2 in section index 91 of file
libbackend.a[ipa-inline-analysis.o]
ld: The value 0xfdfed180 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x172 in section index 96 of file
libbackend.a[ipa-inline-analysis.o]
ld: The value 0xfdfec950 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x842 in section index 96 of file
libbackend.a[ipa-inline-analysis.o]
ld: The value 0xfdfec8b0 does not fit when applying the relocation

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #180 from Peter Bisroev  ---
(In reply to dave.anglin from comment #177)
> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> > I have tried playing around with weak using aCC, however even though it 
> > accepts
> > both attribute and pragma (and complains if you misspell "weak"), both 
> > compiler
> > and linker seem to ignore it. But I might have made some mistake there, will
> > double check tonight.
> Did you look at .s output?  You could also test a simple program with a weak
> function
> in two objects.

Sorry Dave, not 100% sure what kind of test you are talking about. Something
like this?
--
// func0.cpp

int func0(int) __attribute__((weak));
int func0(int arg) {
return arg + 1;
}

// main.cpp

int func0(int) __attribute__((weak));
int func0(int arg) {
return arg + 10;
}

int main(int argc, char * argv[]) {
return func0(argc);
}
--

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #179 from Peter Bisroev  ---
(In reply to dave.anglin from comment #178)
> The configure test didn't find support for COMDAT groups even though aCC and
> HP ld
> support them.  So, there's likely something incompatible with the default
> support for COMDAT
> groups.
> 
> Could you look at configure test and see why it fails?

Looking at configure in 4.9.4, there are two COMDAT related tests.

First test "checking assembler for .nsubspa comdat" fails when it tries to
assemble:
--
  .SPACE $TEXT$
  .NSUBSPA $CODE$,COMDAT
--
The errors are:
--
conftest.s:2: Error: unknown pseudo-op: `.nsubspa'
conftest.s:1: Error: .space specifies non-absolute value
--
Looking through gas manual it looks like '.nsubspa' and that variation of
'.space' are only supported for HPPA.

The second test "checking assembler for COMDAT group support (GNU as)" passes
when it tries to assemble:
--
  .section .text,"axG",@progbits,.foo,comdat
--

However just below this check, configure looks for GNU linker, and if one not
found, disables COMDAT group support even though the second test passed.

However `--enable-comdat` configure flag seems to override this behavior. I
will try to recompile 4.7.4 with it to see what happens.

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #178 from dave.anglin at bell dot net ---
On 2020-02-13 6:04 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #176 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #174)
>> On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote:
>>> The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
>>> sections.  Probably, HP ld does support
>>> weak but it's unlikely there is support for linkonce sections.  See defines 
>>> in
>>> config/pa/som.h.  There we implimented
>>> one only support using the linker's COMDAT support.
>> Is HAVE_COMDAT_GROUP defined in auto-host.h?
> For both 4.9.4 and 8.3.0, gcc/auto-host.h contains only one reference to that:
> 
> /* Define 0/1 if your assembler and linker support COMDAT groups. */
> #ifndef USED_FOR_TARGET
> #define HAVE_COMDAT_GROUP 0
> #endif
> 
The configure test didn't find support for COMDAT groups even though aCC and HP
ld
support them.  So, there's likely something incompatible with the default
support for COMDAT
groups.

Could you look at configure test and see why it fails?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #177 from dave.anglin at bell dot net ---
On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> I have tried playing around with weak using aCC, however even though it 
> accepts
> both attribute and pragma (and complains if you misspell "weak"), both 
> compiler
> and linker seem to ignore it. But I might have made some mistake there, will
> double check tonight.
Did you look at .s output?  You could also test a simple program with a weak
function
in two objects.

My sense is the situation will be similar to hppa64-hpux11.  Weak is partially
supported in that
calls to a weak function resolve to a single instance.  However, undefined weak
is not really supported.
While the linker errors can be overridden, the dynamic linker will object to
applications with undefined
weak symbols.  We worked around this with a libgcc_stub.a library and a linker
script.  HP ld also
probably leaves all the instances of weak linkonce functions contributing to
bloat.