[Bug libstdc++/111129] New: std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Bug ID: 29
Summary: std::regex incorrectly matches quantifiers with plus
appended
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Example code:
```
#include
#include
#include
int main(void) {
std::smatch matches;
auto re = std::regex(R"(a++)", std::regex::icase);
std::string inp = "aaa";
std::regex_search(inp, matches, re);
for (auto &match: matches) {
printf("%s\n", match.str().data());
}
}
```
With libstdc++, this does not crash, and outputs 'aaa'.
This gives people a false idea that libstdc++ implements possessive quantifiers
(see e.g. https://github.com/wwmm/easyeffects/pull/2536) despite the
documentation or code having no references to any such extension (and the C++
standard likewise not mentioning it). You can verify that the semantics are not
possessive by changing the pattern to 'a++a', which should with possessive
semantics not match anything, but with libstdc++ it's an identical match as
before.
With libc++, this correctly fails with: libc++abi: terminating due to uncaught
exception of type std::__1::regex_error: One of *?+{ was not preceded by a
valid regular expression.
[Bug bootstrap/113174] New: gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 Bug ID: 113174 Summary: gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error) Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gcc at octaforge dot org Target Milestone: --- Attempting to bootstrap GCC on Chimera Linux (https://chimera-linux.org) which uses LLVM/Clang as its system compiler and runtime fails, presumably inside the stage 1 compiler, with an internal compiler error. Backtrace from cc1plus, full build logs (gcc-build.log is the original build run, gcc-build2.log is after resumption), as well as the -dap output for the affected file is available here: https://ftp.octaforge.org/q66/random/gcc-out/ Packaging and patches available here: https://github.com/chimera-linux/cports/tree/master/experimental/gcc In particular, configure arguments are listed at https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L11 and at https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L123 , for ppc64le. Apologies for the potentially verbose script. The patches are almost entirely taken from Alpine Linux (which supports ppc64le and seemingly builds fine) outside of my patches that enforce defaulting to compiler-rt runtime instead of libgcc (libclang_rt.builtins + libunwind) and libc++ in place of libstdc++ to match the system toolchain (as otherwise gcc would generate incompatible binaries in this environment). I believe those should not affect this ICE (as this happens during object file generation), or at least I have no idea of the mechanism if they do. Observations: 1) passing -fno-tree-ter will prevent most of the crashes (and it was passed during the build above, mistakenly as I had not intended to pass it) but it eventually crashes anyway (it just does so later; I have verified that the backtraces are identical, so regardless of -fno-tree-ter the same issue is triggered) 2) the insn-recog.cc differs quite a bit for gcc-prev and gcc (diff: https://0x0.st/HEt-.diff), the function that segfaults in the backtrace notably is changed; I'm not entirely sure why 3) I'm not sure if this is just the stage 1 compiler crashing or if subsequent stages are affected; to me from the output it looks like this is still stage 1, however I tried all sorts of combinations of flags (including STAGE1_TFLAGS) without success 4) I tested other targets (x86_64 and aarch64) which work fine. The issue appears to be isolated to rs6000, and quite possibly ppc64le only, as it appears to deal with VSX. However, I had not been able to test this on ppc64 big endian yet. Please let me know if any other information is needed from me. I believe a preprocessed source file is probably not helpful as the issue only reproduces with a particular compiler build for a pretty random set of inputs. I was hoping to figure this out by myself, however I am not familiar enough with GCC's design and internals to make a good sense of this. Apologies if the information is incomplete or if this is an issue with my configuration in some way.
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #3 from Daniel Kolesa --- this is the preprocessed source: https://0x0.st/HEt7.ii It's generated with the following command line: /builddir/gcc-13.2.1_git20231014/build/./prev-gcc/xg++ -B/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/ -B/usr/powerpc64le-chimera-linux-musl/bin/ -nostdinc++ -B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs -B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs -I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl -I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include -I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs -L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -fno-tree-ter -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/builddir/gcc-13.2.1_git20231014/gcc -I/builddir/gcc-13.2.1_git20231014/gcc/. -I/builddir/gcc-13.2.1_git20231014/gcc/../include -I/builddir/gcc-13.2.1_git20231014/gcc/../libcpp/include -I/builddir/gcc-13.2.1_git20231014/gcc/../libcody -Iyes/include -Iyes/include -Iyes/include -I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber -I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber/dpd -I../libdecnumber -I/builddir/gcc-13.2.1_git20231014/gcc/../libbacktrace -o modulo-sched.o -MT modulo-sched.o -MMD -MP -MF ./.deps/modulo-sched.TPo /builddir/gcc-13.2.1_git20231014/gcc/modulo-sched.cc The command line is taken from the failing log. Yes, it could be an LLVM bug. It's hard to say whether it is though.
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #4 from Daniel Kolesa --- I don't think builds with completely unchanged source are going to work, as the compiler won't even reach this point then (at very least several of them are necessary for stage 1 to build at all)
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #6 from Daniel Kolesa ---
If it helps, I have reduced the patches to just the two that strictly necessary
for stage 1 build (I can't get rid of those, sorry, that would be asking for
the impossible), which are:
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang-tree-vect.patch
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang17.patch
and reproduced the exact same segfault on the same files with the exact same
backtrace.
Therefore, I can safely conclude that the patches are 100% irrelevant to the
problem at hand, as the two remaining ones are merely small build fixes.
--
libtool: compile: /builddir/gcc-13.2.1_git20231014/build/./gcc/xgcc
-shared-libgcc -B/builddir/gcc-13.2.1_git20231014/build/./gcc -nostdinc++
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc64le-chimera-linux-musl/bin/
-B/usr/powerpc64le-chimera-linux-musl/lib/ -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include -fno-checking
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -std=gnu++17
-nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection -mtune=power9 -O2
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -g2 -D_GNU_SOURCE -c
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o
during RTL pass: combine
In file included from
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc:86:
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:
In function '{anonymous}::fast_float::adjusted_mantissa
{anonymous}::fast_float::digit_comp(parsed_number_string&, adjusted_mantissa)
[with T = float]':
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:2850:1:
internal compiler error: Segmentation fault
2850 | }
| ^
0x1279a323 crash_signal(int)
/builddir/gcc-13.2.1_git20231014/gcc/toplev.cc:314
cc1plus:
/builddir/gcc-13.2.1_git20231014/build/./gcc/cc1plus -quiet -nostdinc++
-nostdinc++ -v -I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc -I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -iprefix
/builddir/gcc-13.2.1_git20231014/build/gcc/../lib/gcc/powerpc64le-chimera-linux-musl/13.2.1/
-isystem /builddir/gcc-13.2.1_git20231014/build/./gcc/include -isystem
/builddir/gcc-13.2.1_git20231014/build/./gcc/include-fixed -D_GNU_SOURCE -D
_GLIBCXX_SHARED -D _GNU_SOURCE -D PIC -D _GLIBCXX_SHARED -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc
-msecure-plt -quiet -dumpbase floating_from_chars.cc -dumpbase-ext .cc
-mtune=power9 -mabi=elfv2 -g2 -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -std=gnu++17 -version -fno-checking -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -fPIC -o /tmp/ccLDfChm.s
backtrace:
* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
8016li %0,%1
8017mf%1 %0
8018mt%0 %1
-> 8019lwz%U1%X1 %0,%1
8020stw%U0%X0 %1,%0"
8021 [(set_attr_alternative "type"
8022 [(const_string "cr_logical")
(lldb) bt
* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
* frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
frame #1: 0x1154aa50 cc1plus`recog_126(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #7 from Daniel Kolesa --- I just tested this on big-endian ppc64 targeting power4/ppc970; I was able to successfully bootstrap the compiler. It seems this is really specific to LE after all (which makes sense I suppose, considering the affected code appears to be related to VSX?)
[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #8 from Daniel Kolesa ---
I tried an experiment: I canceled the build after initial generation of
insn-recog.cc and patched the offending part with logic from a stage-2
insn-recog.cc I managed to previously capture:
```
--- insn-recog.cc.orig 2024-01-07 04:46:19.328295337 +0100
+++ insn-recog.cc 2024-01-07 04:41:52.025630846 +0100
@@ -41675,11 +41675,12 @@
break;
}
operands[0] = x3;
- if (!gpc_reg_operand (operands[0], E_SImode)
+ if (GET_CODE (x2) != MEM
|| GET_MODE (x2) != E_SImode)
return -1;
x4 = XEXP (x2, 0);
- if (GET_MODE (x4) != E_SImode)
+ if (GET_CODE (x4) != PLUS
+ || GET_MODE (x4) != E_SImode)
return -1;
switch (GET_CODE (x2))
{
```
This allowed all 3 stages to finish building. It results in lots of failed
comparisons for stage2 and stage3 files though, and is obviously not a workable
solution.
[Bug bootstrap/113174] gcc fails to bootstrap on ppc64le with clang-based host environment (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174 --- Comment #9 from q66 --- tested with clang 18.x build and tip-of-tree 14.1 branch, still applies
