[Bug tree-optimization/82902] New: ICE verify_ssa failed during GIMPLE pass: phiprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82902 Bug ID: 82902 Summary: ICE verify_ssa failed during GIMPLE pass: phiprop Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 (or -O2) Compiling a particular file (reduce case attached) with -O1 -ftree-vrp (or -O2) fails with: test1.c: In function ‘a’: test1.c:49:5: error: definition in block 8 does not dominate use in block 5 int a( LT elt, CEV_T *CEV ) ^ for SSA_NAME: _5 in statement: # .MEM_22 = VDEF <.MEM_8> *_5 = MEM[(struct EV_T *)_16]; during GIMPLE pass: phiprop test1.c:49:5: internal compiler error: verify_ssa failed 0xe20803 verify_ssa(bool, bool) ../../gcc-trunk/gcc/tree-ssa.c:1188 0xb6dcbd execute_function_todo ../../gcc-trunk/gcc/passes.c:2001 0xb6ea2e execute_todo ../../gcc-trunk/gcc/passes.c:2048 Works with -O2 -no-tree-vrp. The ICE is from a trunk build, gcc version 8.0.0 20171108 (x86_64-pc-linux-gnu) Gcc 7.0 to 7.2 produces invalid code which will SEGV at runtime (same result on many platforms). Gcc 6.3 and earlier produced working code. To reproduce: gcc -O1 -ftree-vrp test1.c
[Bug tree-optimization/82902] [7 Regression] ICE verify_ssa failed during GIMPLE pass: phiprop
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.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 John Buddery changed: What|Removed |Added CC||jvb at cyberscience dot com --- Comment #6 from John Buddery --- I had this issue as well, and here is the solution I used in case anyone is still interested. I believe it is caused by an HP-UX linker bug, the same one described by this comment and workaround in config/ia64/hpux.h: /* The HP-UX linker has a bug that causes calls from functions in .text.unlikely to functions in .text to cause a segfault. Until it is fixed, prevent code from being put into .text.unlikely or .text.hot. */ #define TARGET_ASM_FUNCTION_SECTION ia64_hpux_function_section While this workaround is sufficient for C code, unfortunately g++ can use multiple text sections for various different reasons when compiling c++ code (lookup Vague Linkage for details). This means g++ is broken on HP ia64, and gcc 4.8.0 build using g++, which is why the bootstrap now fails. The workaround I applied was to add the line: #undef MAKE_DECL_ONE_ONLY to gcc/config/ia64/hpux.h, below the lines I referenced above. This seems to prevent gcc from using .linkonce.t sections, and keeps the HP-UX linker happy. I've no idea if this is the correct solution, but it does produce a working g++. Unfortunately just applying this edit you your 4.9.2 sources and building isn't good enough, because it's your existing broken g++ which does the stage1 build. As far as I can tell all g++ versions available for download are broken, so you have to first download and build 4.7.4 or earlier, applying the same gcc/config/ia64/hpux.h as above. This version builds with gcc, not g++, so the bootstrap isn't a problem. Once you have a fixed 4.7.4 g++, you can then use that to bootstrap 4.9.2 - after again apply the hpux.h edit to the 4.9.2 sources. In my case when building 4.9.2 I also had to disable libgomp, but I think that's a different issue. Of course a much better solution to all this would be to get a fixed HP linker; but I can't even tell if any of the HP patches help as they don't seem to make these fixes generally available.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
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-libgomp --with-as=/opt/hp-gcc/bin/as --enable-languages=c,c++ --prefix=/usr/local/gcc-4.9.2 --with-gmp=/usr/local/gcc-4.9.2 --with-mpc=/usr/local/gcc-4.9.2 --with-mpfr=/usr/local/gcc-4.9.2 I don't remember any errors in libstdc++. I would recommend installing gawk if you haven't already - the HP awk can cause issues when building gcc.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
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.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
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.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
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 set the top two bits of pointers after widening, which is required because of the way ia64 segments it's address space. So, you might have better luck with 4.9.2. Or, you might be able to build gcc as a 64 bit executable (though I don't know how to do configure it this way).
[Bug c++/49967] New: The -static-libstdc++ does not work on HP-UX (IA64 B.11.23, probably others)
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 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@cyberscience.com Host: HP-UX IA64 Target: HP-UX IA64 The -static-libstdc++ option is silently ignored on HP-IX, IA64 platform. The reason for this seems to be that g++spec.c relies on HAVE_LD_STATIC_DYNAMIC from auto-host.h, and if this is not set silently fails to implement -static-libstdc++. The HP linker does have options to implement HAVE_LD_STATIC_DYNAMIC, but configure has not detected them. Presumably this is because they are not the usual -Bstatic and -Bdynamic, the HP options are -aarchive and -ashared_archive (not -ashared which disables archive libs completely). Changing auto-host.h to use: #define HAVE_LD_STATIC_DYNAMIC 1 #define LD_DYNAMIC_OPTION "-ashared_archive" #define LD_STATIC_OPTION "-aarchive" resolves the issue, but of course is not the right fix since this file is generated. So, this is really a configuration time issue. As an additional fix though, I would really expect g++ to error or warn if -static-libstdc++ can't be implemented, instead of silently ignoring. Also it could provide the archive name to the linker in place of -lstdc++ for systems where HAVE_LD_STATIC_DYNAMIC really doesn't exist - but possibly if this were fixed for HP there might not be any systems with this restriction.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment #215 from John Buddery ---
I recently upgraded my hp-ix ia64 gcc build to 11.1.0, and I thought I'd share
what I did in case it's useful for anyone still following this thread.
I started with the patches in this thread, and soon got to the 21 bit
relocation errors.
Thanks to the excellent PCREL60B analysis above, I applied this simple edit to
binutils 2.36 (you have to enable obsoletes to get a build):
--- binutils-2.36/gas/config/tc-ia64.c 2021-01-09 10:47:33.0 +
+++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
+0100
@@ -6892,7 +6892,13 @@
for (j = 0; j < md.slot[curr].num_fixups; ++j)
{
ifix = md.slot[curr].fixup + j;
- fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
+
+ unsigned long where = frag_now_fix () - 16 + i;
+#ifdef TE_HPUX
+ if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
+#endif
+
+ fix = fix_new_exp (frag_now, where, 8,
&ifix->expr, ifix->is_pcrel, ifix->code);
fix->tc_fix_data.opnd = ifix->opnd;
fix->fx_file = md.slot[curr].src_file;
This fixes, for HP only, the PCTEL60B offset to be what the HP linker expects.
I don't know if the same is appropriate for Linux ia-64 or not, as I don't have
access to that environment. I'll add that to the binutils bug report as well,
but I've included it here so people can find it for gcc more easily.
With the working as, I changed gcc to use brl instructions for calls, including
tail calls:
--- gcc-11.1.0/gcc/config/ia64/ia64.md 2021-04-27 11:00:13.0 +0100
+++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md2021-05-13 14:49:21.0
+0100
@@ -4410,7 +4410,9 @@
(const_int 0))
(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
""
- "br.call%+.many %1 = %0"
+ "@
+ br.call%+.many %1 = %0
+ brl.call%+.many %1 = %0"
[(set_attr "itanium_class" "br,scall")])
(define_insn "call_value_nogp"
@@ -4419,14 +4421,18 @@
(const_int 0)))
(clobber (match_operand:DI 2 "register_operand" "=b,b"))]
""
- "br.call%+.many %2 = %1"
+ "@
+ br.call%+.many %2 = %1
+ brl.call%+.many %2 = %1"
[(set_attr "itanium_class" "br,scall")])
(define_insn "sibcall_nogp"
[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
(const_int 0))]
""
- "br%+.many %0"
+ "@
+ br%+.many %0
+ brl%+.many %0"
[(set_attr "itanium_class" "br,scall")])
(define_insn "call_gp"
You have to be careful only to use brl on immediate calls, the assembler does
not accept brl with registers.
The above unconditionally uses brl - on hp-ux and other platforms. This would
work very badly (if at all) on an Itanium 1 (but I'm not sure they are still
around), and is slightly less efficient even on Itanium 2. So, possibly this
should be more limited, maybe using -mlong-call as requesting in Bug 20819 ?
Anyway, with the assembler patch and the brl patch, along with the other
patches in this thread, gcc 11.1.0 will successfully bootstrap in both 32 and
64 bits, and seems to work well - I've built a large 64 bit project with no
problems so far.
There are a lot of fails from the testsuite, but I suspect that's normal for
this os (I'll post results to the testresults list).
---
John
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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_operand:DI 0 "call_operand" "?b,s")) (const_int 0)) (clobber (match_operand:DI 1 "register_operand" "=b,b"))] "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2" "@ br.call%+.many %1 = %0 brl.call%+.many %1 = %0" [(set_attr "itanium_class" "br,scall")]) (define_insn "call_nogp" [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) (const_int 0)) (clobber (match_operand:DI 1 "register_operand" "=b,b"))] "" "br.call%+.many %1 = %0" [(set_attr "itanium_class" "br,scall")]) I assume you need a second instruction to catch the case where the condition doesn't match ? Itanium 1 support seems to have been dropped at some point, so -mtune only accepts options mapping to Itanium2. So, I couldn't test the br case on HP.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 assembler would patch this up and accept both, but it doesn't so the two variants are needed. I'll look into the scall attribute as well.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #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" "?b,s"))
(const_int 0))
(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
""
{
if (TARGET_HPUX && which_alternative == 1 )
return "brl.call%+.many %1 = %0";
else
return "br.call%+.many %1 = %0";
}
[(set_attr "itanium_class" "br,scall")])
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 instruction not a pure B unit
instruction, so I think it should be type "L".
Looks like cond and match-test are valid for attributes, so it should be
possible to get this right.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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.md, which looks at the actual itanium_class rather than just the derived type as I was expecting, and fixes the bundling for long_i only (rather than type L). For now I've reverted to scall to test the other changes - this seems to work, probably because the assembler is fixing up any bundling issues This isn't really right though, as you say it needs combined long_i and scall behaviour for a new type.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 several large projects. Most of the patch is a cumulation of the patches posted earlier in this thread - unsigned pointer extension, reverting @gprel changes etc. gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you hit errors but may need tidying up. ia64.md is the patch for long calls, to avoid the 25 bit limit which prevents linking gcc. It's still a work in progress as the instruction bundling is wrong, but it does work. Note that you must apply the binutils patch (or build the current binutils master, or a release after 2.36) to get an assembler that will work with brl and the HP linker. Do not apply the ia64.md patch without building a patched gnu assembler first! Also note that you need a working C++ compiler to bootstrap. That sounds obvious, but is harder than you think - as far as I know, none of the distributed g++ versions work sufficiently. One way to get a working 4.9.2 g++ is described in my post in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 but there may be other solutions as well. I've never tried to bootstrap with aCC. My configure command is: ../gcc-11.1.0/configure --enable-comdat --disable-libgomp --with -as=/usr/local/binutils/bin/as --enable-languages=c,c++ --prefix=/usr/local/gcc- 11.1.0 --with-gmp=/usr/local_32 --with-mpc=/usr/local_32 --with-mpfr=/usr/local_ 32 --with-dwarf2 The --enable-comdat I think is required. I think libgomp doesn't build, I've never investigated though and disable it. I use dwarf2 as recent gdb versions won't work. The assembler I use is a patched binutils 2.36. Good luck!
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 using long calls (brl).
[Bug c++/105545] New: Compiling string assignment with _GLIBCXX_ASSERTIONS defined fails in 12.1.0, works in 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
Bug ID: 105545
Summary: Compiling string assignment with _GLIBCXX_ASSERTIONS
defined fails in 12.1.0, works in 11.1.0
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
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::string a();
std::string a()
{
std::string x;
x.assign( "Z" );
return x;
}
using command line:
g++ -m64 -c -std=gnu++17 -Wall -O3 -Werror -D_GLIBCXX_ASSERTIONS x.cpp
fails with:
In file included from /usr/local/gcc-12.1.0/include/c++/12.1.0/string:40,
from x.cpp:14:
In static member function ??static std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)??,
inlined from ??static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.h:423:21,
inlined from ??std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_replace(size_type,
size_type, const _CharT*, size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.tcc:532:22,
inlined from ??std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.h:1647:19,
inlined from ??std::string a()?? at x.cpp:22:12:
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/char_traits.h:431:56: error:
??void* __builtin_memcpy(void*, const void*, long unsigned int)?? accessing
9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 17
may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict]
431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
cc1plus: all warnings being treated as errors
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 gmp and mpc outside the tree as well. I don't know about the ld crash - see if it occurs when building 11.1 after you get past the mpfr issue. If it does, that binutils patch will probably work with older binutils versions, so you might be able to find one compatible with your ld. I don't think it's the patch itself, as that only affects brl instructions which gcc won't be generating until the 11.1 patch.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 starting from scratch. This was never really the right fix, and as support for systems without MAKE_DECL_ONE_ONLY has deteriorated in later versions it became harder and harder to follow this route. I did get some intermediate versions working with a lot of hacking, but for any vaguely recent release I would recommend using the 11.1 patches instead.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 linker to crash when making the 64 bit libstdc++.so. Build binutils as 64 bit, by using a configure something like: CFLAGS="-O2 -mlp64" ./configure -prefix=/usr/local
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 down.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 ?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 here committed so that future versions will build out of the box.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 couldn't work out the endianism. Configuring with: CFLAGS="-O -D__BIG_ENDIAN__=1" ./configure --prefix=/u sr/local/binutils-test --enable-obsolete allowed gas to build, but the build then failed later on in libctf. It looks like libtool is inserting +Maked into the command line for some reason, which breaks things. I don't know if this gas build would work for gcc, probably it would have the same issues as a 32 bit gcc build. +DD64 might fix this. Probably not worth updating though just for gcc if you have a working 2.30 build, since that works OK.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 ?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #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 SIGILL - not sure why that's the signal being generated.
[Bug tree-optimization/105545] [12/13/14 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
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.
