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
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
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
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,
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
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
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
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
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
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
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
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
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
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
>
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"
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
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
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/
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
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
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
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
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;
}
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
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.s
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
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
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
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:
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#
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)
> ;;
>
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
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.
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?
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
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
>
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
> >
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/
>
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
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
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,
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
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
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
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
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
>
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://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
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
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
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
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.
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
CC|
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
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?
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Joseph John changed:
What|Removed |Added
CC||josephpattara at gmail dot com
---
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.
64 matches
Mail list logo
