[Bug libstdc++/106547] std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-08-06
[Bug tree-optimization/106243] Failure to optimize (0 - x) & 1 on gimple level (including vector types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Target Milestone|--- |13.0 --- Comment #3 from Roger Sayle --- This has now been fixed on mainline (for both scalar and vector types). Thanks Sam.
[Bug target/106544] riscv_print_operand does not check to see if the operands are valid to do INTVAL on them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106544
--- Comment #2 from Andrew Pinski ---
(In reply to palmer from comment #1)
> Do you have an example of how to trigger the ICE? I don't know what RTL
> checking is and poking around on the internet isn't helping much. I've got
> something I think should fix the problem (just checking CONST_INT_P every
> time), but i'd like to have a test case.
--enable-checking=yes,rtl :)
One example is:
```
void f(int a)
{
asm("#%A0" : : "r"(a));
}
```
Which gives an ICE even without RTL checking:
during RTL pass: final
t.c: In function âfâ:
t.c:4:1: internal compiler error: in riscv_memmodel_needs_amo_acquire, at
config/riscv/riscv.cc:3635
4 | }
| ^
0x11f105a riscv_memmodel_needs_amo_acquire
../../src/gcc/config/riscv/riscv.cc:3635
0x11f105a riscv_print_operand
../../src/gcc/config/riscv/riscv.cc:3702
0xaebd41 output_operand(rtx_def*, int)
../../src/gcc/final.cc:3676
0xaec1ed output_asm_insn(char const*, rtx_def**)
../../src/gcc/final.cc:3569
0xaedd29 output_asm_insn(char const*, rtx_def**)
../../src/gcc/final.cc:2686
0xaedd29 final_scan_insn_1
../../src/gcc/final.cc:2689
0xaee49b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src/gcc/final.cc:2939
0xaee744 final_1
../../src/gcc/final.cc:1996
0xaef1f4 rest_of_handle_final
../../src/gcc/final.cc:4284
0xaef1f4 execute
../../src/gcc/final.cc:4364
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/106544] riscv_print_operand does not check to see if the operands are valid to do INTVAL on them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106544 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #1 from palmer at gcc dot gnu.org --- Do you have an example of how to trigger the ICE? I don't know what RTL checking is and poking around on the internet isn't helping much. I've got something I think should fix the problem (just checking CONST_INT_P every time), but i'd like to have a test case.
[Bug libstdc++/106547] New: std::variant::emplace goes into an infinite recursion with certain weird trivially copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547
Bug ID: 106547
Summary: std::variant::emplace goes into an infinite recursion
with certain weird trivially copyable types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: the.invisible.phantom at gmail dot com
Target Milestone: ---
Created attachment 53421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53421=edit
Preprocessed source file
Consider the following source code (preprocessed version attached):
#include
#include
struct weird {
weird() {}
weird(std::same_as auto&&) {}
weird(const weird&) = default;
weird& operator=(const weird&) = default;
};
int main() {
std::variant data;
data.emplace();
}
When executing, the emplace call goes into an infinite recursion.
The emplace function has a number of different implementations, selected using
`if constexpr`. The first `if constexpr` branch has the condition
`is_nothrow_constructible_v`; since the constructor that we're
using is not noexcept, that branch is not taken. The second branch has the
condition `is_scalar_v`, which does not apply, either.
The third branch has the condition
`__detail::__variant::_Never_valueless_alt() && _Traits::_S_move_assign`.
The second part simply requires that all alternatives be move-assignable, which
is true here. The first part checks two things: that the type's size not exceed
256 bytes, which is true, and that the type be trivially copyable. The `weird`
type has a trivial destructor, a trivial copy constructor, a trivial copy
assignment operator, no move constructor, and no move assignment operator;
therefore, it is trivially copyable and the third branch is chosen.
The implementation in the third branch constructs a temporary variant on the
stack and then move-assigns it to `*this`. The move assignment ultimately calls
emplace again, this time constructing the alternative from `weird&&`. The text
in the comment appears to expect that the first `if constexpr` branch --
corresponding to the noexcept constructor -- will be chosen.
However, construction from `weird&&` actually calls `weird`'s second
constructor, which is not noexcept. (It does not prevent `weird` from being
trivially copyable, since it is a template and therefore is not a move
constructor.) Therefore, this actually chooses the third branch once again,
which, once again, constructs a temporary variant on the stack and move-assigns
it to `*this`. This causes an infinite recursion.
To sum up, the key problem here is that the `weird` type is trivially copyable,
but its move construction is not noexcept, because it invokes a constructor
template that is not a move constructor. (A real-world example of such a weird
type is gsl::not_null from Microsoft's GSL implementation
).
Full invocation of GCC is below. (I also reproduced it on godbolt.org using the
"gcc (trunk)" compiler and checked the source code in the git repository to
make sure the offending lines are still there.)
$ g++ -v -save-temps -std=c++20 test.cpp -o test
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.2.0-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-gBFGDP/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-gBFGDP/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-o' 'test'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug fortran/106546] Incorrect reuse of allocatable array temporaries under -O2 -fno-automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106546 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Seems to be related to the frontend optimization. Add -fno-frontend-optimize to your options.
[Bug fortran/106546] New: Incorrect reuse of allocatable array temporaries under -O2 -fno-automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106546 Bug ID: 106546 Summary: Incorrect reuse of allocatable array temporaries under -O2 -fno-automatic Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: solomon.gibbs at gmail dot com Target Milestone: --- Created attachment 53420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53420=edit Test program that produces the error when compiled and run as described I get an array extent error when running code using allocatable array temporaries compiled with with the flags -O2 -fcheck=bounds -fno-automatic. The error does not occur with -fautomatic instead of -fno-automatic. I believe the generated code is trying to reuse the allocated array temporary, but does not correctly manage resizing it before reuse. It appears that once the temporary is allocated with the maximum possible size, it is never reallocated with a smaller size. I have observed this behavior with GFortran 8.5, 9.4, and 10.3. The attached code example shows the behavior. Compiled as gfortran-10 -o bogus bogus.f90 -O2 -fcheck=bounds -fno-automatic -Wall -Wextra The executable will eventually crash with an error like: Fortran runtime error: Incorrect extent in argument B in MATMUL intrinsic in dimension 1: is 6, should be 2 Error termination. Backtrace: #0 0x7f39f6af6d21 in ??? #1 0x7f39f6af7869 in ??? #2 0x7f39f6af7d99 in ??? #3 0x564889bb5e87 in ??? #4 0x564889bb5144 in ??? #5 0x7f39f6908082 in __libc_start_main at ../csu/libc-start.c:308 #6 0x564889bb517d in ??? #7 0x in ??? $ gfortran-10 -v Using built-in specs. COLLECT_GCC=gfortran-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #3 from Brecht Sanders --- Some information I received related to this issue: On 01/08/2022 14:52, Luis Dallos wrote: > > PCH has had issues for as long as I can remember, see for example: > > * > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0010-Fix-using-large-PCH.patch > > The msys2 team commited in msys2/MINGW-packages@52908ed an additional patch > in order to fix PCH relocation issues. > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0021-PR14940-Allow-a-PCH-to-be-mapped-to-a-different-addr.patch > > See also: > > msys2/MINGW-packages#11582 (comment) > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594556.html
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 Paul Hua changed: What|Removed |Added CC||paul.hua.gm at gmail dot com --- Comment #5 from Paul Hua --- (In reply to CVS Commits from comment #3) > The master branch has been updated by Jakub Jelinek : > > https://gcc.gnu.org/g:0bc1566dec0cab9410723c96d2ef3280fdab8e8e > > commit r13-1854-g0bc1566dec0cab9410723c96d2ef3280fdab8e8e > Author: Jakub Jelinek > Date: Wed Jul 27 12:02:12 2022 +0200 > > testsuite: Add -Wno-psabi to pr94920 tests [PR94920] > > These tests fail on ia32, because we get -Wpsabi warnings. > Fixed by adding -Wno-psabi. The pr94920.C test still fails the > ABS_EXPR scan-tree-dump though, I think we'll need to add vect > options and use vect_int effective target or something similar. Yes, we should do. This also fails the ABS_EXPR scan-tree-dump on LoongArch. > > 2022-07-27 Jakub Jelinek > > PR tree-optimization/94920 > * g++.dg/pr94920.C: Add -Wno-psabi to dg-options. > * g++.dg/pr94920-1.C: Add dg-additional-options -Wno-psabi.
