[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.
[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 #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 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 #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 #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 #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 #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 #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 #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 #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 #227 from John Buddery --- Created attachment 50970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50970=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 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 #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 #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 #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 #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
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,
>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
