https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #276 from Larkin Nickle ---
Created attachment 51215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51215&action=edit
How I'm attempting to build GCC 11.1
For what it's worth, here's exactly how I'm attempting to build 11.1. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #275 from dave.anglin at bell dot net ---
On 2021-07-21 12:55 p.m., me at larbob dot org wrote:
> Here's `disas $pc-256,$pc+256`'s output.
Maybe r47 contains garbage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #274 from Larkin Nickle ---
Created attachment 51190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51190&action=edit
disas of cc1 with more context
Here's `disas $pc-256,$pc+256`'s output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #273 from John Buddery ---
If you go back a bit further, is there a speculative load of one of those
registers
(probably r47 / r59 ) ?
A speculative load will have a .s I think.
I believe ILL_REGNAT should actually be a SEGV, not SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #272 from Larkin Nickle ---
(In reply to dave.anglin from comment #271)
> On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> > Reading symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #271 from dave.anglin at bell dot net ---
On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
> /home/larbob/Projects/build-gcc/builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #270 from Larkin Nickle ---
Reading symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol number
7215 references nonexistent SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #269 from Larkin Nickle ---
(In reply to The Written Word from comment #268)
> (In reply to Larkin Nickle from comment #262)
> > Created attachment 51182 [details]
> > GCC 11.1 patch to net dwarf2 debugging symbols
> >
> > Rebuilding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #268 from The Written Word
---
(In reply to Larkin Nickle from comment #262)
> Created attachment 51182 [details]
> GCC 11.1 patch to net dwarf2 debugging symbols
>
> Rebuilding with this patch. Should hopefully net me actual dwarf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #267 from The Written Word
---
(In reply to Larkin Nickle from comment #266)
> I'll try that 7.9.1 as a last resort; I noticed that 7.3.1 was able to read
> dwarf4 symbols from a previous 4.9.2 build I did so I'm testing building
> 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #266 from Larkin Nickle ---
I'll try that 7.9.1 as a last resort; I noticed that 7.3.1 was able to read
dwarf4 symbols from a previous 4.9.2 build I did so I'm testing building 11.1
patched to produce debug symbols similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #265 from The Written Word
---
(In reply to Larkin Nickle from comment #264)
> Oh, and I should mention this is what I get with 7.3.1 or 7.5.1:
>
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #263 from Larkin Nickle ---
I'm having trouble actually getting a GDB that can read the resulting symbols
properly.
readelf --debug-dump=info cc1 | grep -A 2 'Compilation Unit @'
Compilation Unit @ offset 0x0:
Length:0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #264 from Larkin Nickle ---
Oh, and I should mention this is what I get with 7.3.1 or 7.5.1:
Reading symbols from
/home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1...BFD:
/home/larbob/Projects/build-gcc/builds/gcc-11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #262 from Larkin Nickle ---
Created attachment 51182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51182&action=edit
GCC 11.1 patch to net dwarf2 debugging symbols
Rebuilding with this patch. Should hopefully net me actual dwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #261 from Larkin Nickle ---
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=59447
Argh, it seems that `--with-dwarf2` basically just means use dwarf2 *or later*,
at least in GCCs this new. Will patch gcc/common.opt and rebuild.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #260 from Larkin Nickle ---
(In reply to dave.anglin from comment #259)
> The compiler being used to compile mkstemps.c is broken. If core dumps are
> enabled,
> you should be able to use gdb (wdb) directly to find the illegal instru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #259 from dave.anglin at bell dot net ---
On 2021-07-19 5:00 p.m., me at larbob dot org wrote:
> I've now tried 11.1.0 almost exactly as The Written Word builds it, and still
> get:
>
> during GIMPLE pass: dce
> ../../libiberty/mkstemp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #258 from Larkin Nickle ---
I've now attached the configure log as well as the build log for GCC 11.1 with
`-j1` passed to make so as to make the log more readable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #257 from Larkin Nickle ---
Created attachment 51180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51180&action=edit
Build log for GCC 11.1 with -j1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #256 from Larkin Nickle ---
Created attachment 51179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51179&action=edit
Configure log for gcc 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #255 from Larkin Nickle ---
Here's the log from the attempted 11.1 build against binutils 2.30. Built with
4.8.5. I'm not able to attach this as it's over the max size limit.
https://gist.githubusercontent.com/larb0b/f3a855892f7b16f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #254 from Larkin Nickle ---
I've now tried 11.1.0 almost exactly as The Written Word builds it, and still
get:
during GIMPLE pass: dce
../../libiberty/mkstemps.c: In function 'mkstemps':
../../libiberty/mkstemps.c:80:1: internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #253 from The Written Word
---
(In reply to The Written Word from comment #245)
> (In reply to John Buddery from comment #238)
> > Was your 11.1 build successful ?
>
> Our rebuild of 11.1.0 completed successfully. I haven't tested i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #252 from The Written Word
---
(In reply to Larkin Nickle from comment #249)
> Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
> eventually run into other errors:
>
> ../../../../sources/gcc-11.1.0-new/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #251 from dave.anglin at bell dot net ---
On 2021-07-15 2:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #243 from The Written Word com> ---
> (In reply to J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #250 from Larkin Nickle ---
I should probably note that my PATH is set to the standard path, appended with
the PATH to whichever GCC's bin folder as well as a folder I have with some
utilities:
awk gawk make mksh sed tar
I us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #249 from Larkin Nickle ---
I am still unable to replicate a proper 11.1 build against 2.36 gas. Here's my
process:
HP GCC 4.7.1 -> GCC 4.7.4:
../../sources/gcc-4.7.4/configure --prefix=/usr/util/toolchain/gcc-4.7.4 --w
ith-as=/opt/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #248 from The Written Word
---
(In reply to John Buddery from comment #247)
> For clarification, I assume this is using the HP aCC compiler for binutils
> etc., rather than the bundled /usr/ccs/bin cc ?
Correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #247 from John Buddery ---
Looks good, that's a lot of gcc versions!
For clarification, I assume this is using the HP aCC compiler for binutils
etc., rather than the bundled /usr/ccs/bin cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #246 from The Written Word
---
Created attachment 51163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51163&action=edit
Build script and patches
Build script for zlib, gmp, mpfr, mpc, binutils 2.25.1, 2.30, 2.32, and GCC
4.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #245 from The Written Word
---
(In reply to John Buddery from comment #238)
> Was your 11.1 build successful ?
Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I am
going to try earlier GCC releases and buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #244 from John Buddery ---
I tried a gcc 11 build with patched 2.30 binutils and it worked.
I also tried building binutils 2.36 with just /opt/aCC/bin and no gcc.
I didn't get any gnu99 errors, but it did fail because plugin-api.h c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #243 from The Written Word
---
(In reply to John Buddery from comment #238)
> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
> later require a 64 bit build for 64 bit objects to work reliably.
I can bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #242 from dave.anglin at bell dot net ---
On 2021-07-15 11:01 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #241 from The Written Word com> ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #241 from The Written Word
---
(In reply to John Buddery from comment #240)
> One question about PR66319 - it's marked as resolved, so is this committed
> as a patch in the trunk ?
It's resolved for HP-UX/PA but my HP-UX/IA patch wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #240 from John Buddery ---
Yeah, it sure eats up the space.
One question about PR66319 - it's marked as resolved, so is this committed as a
patch in the trunk ?
I'm hoping that eventually there will be a way to get all the edits her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #239 from The Written Word
---
(In reply to John Buddery from comment #238)
> Thanks, I'll give it a go.
>
> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
> later require a 64 bit build for 64 bit obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #238 from John Buddery ---
Thanks, I'll give it a go.
It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
later require a 64 bit build for 64 bit objects to work reliably.
Was your 11.1 build successful ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #237 from The Written Word
---
(In reply to John Buddery from comment #228)
> gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you
> hit errors but may need tidying up.
Instead of this patch, try the patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #236 from The Written Word
---
(In reply to John Buddery from comment #235)
> Interesting - that's with a 32 bit gas?
$ file bin/gcc111/ia64-hp-hpux11.31/bin/as
bin/gcc111/ia64-hp-hpux11.31/bin/as:ELF-32 executable object file -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #235 from John Buddery ---
Interesting - that's with a 32 bit gas ?
It does look like you have got past the point in stage1 where ld was crashing.
It could be a change between 2.30 and 2.36 I guess, I might see if I can narrow
it dow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #234 from The Written Word
---
(In reply to John Buddery from comment #233)
> One additional note - when building the patched binutils 2.36, it must be
> built as 64 bit executables.
>
> It seems that a 32 bit gas does not produce 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #233 from John Buddery ---
One additional note - when building the patched binutils 2.36, it must be built
as 64 bit executables.
It seems that a 32 bit gas does not produce 64 bit object files properly on
this platform, causing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #232 from John Buddery ---
The #undef MAKE_DECL_ONE_ONLY is only for older builds, it's not needed with
the gcc 11 patches.
It was an alternative single line fix which works for 4.7.2 and 4.9.4, which
you need to build if you're star
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #231 from The Written Word
---
(In reply to John Buddery from comment #228)
> These patches are for 11.1.0, but should work on earlier versions too. With
> this I have a working gcc which I've tested on several large projects.
You d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #230 from John Buddery ---
The mpfr issue seems to be an issue with gcc 4.9.2 compiling later mpfr
versions.
It builds with 4.7.2, so as a workaround try building mpfr outside the gcc tree
using 4.7.2. This may mean you need to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Larkin Nickle changed:
What|Removed |Added
CC||me at larbob dot org
--- Comment #229 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #227 from John Buddery ---
Created attachment 50970
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50970&action=edit
Patches for gcc-11.1.0, hp-ia64
Mostly patches from this thread, apart from ia64.md which adds support for
usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #228 from John Buddery ---
Sorry it took a while, I've been away for a bit and have lots to catch up on.
These patches are for 11.1.0, but should work on earlier versions too. With
this I have a working gcc which I've tested on sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #226 from dave.anglin at bell dot net ---
John, would you please post your full patch set for ia64-hpux? This will help
others.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #225 from John Buddery ---
Yes, I looked briefly at that - I added a new class, but then started hitting
bundling errors because it wasn't being positioned correctly in the 3
instruction bundle.
It will need more changes to itanium2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #224 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> but I need to work out how to vary the attribute, as you were right: scall
> maps
> to a "B" type attribute, but brl is an L+X in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #223 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> The simplest variant I have is:
>
> (define_insn "call_nogp"
> [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #222 from dave.anglin at bell dot net ---
On 2021-05-20 10:02 a.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #220 from dave.anglin at bell dot net ---
> On 2021-05-20 9:37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #221 from John Buddery ---
Thanks - that is neater, as it avoids the need to change the calls in ia64.c,
which gets messy.
The simplest variant I have is:
(define_insn "call_nogp"
[(call (mem:DI (match_operand:DI 0 "call_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #220 from dave.anglin at bell dot net ---
On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #219 from John Buddery ---
> Great, thanks - I'll look at ia64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #219 from John Buddery ---
Great, thanks - I'll look at ia64.c and build and test with that change.
Yes, "b" on ia64 seems to be a branch register, and the brl op only accepts
immediate values not registers. Initially I hoped the ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #218 from dave.anglin at bell dot net ---
On 2021-05-20 5:19 a.m., jvb at cyberscience dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #217 from John Buddery ---
> Thanks very much for adding the bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #217 from John Buddery ---
Thanks very much for adding the binutils patch.
Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you
mean something like:
(define_insn "call_nogp_longcall"
[(call (mem:DI (match_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #216 from dave.anglin at bell dot net ---
On 2021-05-17 5:56 a.m., jvb at cyberscience dot com wrote:
> With the working as, I changed gcc to use brl instructions for calls,
> including
> tail calls:
>
> --- gcc-11.1.0/gcc/config/ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #214 from Peter Bisroev ---
(In reply to Andrew Pinski from comment #213)
> Does this still happen with GCC 8 or above?
Hi Andrew, yes it does from my last tests. As we have found out here, before
newer versions of GCC can work on HP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Andrew Pinski changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #213 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jared changed:
What|Removed |Added
CC||jared.martinsen at fiserv dot
com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #210 from dave.anglin at bell dot net ---
On 2020-05-02 12:14 a.m., peter.bisroev at groundlabs dot com wrote:
> Looks like we might have to get the fix into GNU AS first to get PCREL60B
> working. I will try to look into how we can ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #209 from Peter Bisroev ---
(In reply to dave.anglin from comment #206)
> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
> cc1plus?
Hi Dave,
Sorry for the delayed response. I have tried linker option "-Wl,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #208 from dave.anglin at bell dot net ---
On 2020-04-23 11:48 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> Peter Bisroev changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Peter Bisroev changed:
What|Removed |Added
CC||peter.bisroev at groundlabs
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #206 from dave.anglin at bell dot net ---
Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
cc1plus?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #205 from Peter Bisroev ---
Hi Dave,
I have submitted bug 25599
(https://sourceware.org/bugzilla/show_bug.cgi?id=25599) to binutils with a
slightly simplified test case and CCed you as well.
Additionally, I was also able to verify t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #204 from Peter Bisroev ---
(In reply to dave.anglin from comment #203)
> On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > Now looking at the main.o generated by gcc, the relocation seems to be as
> > expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #203 from dave.anglin at bell dot net ---
On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> Now looking at the main.o generated by gcc, the relocation seems to be as
> expected but the relocation address seems to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #202 from Peter Bisroev ---
(In reply to dave.anglin from comment #201)
> On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote:
> > They both seem to be ELF32
> Maybe run failing program under gdb to find faulting instru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #201 from dave.anglin at bell dot net ---
On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote:
> They both seem to be ELF32
Maybe run failing program under gdb to find faulting instruction. Compare with
executable that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #200 from Peter Bisroev ---
(In reply to dave.anglin from comment #199)
> On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote:
> > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but
> > when
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #199 from dave.anglin at bell dot net ---
On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote:
> Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when
> I try to run the binary I get an "Illegal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #198 from Peter Bisroev ---
(In reply to dave.anglin from comment #196)
> If you create a second object file with a second instance of hello, the
> linker should not
> complain about the second definition of hello since it is weak. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #197 from dave.anglin at bell dot net ---
On 2020-02-21 11:43 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #195 from Peter Bisroev ---
> Hi Dave,
>
> I was doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #196 from dave.anglin at bell dot net ---
On 2020-02-21 10:55 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #194 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #195 from Peter Bisroev ---
Hi Dave,
I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX
Porting Guide"
(http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577&rep=rep1&type=pdf).
I know it is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #194 from Peter Bisroev ---
(In reply to dave.anglin from comment #193)
> I presume that if you compile main.cc with g++, hello() becomes weak. You
> could test with a second instance of hello.
Yes, sorry forgot to mention that. When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #193 from dave.anglin at bell dot net ---
On 2020-02-21 7:36 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #192 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #192 from Peter Bisroev ---
(In reply to dave.anglin from comment #191)
> On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> The problem seems to be that HP ld doesn't handle the PCREL21B relocation
> correctly when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #191 from dave.anglin at bell dot net ---
On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #190 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #190 from Peter Bisroev ---
(In reply to dave.anglin from comment #189)
> On 2020-02-16 4:21 p.m., John David Anglin wrote:
> > On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
> >> I have not had a chance to look t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #189 from dave.anglin at bell dot net ---
On 2020-02-16 4:21 p.m., John David Anglin wrote:
> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
>> I have not had a chance to look through these in great detail, will do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #188 from dave.anglin at bell dot net ---
On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
> I have not had a chance to look through these in great detail, will do this
> later today, but some things I've noticed (no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #187 from Peter Bisroev ---
(In reply to dave.anglin from comment #183)
> On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
> >
> > --- Comment #180 from Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #186 from Peter Bisroev ---
Created attachment 47847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47847&action=edit
Basic compiler tests v00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #185 from Peter Bisroev ---
(In reply to dave.anglin from comment #184)
> On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> > stage b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #184 from dave.anglin at bell dot net ---
On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> stage bootstrap went fine (running 'make che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #183 from dave.anglin at bell dot net ---
On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #180 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #182 from dave.anglin at bell dot net ---
On 2020-02-14 11:04 p.m., peter.bisroev at groundlabs dot com wrote:
> However just below this check, configure looks for GNU linker, and if one not
> found, disables COMDAT group support even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #181 from Peter Bisroev ---
(In reply to Peter Bisroev from comment #179)
> (In reply to dave.anglin from comment #178)
> > The configure test didn't find support for COMDAT groups even though aCC and
> > HP ld
> > support them. So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #180 from Peter Bisroev ---
(In reply to dave.anglin from comment #177)
> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> > I have tried playing around with weak using aCC, however even though it
> > accepts
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #179 from Peter Bisroev ---
(In reply to dave.anglin from comment #178)
> The configure test didn't find support for COMDAT groups even though aCC and
> HP ld
> support them. So, there's likely something incompatible with the default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #178 from dave.anglin at bell dot net ---
On 2020-02-13 6:04 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #176 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #177 from dave.anglin at bell dot net ---
On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> I have tried playing around with weak using aCC, however even though it
> accepts
> both attribute and pragma (and complai
1 - 100 of 204 matches
Mail list logo
