[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #138 from EML --- I think you need the patch from comment 63 as well
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #118 from EML --- (In reply to EML from comment #117) > I do appreciate someone else taking a look at this; I've had a lot of > changes at work, so this really took a back seat. And I don't have access to > the HP compiler to try things. I think this is an important step is in > comment 112: > > --- > Unfortunately, the above won't work directly because of the function name > encoding used on pa. Maybe you can look at aCC to see the assembly output > it generates to a call to a weak function. > --- > > > If we can figure out how aCC generates such weak and linkonce sections, we > should be able to make gcc do the same. > > As an aside, I have maxtsiz set to 1073741824 (per kctune) Going over my notes, we had the same text size problems and we adjusted it to be the maximum size
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #117 from EML --- I do appreciate someone else taking a look at this; I've had a lot of changes at work, so this really took a back seat. And I don't have access to the HP compiler to try things. I think this is an important step is in comment 112: --- Unfortunately, the above won't work directly because of the function name encoding used on pa. Maybe you can look at aCC to see the assembly output it generates to a call to a weak function. --- If we can figure out how aCC generates such weak and linkonce sections, we should be able to make gcc do the same. As an aside, I have maxtsiz set to 1073741824 (per kctune)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #102 from EML --- > Can 4.7.4 rebuild itself? It not, it's probably somewhat broken. Need to > figure out whether it > is good enough to build stage1 at -O0. I think the early faults at -O2/-O1 > should be looked at to see > if they are problems in current code or problems with 4.7.4. Generally, we According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 comment 6 "As far as I can tell all g++ versions available for download are broken, so you have to first download and build 4.7.4 or earlier, applying the same gcc/config/ia64/hpux.h as above. This version builds with gcc, not g++, so the bootstrap isn't a problem. Once you have a fixed 4.7.4 g++, you can then use that to bootstrap 4.9.2 - after again apply the hpux.h edit to the 4.9.2 sources." AFAIK, this is what we did. We did #undef MAKE_DECL_ONE_ONLY - rebuilt 4.7.2 with a downloaded 4.7.2, used that patched 4.7.2 to build 4.9.3 - again applying the "#undef MAKE_DECL_ONE_ONLY" to 4.9.3 So I'm starting from a position of having a possibly "bad" patch to start with if the undef is wrong as dave points out earlier
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #89 from EML --- If you back out #undef MAKE_DECL_ONE_ONLY doesn't g++ generate code that crashes the HP linker?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #83 from EML --- GCC configure has --disable-tls. It is not passed to MPFR as --disable-thread-safe that I can determine - well I tried it and it was not.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #81 from EML --- Correction My make line is: make STAGE1_CFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_CXXFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" CFLAGS_FOR_TARGET="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_TFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" BOOT_CFLAGS="-D_XOPEN_SOURCE_EXTENDED" LDFLAGS="-Wl,+allowdups" (allowdups to work around the duplicate symbols)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #80 from EML --- Starting from the top: I have applied my patch in comment 63 I have applied dave's patch in comment 72 I have applied #undef MAKE_DECL_ONE_ONLY patch My configure line is: ../gcc-8.3.0/configure --prefix=/usr/local/gcc8.3 --with-as=/usr/local/bin/as --without-gnu-ld --disable-nls --disable-libgomp --disable-libgcj --enable-shared --enable-threads=posix --with-gnu-as --with-ld=/usr/ccs/bin/ld --enable-languages=c,c++ My Make line is: make STAGE1_CFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_CXXFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" CFLAGS_FOR_TARGET="-O0 -g -D_XOPEN_SOURCE_EXTENDED" STAGE1_TFLAGS="-O0 -g -D_XOPEN_SOURCE_EXTENDED" BOOT_CFLAGS="-D_XOPEN_SOURCE_EXTENDED" My "system" compiler is GCC 4.9.3: Target: ia64-hp-hpux11.31 Configured with: ../gcc-4.9.3/configure --without-gnu-ld --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-shared --enable-threads=posix --disable-libgomp --enable-languages=c,c++ SED=/usr/local/bin/sed AWK=/usr/local/bin/gawk LDFLAGS=-lunwind AS=/usr/local/bin/as Thread model: posix gcc version 4.9.3 (GCC) During stage0 - MPFR will ICE in GCC4.9.3 due to TLS. You need to go into the MPFR directory and re-run the same configure line from config.log, but add --disable-thread-safe. The stage1 compiler will now build. Woot managed to build some version of gcc 8.3 During stage1 - MPFR will ICE in the stage1 xgcc also due to TLS. Again you need to --disable-thread-safe for MPFR (making sure to set CC correctly) The stage2 compiler will now build - hey it managed to build itself. The stage2 compiler will ICE while building ../../../../gcc-8.3.0/libstdc++-v3/libsupc++/array_type_info.cc well that was unexpected, since it did build itself once, but it failed apparently while building stage3.
[Bug middle-end/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #70 from EML --- Created attachment 46606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46606&action=edit islower pre-processed code (-E flag) Attached the pre-processed code from -E
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #66 from EML --- Created attachment 46596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46596&action=edit Test program using islower
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #65 from EML --- Yes, with that patch on 32bit, I'm not at the error described in comment 58. I will upload the .final file
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #63 from EML ---
Sorry, I didn't undo the patch completely.
I made a very simple change:
--- ia64.c.orig 2019-07-08 14:43:33 +
+++ ia64.c 2019-07-05 16:46:24 +
@@ -1137,7 +1137,7 @@
emit_insn (gen_load_fptr (dest, src));
else if (sdata_symbolic_operand (src, VOIDmode))
emit_insn (gen_load_gprel (dest, src));
- else if (local_symbolic_operand64 (src, VOIDmode))
+ else if (local_symbolic_operand64 (src, VOIDmode) && !TARGET_HPUX)
{
/* We want to use @gprel rather than @ltoff relocations for local
symbols:
Which I think has the same effect as disabling it in predicate. I'm happy with
either approach.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #61 from EML --- Sorry, perhaps I have confused the situation. I have already patched my compiler to remove the gprel in both 32 and 64. That gprel patch breaks things in both 32 and 64. I'm reasonably convinced the patch is wrong for HP-UX, so I'm moving forward with that assumption. When I remove that gprel patch - the 64bit stage 1 compiler is able to compile hello world, islower, as well as all the other "conftest" programs successfully. It can compile libstdc++ as well (some duplicate symbols however). However, the 32-bit compiler does not work which I believe to be a pointer swizzle issue. I've confirmed the binary is 32bit as follows: -bash-5.0$ file islower islower:ELF-32 executable object file - IA64 -bash-5.0$ elfdump -f islower islower: *** ELF Header *** Class: ELF-32 Data:Big-endian OS: HP-UX ABI Version: 1 Type:EXEC Machine: IPF Version: 1 Entry Addr: 0x40008b0 Program Hdr Offset: 0x34 Section Hdr Offset: 0x1104c Flags: trapnil Flags: big-endian PSR Flags: IA-64 Elf Hdr Size:0x34 Program Hdr Size:0x20 Program Hdr Number: 12 Section Hdr Size:0x28 Section Hdr Number: 43 Section Hdr String Idx: 42
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #59 from EML --- Created attachment 46575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46575&action=edit islower 32 bit test assembler
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #58 from EML ---
32 Bit:
Second Test Program (derived from a crashing conftest)
#include
int
main ()
{
int j = 0;
j = islower(0);
printf("j is: %d\n", j);
return 0;
}
[.LCFI2:]
mov r35 = r1
.body
.loc 1 6 7
;;
st4 [r34] = r0
.loc 1 8 18
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
.loc 1 8 16
;;
cmp.eq p6, p7 = 0, r14
(p6) br.cond.dptk .L2
.loc 1 8 35 discriminator 1
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
;;
ld4 r14 = [r14] <<<--- crashes here. Missing addp4 r14 = 0,r14
.loc 1 8 16 discriminator 1
;;
and r14 = 64, r14
br .L3
;;
If you insert the addp4 r14 = 0,r14 before that command (like gcc 4.9.3 does),
the program compiles and runs correctly
I'll upload the .s for "IsLower.c" - it's definitely a 32 bit executable, so
the correct options are being passed around.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #55 from EML --- Doing some more testing on my "gprel unfixed fix" 32-bit gcc, I found out that it seems to be missing the 32-bit pointer swizzling needed to make 32bit executables on 64-bit IA-64. The test program assembler is missing an addp4 instruction - when I add in this instruction, my second test program also works. This is defined as "ptr_extend" in the ia64.md. I don't know what it doesn't seeem to be there, but it is definitely missing. So I thought I would try to make a 64-bit GCC and then compile everything 64-bit just to see if that would work, since it doesn't need swizzling. This still has the "gprel unfixed fix" though. So far it has made it past all the conftest in the c++ library configure (so already much further) and it has compiled libstdc++. There were, unfortunately, some linker problems with "duplicate symbols" which seem to have been fatal. However, this is much closer now on 64-bit
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #52 from EML --- Note, regardless of reverting the gprel patch, GCC 8 puts the data in .rodata. However, doesn't gcc 4.9.x do the same thing, it just moves it to GOT with ltoffx? .file "foo.c" .pred.safe_across_calls p1-p5,p16-p63 .section.text, "ax", "progbits" .Ltext0: .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" Isn't LC0 here also in .rodata? objdump -h -s fooContents of section .rodata: 40007f8 48656c6c 6f732057 6f726c64 00Hellos World. So gcc 4.9.x also puts the string into rodata? (Not sure I'm reading all the files correctly, so perhaps I'm just reading it all wrong)
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #44 from EML ---
The aforementioned gprel patch I think is incorrect on HPUX, given this in
ia64.c
/* For HPUX, it is illegal to have relocations in shared segments. */
static int
ia64_hpux_reloc_rw_mask (void)
{
return 3;
}
Therefore, if I understand correctly, HP requires all relocations, even to
local data, to be dynamic. And I understand the entire purpose of the earlier
patch is in direct contradiction to this.
Removing this (by adding a !TARGET_HPUX) to ia64.c results in a little
progress.
I can now compile and run Hello World. Woot.
However, I have likely reached the same problem as "Word" - the EOF conftest in
libstdc++v3 fails.
(conftest actually crashed a couple times, the latest is for EOF)
So Hello World runs, but other relatively straightforward programs do not.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #37 from EML --- I wonder if is this patch is related: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02193.html "Before the patch generated code uses .GOT entry: addl r14 = @ltoffx(a#), r1 ld8.mov r14 = [r14], a# After the patch generated code uses static gprel relocation: movl r14 = @gprel(a#) add r14 = r1, r14 "
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #33 from EML --- Could the problem be with "AS"? Maybe that assembler is technically ok, but AS is generating bad machine code?
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #31 from EML --- (In reply to dave.anglin from comment #26) > On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > > If I replace those 3 lines and run the assembler+linker by hand - the > > non-working foo.s will run correctly > So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined. The configure > script is > likely not detecting this assembler capability correctly. > > Are you using bash shell? If not, I suggest that you use it instead of HP > shell. This macro only seems to control whether you use ltoffx or ltoff. I can confirm I am using bash, and #define HAVE_AS_LTOFFX_LDXMOV_RELOCS 1 in gcc/config.h I also added in an #error to the code to make sure. It is definitely set.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #25 from EML ---
I have applied the patch and tried your other suggestions, still the stage1
compiler has the same problems generating executables.
In analyzing the intermediate files between working (gcc 4.93) and not
(bootstrap 8.3), the intermediate files seem similar until the "mach" stage
The problem seems to be in out the compiler decides to reference a string in
the source.
My program is:
#include
int main()
{
printf("Hellos World\n");
return 0;
}
The generated .s file for Working does this:
.LC0:
stringz "Hellos World"
addl r36 = @ltoffx(.LC0), r1
;;
ld8.mov r36 = [r36], .LC0
The non-working .s file does this:
.LC0:
stringz "Hellos World"
movl r36 = @gprel(.LC0)
;;
add r36 = r1, r36
If I replace those 3 lines and run the assembler+linker by hand - the
non-working foo.s will run correctly
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #22 from EML --- Thanks for the hints and options on IA64, I used the GNU AS (2.32), but the HP LD (ld: 92453-07 linker ld HP Itanium(R) B.12.65 IPF/IPF) Well, this is historically how you do it, I believe you need to use the HP linker as the dynamic loader won't work with the GNU linker. I have some tests I want to run. - Note, I started with 8.3.0 because I understood (and you have confirmed) that this ran on Debian ia64. So generally the assembler must know how to put together the instructions properly for the CPU. My configure line was: $ ../gcc-8.3.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc8.3 --with-as=/usr/local/bin/as --without-gnu-ld --disable-nls --disable-libgomp --disable-libgcj --enable-shared --enable-threads=posix CC=gcc -mlp64 CXX=g++ -mlp64 (Note, the CC and CXX are for getting it build in 64bit - leaving that off will generate a 32bit version) Yes, this all is somewhat unrelated to the original bug report - probably should be moved to some other report.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #19 from EML --- Dave, that link is to Debian HPPA - not IA64 (I cannot find Debian IA64 working from that site) Working assembler for hello world program: => 0x4c90 <+0>: [MII] alloc r33=ar.pfs,5,4,0 0x4c91 <+1>: mov r34=r12 0x4c92 <+2>: mov r32=b0 0x4ca0 <+16>:[MII] mov r35=r1 0x4ca1 <+17>:addl r36=-16,r1;; 0x4ca2 <+18>:nop.i 0x0 Bad assembler: => 0x4c00 <+0>: [MII] alloc r33=ar.pfs,5,4,0 0x4c01 <+1>: mov r34=r12 0x4c02 <+2>: mov r32=b0 0x4c10 <+16>:[MLX] cmp.lt p0,p0=r0,r0 <<< Illegal Instruction 0x4c11 <+17>:movl r36=0x42c0180;; 0x4c20 <+32>:[MIB] add r36=r1,r36 0x4c21 <+33>:nop.i 0x0
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 EML changed: What|Removed |Added CC||elowe at elowe dot com --- Comment #17 from EML --- I have a working 4.9.3 from following directions in this bug and others - it does appear to work and generates executables that execute correctly So I thought I would attempt to use it to bootstrap GCC 8.3.0 I can compile the stage1 compiler xgcc - however, the stage1 compiler generates executables the immediately crash. It will happily build libgcc, but cannot generate correct executables and will not finish the "configure" step for libstdc++ (which attempts to compile and run various conftest.c programs) - these are pretty simple programs. I also tried to compile a simple "Hello World" program, but it crashes immediately when run. Note that in certain cases, the MPFR library won't build depending on the CFLAGS used (in particular the default -g -O2), this is due to problems with thread local storage. You can work around this by configuring MPFR with --disable-thread-safe I also tried configuring gcc with --disable-tls (there was no change in end behaviour though I have tried various options for building stage1 (STAGE1_CFLAGS, STAGE1_CXXFLAGS) default (just run make - this builds with -g -O2) -g -O0 -g -O0 -D_XOPEN_SOURCE_EXTENSION I also managed to build a 64bit version of the stage1 compiler. This also cannot generate executable code In short, gcc 8.3, whether 32 or 64, when bootstrapped with gcc 4.9.3 cannot produce correct executables.
