[Bug c++/105300] New: segfault from static_assert with user-defined string suffix argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 Bug ID: 105300 Summary: segfault from static_assert with user-defined string suffix argument Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Jack at Applin dot US Target Milestone: --- Created attachment 52824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52824=edit preprocessed source to reproduce the error $ cat bad.ii void operator""_x(const char *, unsigned long); static_assert(false, "foo"_x); $ g++ bad.ii bad.ii:2:15: internal compiler error: Segmentation fault 2 | static_assert(false, "foo"_x); | ^ 0xb0c67e crash_signal ../../src/gcc/toplev.c:327 0x7fb38e75951f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x7dd197 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool) ../../src/gcc/cp/semantics.c:10134 0x15089c8 cp_parser_static_assert ../../src/gcc/cp/parser.c:15464 0xf9ed91 cp_parser_declaration ../../src/gcc/cp/parser.c:14164 0x149bba3 cp_parser_toplevel_declaration ../../src/gcc/cp/parser.c:14193 0x149bba3 cp_parser_translation_unit ../../src/gcc/cp/parser.c:4942 0x149bba3 c_parse_file() ../../src/gcc/cp/parser.c:45326 0x1489a5e c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1218 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. $ g++ --version g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Kewen Lin --- Fixed on latest trunk.
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:021b51814d67bedd8f41ac07edfd05654140c6e5
commit r12-8184-g021b51814d67bedd8f41ac07edfd05654140c6e5
Author: Kewen Lin
Date: Sun Apr 17 21:34:51 2022 -0500
testsuite: Skip pr105250.c for powerpc and s390 [PR105266]
This test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390. So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.
gcc/testsuite/ChangeLog:
PR testsuite/105266
* gcc.dg/pr105250.c: Skip for powerpc*-*-* and s390*-*-*.
[Bug target/105288] AVX/AVX512 casts should use the "v" constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105288 --- Comment #2 from Hongtao.liu --- I think HJ means avx__ can be extended to evex sse registes by change "x" to "v" when AVX512VL is available. For avx512f__, it should be "=Yv,m" " vm,v" since operands[0] could be allocated as evex register w/o AVX512VL, but it will be lower to 256-bit mov which require AVX512VL for evex registers.
[Bug c++/105299] dereference null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105299 --- Comment #3 from Ye Luo --- Unfortunately there is no easy reproducer. Even without the printf. I got the same failure. Will try with a debugger.
[Bug c++/105299] dereference null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105299 --- Comment #2 from Andrew Pinski --- Also this is not the right place to ask how to debug your code really. This is about reporting bugs against GCC. I highly doubt there is a bug in GCC and you didn't even read https://gcc.gnu.org/bugs/ before reporting a bug report on what we need.
[Bug c++/105299] dereference null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105299 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- There is no way we can help you debug this code with just a code segment. Maybe you have a buffer overflow on the stack which is causing ArgMappers to become null after the fprintf. gdb and watch points are useful to see when the value of ArgMappers changes if at all.
[Bug c++/105299] New: dereference null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105299
Bug ID: 105299
Summary: dereference null pointer
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xw111luoye at gmail dot com
Target Milestone: ---
My application runs in parallel on Power9 RHEL 8.2 using gcc 9.3. The failure
doesn't show up in small scale runs. However, when running with 24576(4096*6)
MPI processes,
code:
void* ArgMappers; // passed in as a function argument.
...
if (ArgMappers) {
fprintf(stderr, "ArgMappers is not nullptr %p, I = %d\n", ArgMappers, I);
if (ArgMappers[I]) {
segfault happens at the second 'if'.
the print out and failure message is
ArgMappers is not nullptr (nil), I = 3
[g32n01:3164430] *** Process received signal ***
[g32n01:3164430] Signal: Segmentation fault (11)
[g32n01:3164430] Signal code: Address not mapped (1)
[g32n01:3164430] Failing at address: 0x18
It is very strange that the first if check passed while ArgMappers is has a
value NULL as the printf shows.
In a few more runs, I got at least three failing
"Failing at address" 0x8 0x18 0x40
Any insight is welcome.
[Bug bootstrap/105298] GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105298 --- Comment #2 from Andrew Pinski --- https://bugzilla.redhat.com/show_bug.cgi?id=20218 explains why.
[Bug bootstrap/105298] GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105298 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Use LD_LIBRARY_PATH instead of LD_RUN_PATH.
[Bug bootstrap/105298] New: GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105298 Bug ID: 105298 Summary: GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: kdevel at vogtner dot de Target Milestone: --- Different from GCC 11.2 GCC 12 does not seem to build gdc without having already a gdc installed. In order to overcome this I use a GCC 11.2 which is installed in a non-std. For this puropose I set PATH=:$PATH export LD_RUN_PATH=/lib64:/lib before gcc-12-20220410/configure --prefix=$inst --enable-languages=c,c++,d where $inst ist a non-std. directory. make bootstrap then fails with error 2 and configure: error: can't compile D sources! This is caused by gcc/d21 in the objdir referencing /usr/lib64/libstdc++.so instead of /libstdc++.so, which is caused by RPATH set to $inst/lib64 instead of /lib64.
[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105295 Andrew Pinski changed: What|Removed |Added Depends on||101521 --- Comment #3 from Andrew Pinski --- PR 101521 records on how it should be implemented differently. Maybe for GCC 13, it will change. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521 [Bug 101521] -ftrapv should become something like -fsanitize=undefined -fsanitize-undefined-trap-on-error
[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105295 --- Comment #2 from Andrew Pinski --- Yes trapv is implemented during expansion (from gimple to RTL) and not really optimized.
[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105295 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement URL|https://godbolt.org/z/4rojo | |77a7| --- Comment #1 from Andrew Pinski --- https://godbolt.org/z/4rojo77a7
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #4 from Elmar Stellnberger --- The related debian-security discussion can be found here: https://lists.debian.org/debian-security/2022/04/msg00042.html (strangely I can not find my last posts when sorting by Thread, simple to see with sorting by Date)
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #3 from Elmar Stellnberger --- Created attachment 52823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52823=edit patch that should be useable under gcc-8-8.3.0/debian/patches/ I have recompiled g++ and the output of dpkg-buildpackage -b -kestel...@elstel.org -nc tells me that it should have successfully created the respective .deb package files as before. I have looked into the same directory as before but unfortunately I found not a single .deb there and nowhere else under /usr/src. The files can only have been deleted like the ssh user from /etc/passwd at my nslu2 machine. Another time I found out about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my nslu2 via ssh any more. This looks very similar as what I have experienced with arm-linux-gnueabihf-ld when the program did neither produce an error message, an !=0 return value and no output file as given with -o txtfmt. This was when I had all options right to what I can assess, i.e. just before it must have worked. As for now I can not find out whether the patch really resolves the bug. Someone else will have to be as nice to recompile for me. The patch makes a forward change to a known good g++ (version as suggested by use of moc/Qt5 rather than by building Firefox however). It patches the only piece of code that was different along the backtrace of Firefox-esr-91.8.0esr.
[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105291 corentinjabot at gmail dot com changed: What|Removed |Added CC||corentinjabot at gmail dot com --- Comment #4 from corentinjabot at gmail dot com --- Agreed, clang should implement the proposed resolution to CWG2569 very soon so there isn't anything that needs to change in libstdc++
[Bug c++/104020] [coroutines] ICE in co_await function call with initializer_list arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104020 Avi Kivity changed: What|Removed |Added CC||avi at scylladb dot com --- Comment #1 from Avi Kivity --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #2 from Elmar Stellnberger --- One of the differences I see around the backtrace is that the type source_location has been changed into location_t. I could change this in tree-outof-ssa.c, but in reality the change has been made in many files between gcc 8.3.0 and gcc 9.2.0 (did not find 9.2.1). Another change around the backtrace is that the following code block has been stripped from pass_expand::execute: if (chkp_function_instrumented_p (current_function_decl)) chkp_reset_rtl_bounds (); However the following in input.h would say it were without effect to change location_t: typedef source_location location_t; pass_expand is at the very bottom of the stack trace and if it is really these two lines then great, but it could also be the data passed into this process. The assert that fails is: expr.c:220: gcc_assert (from_mode != BLKmode); // convert_move from_mode originates from 389 copy_rtx(SA.partition_to_pseudo[src]) // insert_part_to_rtx_on_edge 733 g->stack_pop() -> src // procedure eliminate_phi 909 elim_graph g(sa->map) // procedure expand_phi_nodes On the other hand perhaps the issue could not even be resolved with 9.2.0. This was just my first guess.
