https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
--- Comment #10 from John Buddery ---
I can confirm this works on the gcc-13 branch, for both c++17 and c++20 - feel
free to close this issue.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jvb at cyberscience dot com
Target Milestone: ---
Compiling using -D_GLIBCXX_ASSERTIONS fails in gcc 12.1.0, worked in 11.1.0:
#include
extern std
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 #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 #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 #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 #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 #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 #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 #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
--- 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 #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 #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 #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 #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
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82902
--- Comment #5 from John Buddery ---
Thanks for the quick fix - this resolves the ICE in 8.0 for me, and applying to
7.2 fixes the invalid code generation I was seeing there.
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jvb at cyberscience dot com
Target Milestone: ---
Created attachment 42565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42565&action=edit
Reduced test case, compile with -O1 -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #24 from John Buddery ---
You can use --disable-libgomp in the configure command, I had to do this on my
HP builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #17 from John Buddery ---
My ld is slightly older:
ld: 92453-07 linker ld HP Itanium(R) B.12.42 IPF/IPF
It may have been older still when I built gcc, as OS patches have been applied
since then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #14 from John Buddery ---
I did get a working 4.9.2 build, with the workaround from my earlier comment.
It's a 32 bit build, bootstrapped with the hp 4.6.2 gcc distribution, my config
line was:
$ ../gcc-4.9.2/configure --disable-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #9 from John Buddery ---
I should clarify that the workaround above only works fully on 4.9.2 and
earlier.
>From 5.0 onwards, gcc seems to have a problem building 32 bit code for
ia64-hpux.
It doesn't emit intstructions to properly s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967
Summary: The -static-libstdc++ does not work on HP-UX (IA64
B.11.23, probably others)
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
26 matches
Mail list logo