[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=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 #64 from dave.anglin at bell dot net ---
On 2019-07-08 2:51 p.m., elowe at elowe dot com wrote:
> 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.
Okay, I assume we are now at the problem in comment #58. Would you upload the
final RTL
dump for "IsLower.c" ("-da" opttion will generate)? It would also be useful to
find the change
which introduced the regression for "IsLower.c".
You could post the above patch with a ChangeLog to gcc-patches. It's small
enough that a FSF
assignment shouldn't be needed.
[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 #62 from dave.anglin at bell dot net --- On 2019-07-08 12:22 p.m., elowe at elowe dot com wrote: > 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). I doubt removing the gprel patch is an acceptable solution as it fixed a bug on Linux. A better solution is to disable the local_symbolic_operand64 predicate on hpux. That should fix hello world. Then, we can move to other issues.
[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 #60 from dave.anglin at bell dot net ---
On 2019-07-08 12:07 a.m., elowe at elowe dot com wrote:
> If you insert the addp4 r14 = 0,r14 before that command (like gcc 4.9.3 does),
> the program compiles and runs correctly
It would be useful to do a regression search to determine the revision that
changed the above behavior.
>
> I'll upload the .s for "IsLower.c" - it's definitely a 32 bit executable, so
> the correct options are being passed around.
I'm not sure why you say the .s for "IsLower.c" is a 32-bit executable and that
the correct options are
being passed around. You haven't shown the assembler or linker commands used
to create the executable.
For applications like the hello world program, there is very little difference
between the 32 and 64-bit
assembler output generated by gcc (cc1).
I'm still trying to understand the problem with the gprel relocation. It seems
to work in 64-bit but not
in 32-bit. While there might be issues with assembler or linker, you are
probably correct that we need
to swizzle pointer with ILP32.
You could try adding something like the following to this hunk after the
emit_insn() line:
else if (local_symbolic_operand64 (src, VOIDmode))
{
/* We want to use @gprel rather than @ltoff relocations for local
symbols:
- @gprel does not require dynamic linker
- and does not use .sdata section
https://gcc.gnu.org/bugzilla/60465 */
emit_insn (gen_load_gprel64 (dest, src));
}
if (TARGET_ILP32)
{
rtx tmp;
tmp = gen_rtx_REG_offset (dest, ptr_mode, REGNO (dest),
byte_lowpart_offset (ptr_mode, GET_MODE
(dest)));
REG_POINTER (tmp) = 1;
emit_insn (gen_ptr_extend (dest, tmp));
}
Alternatively, you could try disabling the local_symbolic_operand64 predicate
in predicates.md:
(define_predicate "local_symbolic_operand64"
(match_code "symbol_ref,const")
{
switch (GET_CODE (op))
{
Just add
if (TARGET_ILP32)
return false;
before switch statement.
[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=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 #57 from dave.anglin at bell dot net --- On 2019-07-05 7:57 p.m., elowe at elowe dot com wrote: > 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. It's not clear to me that this is necessary. The movl instruction loads a 64-bit immediate. In this case, it should be the offset between gp (r1) and .LC0. At the br.call.sptk.many b0 instruction, r36 should contain the address of .LC0. You should be able to see this with gdb. It should be possible to adjust the offset to account for any difference between 32 and 64-bit runtimes. If the offset value is wrong, I think we have a binutils issue. Maybe -milp32 is not being passed on hpux to assembler. I don't see any difference between 32-bit and 64-bit code, or between hpux and linux.
[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 #56 from dave.anglin at bell dot net --- On 2019-07-05 7:57 p.m., elowe at elowe dot com wrote: > 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. Could be. The default hpux compiler generates ILP32 code and it's supposed to be big-endian. Could you compile hello world with "-c" option and run "objdump -r" on resulting object? Pointers are 32-bit in the ILP32 model. I think we should have GPREL32MSB relocation but maybe we have 64-bit reloc. https://refspecs.linuxfoundation.org/elf/IA64-SysV-psABI.pdf
[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 #54 from The Written Word --- (In reply to EML from comment #52) > objdump -h -s foo > Contents 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) I'm seeing the string in .rodata as well regardless of compiler version: $ gobjdump -h -s -j .rodata a.out a.out: file format elf32-ia64-hpux-big Sections: Idx Name Size VMA LMA File off Algn 10 .rodata 000d 040007c8 040007c8 07c8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA Contents of section .rodata: 40007c8 48656c6c 6f732057 6f726c64 00Hellos World. And the HP C compiler has it in .rodata as well: $ cc a.out $ gobjdump -h -s -j .rodata a.out a.out: file format elf32-ia64-hpux-big Sections: Idx Name Size VMA LMA File off Algn 11 .rodata 000e 040007c0 040007c0 07c0 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA Contents of section .rodata: 40007c0 48656c6c 6f732057 6f726c64 0a00 Hellos World..
[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 #53 from The Written Word --- (In reply to EML from comment #52) > 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) gcc-4.4.6 does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.6.4 does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.7.4 does: .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.8.5 does: .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-4.9.4 (with gprel patch reverted) does: .file "hello.c" .pred.safe_across_calls p1-p5,p16-p63 .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16 gcc-8.3.0 (first stage) does: .section.text, "ax", "progbits" .section.rodata,"a","progbits" .align 8 .LC0: stringz "Hellos World" .section.text, "ax", "progbits" .align 16
[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 #51 from The Written Word
---
(In reply to dave.anglin from comment #50)
> On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
> I'm still puzzled why .LC0 ends up in .rodata.
>
> (insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
> (minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] *.LC0>)
> (reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
> (nil))
This is a diff of the RTL between two gcc-8.3.0 versions, one with PR60465
reverted and one without:
--- without-PR60465/hello.c.313r.dfinish2019-07-05 20:37:38 +
+++ with-PR60465/hello.c.313r.dfinish2019-07-05 20:26:13 +
@@ -31,16 +31,16 @@
(note 22 21 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 22 30 2 NOTE_INSN_FUNCTION_BEG)
(insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
-(plus:DI (high:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ))
-(reg:DI 1 r1))) "hello.c":5 110 {*load_symptr_high}
+(minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
+(reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
(nil))
(insn 34 30 31 2 (unspec_volatile [
(const_int 3 [0x3])
] UNSPECV_INSN_GROUP_BARRIER) "hello.c":5 364 {insn_group_barrier}
(nil))
(insn 31 34 32 2 (set (reg:DI 120 out0 [+-4 ])
-(lo_sum:DI (mem/u/c:DI (reg:DI 120 out0 [+-4 ]) [0 S8 A64])
-(symbol_ref/f:SI ("*.LC0") [flags 0x2] ))) "hello.c":5 111 {*load_symptr_low}
+(plus:DI (reg:DI 1 r1)
+(reg:DI 120 out0 [+-4 ]))) "hello.c":5 206 {adddi3}
(nil))
(call_insn 32 31 33 2 (parallel [
(set (reg:SI 8 r8)
[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 #50 from dave.anglin at bell dot net ---
On 2019-07-05 4:28 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
I'm still puzzled why .LC0 ends up in .rodata.
(insn 30 2 34 2 (set (reg:DI 120 out0 [+-4 ])
(minus:DI (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
(reg:DI 1 r1))) "hello.c":5 108 {*gprel64_offset}
(nil))
[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 #49 from The Written Word --- Created attachment 46565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46565=edit hello.c compiled with -da /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include -g -da hello.c
[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 #48 from The Written Word --- Created attachment 46564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46564=edit hello.s assembly output of hello.c /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include -S hello.c
[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 #47 from The Written Word --- Created attachment 46563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46563=edit Hello.c test program
[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 #46 from The Written Word --- (In reply to dave.anglin from comment #45) > > You could dump the RTL by adding "-da" to the compile options. Then, you > could upload the "final" file. I am uploading hello.c, hello.s, and hello.c.313r.dfinish.
[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 #45 from dave.anglin at bell dot net ---
On 2019-07-05 3:34 p.m., elowe at elowe dot com wrote:
> 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 think this is wrong, but this is getting closer to a fix. Would like to see
the .s output.
We have in varasm.c:
section *
default_select_rtx_section (machine_mode mode ATTRIBUTE_UNUSED,
rtx x,
unsigned HOST_WIDE_INT align ATTRIBUTE_UNUSED)
{
if (compute_reloc_for_rtx (x) & targetm.asm_out.reloc_rw_mask ())
return data_section;
else
return readonly_data_section;
}
As you can see, when a bit is set in the reloc_rw_mask and the rtx requires
relocation,
the rtx is output in the data section.
I think the problem is the rtx is actually output in .rodata and the HP dynamic
linker
can't do this relocation in .rodata.
The ia64 target is actually using default_elf_select_rtx_section:
section *
default_elf_select_rtx_section (machine_mode mode, rtx x,
unsigned HOST_WIDE_INT align)
{
int reloc = compute_reloc_for_rtx (x);
/* ??? Handle small data here somehow. */
if (reloc & targetm.asm_out.reloc_rw_mask ())
{
if (reloc == 1)
return get_named_section (NULL, ".data.rel.ro.local", 1);
else
return get_named_section (NULL, ".data.rel.ro", 3);
}
return mergeable_constant_section (mode, align, 0);
}
It seems to me compute_reloc_for_rtx() must be doing the wrong thing for the
rtx
(i.e., returning 0).
You could dump the RTL by adding "-da" to the compile options. Then, you could
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 #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 #43 from The Written Word --- (In reply to dave.anglin from comment #42) > On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote: > > I can now duplicate what you're seeing: > > $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s > > --- gcc-4.9.3/hello.s2019-07-05 04:55:49 + > > +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 + > > @@ -1,5 +1,6 @@ > > .file "hello.c" > > .pred.safe_across_calls p1-p5,p16-p63 > > + .section.text, "ax", "progbits" > > .section.rodata,"a","progbits" > With 8.3.0 assembly output, what happens if you change ".rodata" to ".data"? > It may > be that hpux can't handle gprel in .rodata. > > The other possibility is gp is wrong. > > .align 8 > > .LC0: > > @@ -19,9 +20,9 @@ > > mov r32 = b0 > > mov r35 = r1 > > .body > > - addl r36 = @ltoffx(.LC0), r1 > > + movl r36 = @gprel(.LC0) > > ;; > > - ld8.mov r36 = [r36], .LC0 > > + add r36 = r1, r36 > > br.call.sptk.many b0 = puts# > > mov r1 = r35 > > mov r14 = r0 $ /opt/build/china/gcc-8.3.0/.obj-/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj-/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31 /lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include hello.s hello.s: Assembler messages: hello.s:4: Warning: ignoring changed section attributes for .data $ ./a.out `
[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 #42 from dave.anglin at bell dot net --- On 2019-07-05 12:57 a.m., bugzilla-gcc at thewrittenword dot com wrote: > I can now duplicate what you're seeing: > $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s > --- gcc-4.9.3/hello.s2019-07-05 04:55:49 + > +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 + > @@ -1,5 +1,6 @@ > .file "hello.c" > .pred.safe_across_calls p1-p5,p16-p63 > + .section.text, "ax", "progbits" > .section.rodata,"a","progbits" With 8.3.0 assembly output, what happens if you change ".rodata" to ".data"? It may be that hpux can't handle gprel in .rodata. The other possibility is gp is wrong. > .align 8 > .LC0: > @@ -19,9 +20,9 @@ > mov r32 = b0 > mov r35 = r1 > .body > - addl r36 = @ltoffx(.LC0), r1 > + movl r36 = @gprel(.LC0) > ;; > - ld8.mov r36 = [r36], .LC0 > + add r36 = r1, r36 > br.call.sptk.many b0 = puts# > mov r1 = r35 > mov r14 = r0
[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 #41 from The Written Word
---
(In reply to The Written Word from comment #39)
> (In reply to EML from comment #25)
> > 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
>
> I can now duplicate what you're seeing:
> $ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
> --- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
> +++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
> @@ -1,5 +1,6 @@
> .file "hello.c"
> .pred.safe_across_calls p1-p5,p16-p63
> + .section.text, "ax", "progbits"
> .section.rodata,"a","progbits"
> .align 8
> .LC0:
> @@ -19,9 +20,9 @@
> mov r32 = b0
> mov r35 = r1
> .body
> - addl r36 = @ltoffx(.LC0), r1
> + movl r36 = @gprel(.LC0)
> ;;
> - ld8.mov r36 = [r36], .LC0
> + add r36 = r1, r36
> br.call.sptk.many b0 = puts#
> mov r1 = r35
> mov r14 = r0
>
> $ grep LTOFF /gcc/config.status
> D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"
If I revert the patch for PR60465 (added as an attachment), then looking at the
difference between gcc-4.9.4/hello.s and gcc-8.3.0/hello.s gives:
--- gcc-4.9.4/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 11:25:09 +
@@ -1,5 +1,6 @@
.file "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+ .section.text, "ax", "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
Reverting the patch doesn't bring us any closer to the segfault in libstdc++-v3
though.
[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 #40 from The Written Word --- Created attachment 46560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46560=edit Revert PR60465
[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 #39 from The Written Word
---
(In reply to EML from comment #25)
> 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
I can now duplicate what you're seeing:
$ diff -u gcc-4.9.4/hello.s gcc-8.3.0/hello.s
--- gcc-4.9.3/hello.s2019-07-05 04:55:49 +
+++ gcc-8.3.0/hello.s 2019-07-05 04:55:44 +
@@ -1,5 +1,6 @@
.file "hello.c"
.pred.safe_across_calls p1-p5,p16-p63
+ .section.text, "ax", "progbits"
.section.rodata,"a","progbits"
.align 8
.LC0:
@@ -19,9 +20,9 @@
mov r32 = b0
mov r35 = r1
.body
- addl r36 = @ltoffx(.LC0), r1
+ movl r36 = @gprel(.LC0)
;;
- ld8.mov r36 = [r36], .LC0
+ add r36 = r1, r36
br.call.sptk.many b0 = puts#
mov r1 = r35
mov r14 = r0
$ grep LTOFF /gcc/config.status
D["HAVE_AS_LTOFFX_LDXMOV_RELOCS"]=" 1"
[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 #38 from The Written Word --- I rebuilt 8.3.0 with minimal patches and am seeing the same failure as before. From /ia64-hp-hpux11.31/libstdc++-v3/config.log: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure: line 1940: 18830 Segmentation fault (core dumped) ./conftest$ac_exeext If I compile the conftest.c program between gcc-4.9.4 and the 8.3.0 stage 1 compiler: --- gcc-4.9.4/conftest.s 2019-07-05 04:50:23 + +++ /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/conftest.s 2019-07-05 04:50:13 + @@ -27,42 +27,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L3 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L4 br .L5 ;; @@ -73,33 +57,15 @@ mov r14 = r8 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L5 .L4: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L5: addl r14 = @ltoffx(__SB_masks#), r1 @@ -108,42 +74,26 @@ ;; ld4 r14 = [r14] ;; - addp4 r14 = 0,r14 - ;; cmp.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L7 addl r14 = @ltoffx(__SB_masks#), r1 ;; ld8.mov r14 = [r14], __SB_masks# ;; ld4 r14 = [r14] - ;; - addp4 r14 = 0,r14 ld4 r15 = [r34] ;; shladd r15 = r15, 2, r0 ;; add r14 = r15, r14 ;; - addp4 r14 = 0,r14 + addp4 r14 = r14, r0 ;; ld4 r14 = [r14] ;; and r14 = 64, r14 ;; cmp4.eq p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L8 br .L9 ;; @@ -154,33 +104,15 @@ mov r14 = r8 ;; cmp4.ne p6, p7 = 0, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 .L8: ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L9 ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 122, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L6 .L9: ld4 r36 = [r34] @@ -190,22 +122,10 @@ ld4 r14 = [r34] ;; cmp4.ge p6, p7 = 96, r14 - ;; - (p6) adds r14 = 1, r0 - ;; - (p7) adds r14 = 0, r0 - ;; - tbit.nz p6, p7 = r14, 0 (p6) br.cond.dptk .L10 ld4 r14 = [r34] ;; cmp4.lt p6, p7 = 122, 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 #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 #36 from dave.anglin at bell dot net --- On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > The non-working .s file does this: > > .LC0: > stringz "Hellos World" > > > > movl r36 = @gprel(.LC0) > ;; > add r36 = r1, r36 It seems to me that the gprel instruction would fault if the gp (r1) isn't properly initialized correctly before main is started.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #35 from Jim Wilson --- I never had access to ia64 hpux unfortunately. I did ask them for a copy once, but they couldn't figure out why I wanted it, and so they wouldn't give it to me. Steve Ellcey was working for HP at the time and maintaining the ia64-hpux support. You could try asking him. I think the ia64-hpux support was always poor. Too many things done differently than ia64-linux, requiring inconvenient hacks on our side to make our tools work on their system. I don't know if the binutils support was ever usable. The gcc support was usable at one time, but I don't know the details.
[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 #34 from dave.anglin at bell dot net --- On 2019-07-04 4:43 p.m., elowe at elowe dot com wrote: > Could the problem be with "AS"? > > Maybe that assembler is technically ok, but AS is generating bad machine code? That's easy to check. You can dump the assembler output generated by gcc with "-S" option. I'm pretty sure the faulting gprel instruction is from gcc. You can compare .o files generated by new and working compiles with cmp. You can disassemble .o and executables with "objdump -d". You can link .o file generated with new compiler with old compiler. You can also test using HP and GNU tools. Use "gcc -save-temps -v" to capture intermediate files and commands. I think the issue is more likely with ld than as.
[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 #32 from dave.anglin at bell dot net --- On 2019-07-03 9:08 p.m., elowe at elowe dot com wrote: > 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 My lack of knowledge about ia64 is showing... A ia64-hpux cross from hppa-linux generates the same failing code for the hello world program. Thus, I don't think this is a bootstrap compiler problem. It should be possible to bisect tree and find the change which broke ia64. gcc -v should show the configure options used to build original working gcc.
[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 #30 from The Written Word --- (In reply to dave.anglin from comment #29) > On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote: > > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc > > -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ > > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i > > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include > > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 > > -g > > conftest.c >&5 > > configure:8057: $? = 0 > > configure:8057: ./conftest > > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 > > Memoryfault(coredum > > p) > > The configure test needs to be debugged in the same manner as the "hello > world" program. Yeah, we've already looked at the difference between 4.9.4/8.3.0 assembly but want to rebuild 8.3.0 with as few patches as possible to ensure the issue isn't some patch we've introduced.
[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 #29 from dave.anglin at bell dot net --- On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote: > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc > -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g > conftest.c >&5 > configure:8057: $? = 0 > configure:8057: ./conftest > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 > Memoryfault(coredum > p) The configure test needs to be debugged in the same manner as the "hello world" program.
[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 #28 from The Written Word --- (In reply to EML from comment #17) > 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 We are building GCC against mpfr-3.1.6 but MPFR wasn't a difficult build on HP-UX/IA. We are building with the HP C compiler though. The MPFR testsuite passed all but one test which was a PASS. And, ./configure shows -DMPFR_USE_THREAD_SAFE=1.
[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 #27 from The Written Word --- (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. It's set to 1 for us. We're getting a segfault while building libstdc++-v3 with 8.3.0: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 Memoryfault(coredum p) configure:8057: $? = 139 Using the stage 1 8.3.0 compiler, we can get a simple "hello world" program to compile.
[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 #26 from dave.anglin at bell dot net --- 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.
[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 #24 from The Written Word --- (In reply to EML from comment #22) > 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) Do you have this patch applied as you're using binutils 2.32? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338?
[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 #23 from dave.anglin at bell dot net --- On 2019-07-01 3:12 p.m., elowe at elowe dot com wrote: > 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 I'm going to suggest that you add "--with-gnu-as" and "--with-ld=/usr/ccs/bin/ld" options. I might have path for HP ld wrong. Also, make sure CC and CXX are quoted. There is a dependence in ia64.c, etc, on the assembler dialect (TARGET_GNU_AS). There's also a dependence on TARGET_HPUX_LD.
[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 #21 from dave.anglin at bell dot net --- On 2019-07-01 12:53 p.m., elowe at elowe dot com wrote: > 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 I can't help with ia64 instructions. This looks like a different bug from the original report. Are you using GNU or HP tools? Did you specify "--with-gnu-as" and/or "--with-gnu-ld" in your configure options? On hppa, the HP assembler is not recommended. I'm a bit surprised that the illegal instruction wasn't an assembler error. I would switch to testing trunk as any fix will be applied to it first. If you add "-da" to the compile options for the hello world program, you should see the RTL generated in various compilation stages. Ultimately, the final stage is output as assembler. Comparing your working compiler to the broken compiler may give clues as to what is broken and when it occurs. "-save-temps -v" is another useful option. It saves intermediate files and shows intermediate compilation commands.
[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 #20 from dave.anglin at bell dot net --- On 2019-07-01 12:53 p.m., elowe at elowe dot com wrote: > Dave, that link is to Debian HPPA - not IA64 (I cannot find Debian IA64 > working > from that site) Sorry, here is ia64 link: https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ia64=8.3.0-7=1556533635=0
[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 --- Comment #18 from dave.anglin at bell dot net --- On 2019-06-30 6:19 p.m., elowe at elowe dot com wrote: > 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. The only way to make progress is to debug the above problems. The issue is likely hp-ux specific as gcc-8 builds successfully on Debian linux: https://buildd.debian.org/status/fetch.php?pkg=gcc-8=hppa=8.3.0-7=1556503087=0
[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.
[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 #16 from dave.anglin at bell dot net --- On 2019-05-22 5:23 p.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #15 from The Written Word com> --- > (In reply to dave.anglin from comment #12) >> It might help to compile stage1 with -O2 or -Os. > How does one do this? After ./configure, "gmake CFLAGS=-Os"? BOOT_CFLAGS > applies to stage2/3. STAGE1_CFLAGS and STAGE1_CXXFLAG used to work: make STAGE1_CFLAGS="-O2 -g" STAGE1_CXXFLAGS="-O2 -g" -j2 bootstrap
[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 #15 from The Written Word --- (In reply to dave.anglin from comment #12) > It might help to compile stage1 with -O2 or -Os. How does one do this? After ./configure, "gmake CFLAGS=-Os"? BOOT_CFLAGS applies to stage2/3.
[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 #13 from The Written Word --- (In reply to dave.anglin from comment #12) > It might help to compile stage1 with -O2 or -Os. This might reduce offset > and get a newer version > of gcc to build. gcc-8.3.0 seems to have built okay on Debian. gcc-9 so > far has failed to build on ia64. Ok, I'll try. I'll try to reach out to the Debian/ia maintainers again.
[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 #14 from The Written Word --- (In reply to dave.anglin from comment #10) > I don't know the status of Jim Wilson who is listed as ia64 maintainer. We reached out to Jim Wilson in 2016 and got a reply back. He no longer has access to any ia64 machines.
[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 #12 from dave.anglin at bell dot net --- On 2019-05-07 9:32 a.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #11 from The Written Word com> --- > (In reply to dave.anglin from comment #10) >> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote: >>> Dave, are you aware of anybody testing ia64-hpux? >>> Should it be deprecated if nobody is maintaining it? >> I don't have or access to a ia64 box. >> >> I don't know the status of Jim Wilson who is listed as ia64 maintainer. >> >> Albert Chin is the only person that I know who >> might be actively using it. >> >> My access to the hppa box that I use for hppa-hpux support requires support >> from NRC Canada but >> all colleagues there have retired. It was down for a few weeks until >> yesterday when I got a network person >> to reboot it. >> >> So, maybe it's time to deprecate hpux. I'm still working on hppa-linux. > We are still using it but haven't been able to build anything post 4.9.4. We > tried to find someone to pay to bring this port up-to-date but had no success. > Open to other suggestions but deprecating it might be the only way forward. As I said before, I can't accept US contracts because of HST tax implications. I can only accept Canadian source income. It might help to compile stage1 with -O2 or -Os. This might reduce offset and get a newer version of gcc to build. gcc-8.3.0 seems to have built okay on Debian. gcc-9 so far has failed to build on ia64.
[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 #11 from The Written Word --- (In reply to dave.anglin from comment #10) > On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote: > > Dave, are you aware of anybody testing ia64-hpux? > > Should it be deprecated if nobody is maintaining it? > I don't have or access to a ia64 box. > > I don't know the status of Jim Wilson who is listed as ia64 maintainer. > > Albert Chin is the only person that I know who > might be actively using it. > > My access to the hppa box that I use for hppa-hpux support requires support > from NRC Canada but > all colleagues there have retired. It was down for a few weeks until > yesterday when I got a network person > to reboot it. > > So, maybe it's time to deprecate hpux. I'm still working on hppa-linux. We are still using it but haven't been able to build anything post 4.9.4. We tried to find someone to pay to bring this port up-to-date but had no success. Open to other suggestions but deprecating it might be the only way forward.
[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 #10 from dave.anglin at bell dot net --- On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote: > Dave, are you aware of anybody testing ia64-hpux? > Should it be deprecated if nobody is maintaining it? I don't have or access to a ia64 box. I don't know the status of Jim Wilson who is listed as ia64 maintainer. Albert Chin is the only person that I know who might be actively using it. My access to the hppa box that I use for hppa-hpux support requires support from NRC Canada but all colleagues there have retired. It was down for a few weeks until yesterday when I got a network person to reboot it. So, maybe it's time to deprecate hpux. I'm still working on hppa-linux.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64919 --- Comment #9 from Jonathan Wakely --- (In reply to Joseph John from comment #5) > I am still struggling to compiler any version giver than GCC 4.9.0 on ia64 > platform still but as far as this issue is concerned I was able to get pass > the LD abort when I used the below options for configure: > > CC="gcc -mlp64" CXX="g++ -mlp64" > > With this option I was able to pass the linker abort just after the > libbackend.a creation but I run into a segmentation error which I believe is > the documented issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 That bug now seems to have some fixes/workarounds to allow building 4.9.4
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Jonathan Wakely changed: What|Removed |Added Keywords||build CC||danglin at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- A user on IRC reported similar errors for GCC 9.1.0: g++ -mlp64 -std=gnu++98 -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o ia64-c.o default-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -lmpc -lmpfr -lgmp -L./../zlib -lz -lunwind ld: The value 0xfda61f70 does not fit when applying the relocation PCREL21B for symbol ".text" at offset 0x2a2 in section index 622 of file libbackend.a[wide-int-range.o] 426 errors. collect2: error: ld returned 1 exit status Dave, are you aware of anybody testing ia64-hpux? Should it be deprecated if nobody is maintaining it?
[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 #6 from Joseph John --- Frank, Any pointers you could give me on this how you solved the first issue coming because of native LD? That could help me a lot. I believe you still compiled with native LD but how did you progress the "relocation PCREL21B" error?
[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 #7 from Joseph John --- MY LD version is below: -bash-4.3$ ld -V ld: 92453-07 linker ld HP Itanium(R) B.12.60 IPF/IPF Are you using the same version?
[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 #5 from Joseph John --- I am still struggling to compiler any version giver than GCC 4.9.0 on ia64 platform still but as far as this issue is concerned I was able to get pass the LD abort when I used the below options for configure: CC="gcc -mlp64" CXX="g++ -mlp64" With this option I was able to pass the linker abort just after the libbackend.a creation but I run into a segmentation error which I believe is the documented issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Joseph John changed: What|Removed |Added CC||josephpattara at gmail dot com --- Comment #3 from Joseph John --- I am trying to compile GCC 4.9.2 on HP-UX 11.31 and am precisely getting the same LD error. Do we have any update or toot cause on this issue?
[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 #4 from Joseph John --- I tried with source build for 4.9.2 and 4.9.3 but both of them resulted in same ld relocation error.
