[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #14 from Sam James --- Created attachment 57731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57731=edit reduced.i Maybe. I think it could go further even with cvise but I was playing with the sysctls for that ASAN ASLR issue and I think it meant it stopped going further.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Keywords|needs-reduction |needs-bisection --- Comment #27 from Andrew Pinski --- It might be useful to redo the bisect on the testcase in comment #26 at -O1 .
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Attachment #57729|0 |1 is obsolete|| --- Comment #26 from Andrew Pinski --- Created attachment 57730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57730=edit Slightly cleaned up Note p has to be __int128, otherwise it works.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW --- Comment #25 from Andrew Pinski --- .
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Attachment #57727|0 |1 is obsolete|| Attachment #57728|0 |1 is obsolete|| --- Comment #24 from Andrew Pinski --- Created attachment 57729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57729=edit More reduced
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #23 from Andrew Pinski --- Created attachment 57728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57728=edit Reduced slightly more, removes the string compare
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #22 from Andrew Pinski --- Adding -fno-tree-loop-im allows it to work.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #21 from Sam James --- Created attachment 57727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57727=edit reduced.c This aborts for me at >= -O1 but I'm not convinced it's right.
[Bug libstdc++/114387] New: Explicitly declared destructor makes basic_format_context sometimes not movable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114387
Bug ID: 114387
Summary: Explicitly declared destructor makes
basic_format_context sometimes not movable
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
The following code snippet doesn't compile when using libstdc++
(https://godbolt.org/z/x3v44PTbq).
```
#include
#include
#include
#include
template
class sealed_output_iterator {
private:
CharT* p_;
public:
using difference_type = std::ptrdiff_t;
explicit sealed_output_iterator(CharT* p) noexcept : p_{p} {}
sealed_output_iterator(sealed_output_iterator&&) = default;
sealed_output_iterator& operator=(sealed_output_iterator&&) = default;
CharT& operator*() const noexcept
{
return *p_;
}
sealed_output_iterator& operator++() noexcept
{
++p_;
return *this;
}
sealed_output_iterator& operator++(int) noexcept
{
++p_;
return *this;
}
};
static_assert(std::movable>);
static_assert(!std::copyable>);
static_assert(std::output_iterator, const char&>);
static_assert(std::movable,
char>>); // !
```'
The reason seems to be that the explicitly declared destructor suppresses the
implict declaration of move constructor and assignment operator.
https://github.com/gcc-mirror/gcc/blob/c4845edfeaf44756ad9672e8d143f1c8f5c4c0f6/libstdc%2B%2B-v3/include/std/format#L3839
Per https://eel.is/c++draft/format.context, it seems that no specialization
member functions of basic_format_context is suppressed, so perhaps libstdc++
should remove the explicit declaration of the destructor.
However, it's unclear to me whether users are supposed to be able to
default-construct/copy/move basic_format_context objects. So it may be wanted
to delete copy functions, but this may need an LWG issues.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112631, which changed state. Bug 112631 Summary: gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112631 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/112631] gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112631 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 CC||nshead at gcc dot gnu.org --- Comment #3 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/112631] gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112631 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:c4845edfeaf44756ad9672e8d143f1c8f5c4c0f6 commit r14-9530-gc4845edfeaf44756ad9672e8d143f1c8f5c4c0f6 Author: Nathaniel Shead Date: Sat Mar 16 22:00:29 2024 +1100 c++: Fix handling of no-linkage decls for modules When testing the changes for PR c++/112631 we discovered that currently we don't emit definitions of block-scope function declarations if they're not used in the module interface TU, which causes issues if they are used by importers. This patch fixes the handling of no-linkage declarations for C++20. In particular, a type declared in a function with vague linkage or declared in a module CMI could potentially be accessible outside its defining TU, and as such we can't assume that function declarations using that type can never be defined in another TU. A complication with handling this is that we're only strictly interested in declarations with a module CMI, but when parsing the global module fragment we don't yet know whether or not this module will have a CMI until we reach the "export module" line (or not). Since this case is IFNDR anyway (by [basic.def.odr] p11) we just tentatively assume while parsing the GMF that this module will have a CMI; once we see (or don't see) an 'export module' declaration we can commit to that knowledge for future declarations. gcc/cp/ChangeLog: * cp-tree.h (module_maybe_has_cmi_p): New function. * decl.cc (grokfndecl): Mark block-scope functions as public if they could be visible in other TUs. * decl2.cc (no_linkage_error): Don't error for declarations that could be defined in other TUs since C++20. Suppress duplicate errors from 'check_global_declaration'. * tree.cc (no_linkage_check): In relaxed mode, don't consider types in a module CMI to have no linkage. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/linkage-1.C: New test. * g++.dg/modules/block-decl-3.h: New test. * g++.dg/modules/block-decl-3_a.C: New test. * g++.dg/modules/block-decl-3_b.C: New test. * g++.dg/modules/block-decl-3_c.C: New test. * g++.dg/modules/linkage-1_a.C: New test. * g++.dg/modules/linkage-1_b.C: New test. * g++.dg/modules/linkage-1_c.C: New test. * g++.dg/modules/linkage-2.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #23 from g.peterh...@t-online.de --- Hello Matthias, you've given me new ideas. I think we agree on implementing hypot3 using a scaling factor. But the correct value is not yet implemented here either; do you have a suggestion? A version here: https://godbolt.org/z/Gd53cG9YG I've intentionally broken hypot_gp into small pieces so that you can play around with it. This is of course unnecessary for a final version. General * The function must of course work efficiently with all FP types. Questions * Sorting: It is theoretically sufficient to sort the values x,y,z only to the extent that the condition x,y <= z is fulfilled (HYPOT_SORT_FULL). * Accuracy: This is better with fma (HYPOT_FMA). * How do you create the benchmarks? I could do this myself without getting on your nerves. thx Gero
[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > (In reply to Eric Botcazou from comment #7) > > This has introduced regressions on the 12 and 13 branches for x86-64/Linux: > > > > FAIL: g++.dg/opt/pr91838.C -std=c++14 scan-assembler > > pxors+%xmm0,s+%xmm0 > > FAIL: g++.dg/opt/pr91838.C -std=c++17 scan-assembler > > pxors+%xmm0,s+%xmm0 > > FAIL: g++.dg/opt/pr91838.C -std=c++20 scan-assembler > > pxors+%xmm0,s+%xmm0 > > > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/809244.html > > The IR looks like: > _4 = BIT_FIELD_REF ; > _5 = _4 >> 8; > > Well that is "undefined" in the IR. > That requires r14-2821-gd1c072a1c3411a6fe29900750b38210af8451eeb and > r14-2985-g04aa0edcace22a to be backported too. > I guess this testcase should just be xfailed on the GCC 13 and 12 branches > even. Also note bug 91838 comment #17 specifically talks about this could happen even.
[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91838 --- Comment #8 from Andrew Pinski --- (In reply to Eric Botcazou from comment #7) > This has introduced regressions on the 12 and 13 branches for x86-64/Linux: > > FAIL: g++.dg/opt/pr91838.C -std=c++14 scan-assembler > pxors+%xmm0,s+%xmm0 > FAIL: g++.dg/opt/pr91838.C -std=c++17 scan-assembler > pxors+%xmm0,s+%xmm0 > FAIL: g++.dg/opt/pr91838.C -std=c++20 scan-assembler > pxors+%xmm0,s+%xmm0 > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/809244.html The IR looks like: _4 = BIT_FIELD_REF ; _5 = _4 >> 8; Well that is "undefined" in the IR. That requires r14-2821-gd1c072a1c3411a6fe29900750b38210af8451eeb and r14-2985-g04aa0edcace22a to be backported too. I guess this testcase should just be xfailed on the GCC 13 and 12 branches even.
[Bug analyzer/110928] [14 Regression] ICE with -fanalyzer on -Wanalyzer-out-of-bounds checker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110928 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/110902] Missing cast in region_model_manager::maybe_fold_binop on MULT_EXPR by 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110902 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk by the above patch.
[Bug analyzer/111305] [13/14 Regression] GCC Static Analyzer -Wanalyzer-out-of-bounds false postive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111305 David Malcolm changed: What|Removed |Added Priority|P2 |P3 Summary|[13/14 Regression] GCC |[13/14 Regression] GCC |Static Analyzer |Static Analyzer |-Wanalyzer-out-of-bounds FP |-Wanalyzer-out-of-bounds |and ICE problem |false postive --- Comment #4 from David Malcolm --- ICE should be fixed by the above patch. False positive still not fixed.
[Bug analyzer/111441] [14 Regression] ICE generating access diagram, in fold_binary_loc, at fold-const.cc:11580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/110902] Missing cast in region_model_manager::maybe_fold_binop on MULT_EXPR by 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110902 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1579394c9ecf3d1f678daa54b835c7fc3b76fb6d commit r14-9527-g1579394c9ecf3d1f678daa54b835c7fc3b76fb6d Author: David Malcolm Date: Mon Mar 18 18:44:34 2024 -0400 analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902,PR110928,PR111305,PR111441] Various analyzer ICEs in our bugzilla relate to sloppy use of types within bounds-checking. The bounds-checking code works by comparing symbolic *bit* offsets, and we don't have a good user-facing type that can represent such an offset (ptrdiff_type_node is for *byte* offsets). ana::svalue doesn't enforce valid combinations of types for things like binary operations. When I added the access diagrams for GCC 14, this could lead to attempts to generate trees for such svalues, leading to trees with invalid combinations of types (e.g. PLUS_EXPR or MULT_EXPR of incompatible types), leading to ICEs inside the tree folding logic. I tried two approaches to fixing this. My first approach was to fix the type-handling throughout the bounds-checking code to use correct types, using size_type_node for sizes, ptrdiff_type_node for byte offsets, and trying ptrdiff_type_node for bit offsets. I implemented this, and it fixed the crashes, but unfortunately it led to: (a) numerous false negatives from the bounds-checking code, due to it becoming unable to be sure that the accessed offset was beyond the valid bounds, due to the expressions involved gaining complicated sets of nested casts. (b) ugly access diagrams full of nested casts (for capacities, gap measurements, etc) So my second approach, implemented in this patch, is to accept that we don't have a tree type for representing bit offsets. The patch represents bit offsets using "typeless" symbolic values i.e. ones for which get_type () is NULL_TREE, and implements enough support for basic arithemetic as if these are mathematical integers (albeit ones for which concrete values within an expression must fit within a signed wide int). Such values can't be converted to tree, so the patch avoids such conversions, instead implementing a new svalue::maybe_print_for_user for printing them to a pretty_printer. The patch uses ptrdiff_type_node for byte offsets. Doing so fixes the crashes, whilst appearing to preserve the behavior of -Wanalyzer-out-of-bounds in my testing. gcc/analyzer/ChangeLog: PR analyzer/110902 PR analyzer/110928 PR analyzer/111305 PR analyzer/111441 * access-diagram.cc: Include "analyzer/analyzer-selftests.h". (get_access_size_str): Reimplement for conversion of implmementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (remove_ssa_names): Make non-static. (bit_size_expr::get_formatted_str): Rename to... (bit_size_expr::maybe_get_formatted_str): ...this, adding "model" param and converting return type to a unique_ptr. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::print): Rename to... (bit_size_expr::maybe_print_for_user): ...this, adding "model" param and converting return type to bool. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::maybe_get_as_bytes): Add "mgr" param and convert return type from tree to const svalue *; reimplement. (access_range::access_range): Call strip_types when on region_offset intializations. (access_range::get_size): Update for conversion of implementation of bit_size_expr from tree to const svalue &. (access_operation::get_valid_bits): Pass manager to access_range ctor. (access_operation::maybe_get_invalid_before_bits): Likewise. (access_operation::maybe_get_invalid_after_bits): Likewise. (boundaries::add): Likewise. (bit_to_table_map::populate): Add "mgr" param and pass it to access_range ctor. (access_diagram_impl::access_diagram_impl): Pass manager to bit_to_table_map::populate. (access_diagram_impl::maybe_add_gap): Use svalue rather than tree for symbolic bit offsets. Port to new bit_size_expr representation. (access_diagram_impl::add_valid_vs_invalid_ruler): Port
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 112787, which changed state. Bug 112787 Summary: Codegen regression of large GCC vector extensions when enabling SVE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug analyzer/111441] [14 Regression] ICE generating access diagram, in fold_binary_loc, at fold-const.cc:11580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441 --- Comment #6 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1579394c9ecf3d1f678daa54b835c7fc3b76fb6d commit r14-9527-g1579394c9ecf3d1f678daa54b835c7fc3b76fb6d Author: David Malcolm Date: Mon Mar 18 18:44:34 2024 -0400 analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902,PR110928,PR111305,PR111441] Various analyzer ICEs in our bugzilla relate to sloppy use of types within bounds-checking. The bounds-checking code works by comparing symbolic *bit* offsets, and we don't have a good user-facing type that can represent such an offset (ptrdiff_type_node is for *byte* offsets). ana::svalue doesn't enforce valid combinations of types for things like binary operations. When I added the access diagrams for GCC 14, this could lead to attempts to generate trees for such svalues, leading to trees with invalid combinations of types (e.g. PLUS_EXPR or MULT_EXPR of incompatible types), leading to ICEs inside the tree folding logic. I tried two approaches to fixing this. My first approach was to fix the type-handling throughout the bounds-checking code to use correct types, using size_type_node for sizes, ptrdiff_type_node for byte offsets, and trying ptrdiff_type_node for bit offsets. I implemented this, and it fixed the crashes, but unfortunately it led to: (a) numerous false negatives from the bounds-checking code, due to it becoming unable to be sure that the accessed offset was beyond the valid bounds, due to the expressions involved gaining complicated sets of nested casts. (b) ugly access diagrams full of nested casts (for capacities, gap measurements, etc) So my second approach, implemented in this patch, is to accept that we don't have a tree type for representing bit offsets. The patch represents bit offsets using "typeless" symbolic values i.e. ones for which get_type () is NULL_TREE, and implements enough support for basic arithemetic as if these are mathematical integers (albeit ones for which concrete values within an expression must fit within a signed wide int). Such values can't be converted to tree, so the patch avoids such conversions, instead implementing a new svalue::maybe_print_for_user for printing them to a pretty_printer. The patch uses ptrdiff_type_node for byte offsets. Doing so fixes the crashes, whilst appearing to preserve the behavior of -Wanalyzer-out-of-bounds in my testing. gcc/analyzer/ChangeLog: PR analyzer/110902 PR analyzer/110928 PR analyzer/111305 PR analyzer/111441 * access-diagram.cc: Include "analyzer/analyzer-selftests.h". (get_access_size_str): Reimplement for conversion of implmementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (remove_ssa_names): Make non-static. (bit_size_expr::get_formatted_str): Rename to... (bit_size_expr::maybe_get_formatted_str): ...this, adding "model" param and converting return type to a unique_ptr. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::print): Rename to... (bit_size_expr::maybe_print_for_user): ...this, adding "model" param and converting return type to bool. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::maybe_get_as_bytes): Add "mgr" param and convert return type from tree to const svalue *; reimplement. (access_range::access_range): Call strip_types when on region_offset intializations. (access_range::get_size): Update for conversion of implementation of bit_size_expr from tree to const svalue &. (access_operation::get_valid_bits): Pass manager to access_range ctor. (access_operation::maybe_get_invalid_before_bits): Likewise. (access_operation::maybe_get_invalid_after_bits): Likewise. (boundaries::add): Likewise. (bit_to_table_map::populate): Add "mgr" param and pass it to access_range ctor. (access_diagram_impl::access_diagram_impl): Pass manager to bit_to_table_map::populate. (access_diagram_impl::maybe_add_gap): Use svalue rather than tree for symbolic bit offsets. Port to new bit_size_expr representation. (access_diagram_impl::add_valid_vs_invalid_ruler): Port
[Bug analyzer/111305] [13/14 Regression] GCC Static Analyzer -Wanalyzer-out-of-bounds FP and ICE problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111305 --- Comment #3 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1579394c9ecf3d1f678daa54b835c7fc3b76fb6d commit r14-9527-g1579394c9ecf3d1f678daa54b835c7fc3b76fb6d Author: David Malcolm Date: Mon Mar 18 18:44:34 2024 -0400 analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902,PR110928,PR111305,PR111441] Various analyzer ICEs in our bugzilla relate to sloppy use of types within bounds-checking. The bounds-checking code works by comparing symbolic *bit* offsets, and we don't have a good user-facing type that can represent such an offset (ptrdiff_type_node is for *byte* offsets). ana::svalue doesn't enforce valid combinations of types for things like binary operations. When I added the access diagrams for GCC 14, this could lead to attempts to generate trees for such svalues, leading to trees with invalid combinations of types (e.g. PLUS_EXPR or MULT_EXPR of incompatible types), leading to ICEs inside the tree folding logic. I tried two approaches to fixing this. My first approach was to fix the type-handling throughout the bounds-checking code to use correct types, using size_type_node for sizes, ptrdiff_type_node for byte offsets, and trying ptrdiff_type_node for bit offsets. I implemented this, and it fixed the crashes, but unfortunately it led to: (a) numerous false negatives from the bounds-checking code, due to it becoming unable to be sure that the accessed offset was beyond the valid bounds, due to the expressions involved gaining complicated sets of nested casts. (b) ugly access diagrams full of nested casts (for capacities, gap measurements, etc) So my second approach, implemented in this patch, is to accept that we don't have a tree type for representing bit offsets. The patch represents bit offsets using "typeless" symbolic values i.e. ones for which get_type () is NULL_TREE, and implements enough support for basic arithemetic as if these are mathematical integers (albeit ones for which concrete values within an expression must fit within a signed wide int). Such values can't be converted to tree, so the patch avoids such conversions, instead implementing a new svalue::maybe_print_for_user for printing them to a pretty_printer. The patch uses ptrdiff_type_node for byte offsets. Doing so fixes the crashes, whilst appearing to preserve the behavior of -Wanalyzer-out-of-bounds in my testing. gcc/analyzer/ChangeLog: PR analyzer/110902 PR analyzer/110928 PR analyzer/111305 PR analyzer/111441 * access-diagram.cc: Include "analyzer/analyzer-selftests.h". (get_access_size_str): Reimplement for conversion of implmementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (remove_ssa_names): Make non-static. (bit_size_expr::get_formatted_str): Rename to... (bit_size_expr::maybe_get_formatted_str): ...this, adding "model" param and converting return type to a unique_ptr. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::print): Rename to... (bit_size_expr::maybe_print_for_user): ...this, adding "model" param and converting return type to bool. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::maybe_get_as_bytes): Add "mgr" param and convert return type from tree to const svalue *; reimplement. (access_range::access_range): Call strip_types when on region_offset intializations. (access_range::get_size): Update for conversion of implementation of bit_size_expr from tree to const svalue &. (access_operation::get_valid_bits): Pass manager to access_range ctor. (access_operation::maybe_get_invalid_before_bits): Likewise. (access_operation::maybe_get_invalid_after_bits): Likewise. (boundaries::add): Likewise. (bit_to_table_map::populate): Add "mgr" param and pass it to access_range ctor. (access_diagram_impl::access_diagram_impl): Pass manager to bit_to_table_map::populate. (access_diagram_impl::maybe_add_gap): Use svalue rather than tree for symbolic bit offsets. Port to new bit_size_expr representation. (access_diagram_impl::add_valid_vs_invalid_ruler): Port
[Bug analyzer/110928] [14 Regression] ICE with -fanalyzer on -Wanalyzer-out-of-bounds checker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110928 --- Comment #1 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1579394c9ecf3d1f678daa54b835c7fc3b76fb6d commit r14-9527-g1579394c9ecf3d1f678daa54b835c7fc3b76fb6d Author: David Malcolm Date: Mon Mar 18 18:44:34 2024 -0400 analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902,PR110928,PR111305,PR111441] Various analyzer ICEs in our bugzilla relate to sloppy use of types within bounds-checking. The bounds-checking code works by comparing symbolic *bit* offsets, and we don't have a good user-facing type that can represent such an offset (ptrdiff_type_node is for *byte* offsets). ana::svalue doesn't enforce valid combinations of types for things like binary operations. When I added the access diagrams for GCC 14, this could lead to attempts to generate trees for such svalues, leading to trees with invalid combinations of types (e.g. PLUS_EXPR or MULT_EXPR of incompatible types), leading to ICEs inside the tree folding logic. I tried two approaches to fixing this. My first approach was to fix the type-handling throughout the bounds-checking code to use correct types, using size_type_node for sizes, ptrdiff_type_node for byte offsets, and trying ptrdiff_type_node for bit offsets. I implemented this, and it fixed the crashes, but unfortunately it led to: (a) numerous false negatives from the bounds-checking code, due to it becoming unable to be sure that the accessed offset was beyond the valid bounds, due to the expressions involved gaining complicated sets of nested casts. (b) ugly access diagrams full of nested casts (for capacities, gap measurements, etc) So my second approach, implemented in this patch, is to accept that we don't have a tree type for representing bit offsets. The patch represents bit offsets using "typeless" symbolic values i.e. ones for which get_type () is NULL_TREE, and implements enough support for basic arithemetic as if these are mathematical integers (albeit ones for which concrete values within an expression must fit within a signed wide int). Such values can't be converted to tree, so the patch avoids such conversions, instead implementing a new svalue::maybe_print_for_user for printing them to a pretty_printer. The patch uses ptrdiff_type_node for byte offsets. Doing so fixes the crashes, whilst appearing to preserve the behavior of -Wanalyzer-out-of-bounds in my testing. gcc/analyzer/ChangeLog: PR analyzer/110902 PR analyzer/110928 PR analyzer/111305 PR analyzer/111441 * access-diagram.cc: Include "analyzer/analyzer-selftests.h". (get_access_size_str): Reimplement for conversion of implmementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (remove_ssa_names): Make non-static. (bit_size_expr::get_formatted_str): Rename to... (bit_size_expr::maybe_get_formatted_str): ...this, adding "model" param and converting return type to a unique_ptr. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::print): Rename to... (bit_size_expr::maybe_print_for_user): ...this, adding "model" param and converting return type to bool. Update for conversion of implementation of bit_size_expr from tree to const svalue &. Use svalue::maybe_print_for_user rather than tree printing routines. (bit_size_expr::maybe_get_as_bytes): Add "mgr" param and convert return type from tree to const svalue *; reimplement. (access_range::access_range): Call strip_types when on region_offset intializations. (access_range::get_size): Update for conversion of implementation of bit_size_expr from tree to const svalue &. (access_operation::get_valid_bits): Pass manager to access_range ctor. (access_operation::maybe_get_invalid_before_bits): Likewise. (access_operation::maybe_get_invalid_after_bits): Likewise. (boundaries::add): Likewise. (bit_to_table_map::populate): Add "mgr" param and pass it to access_range ctor. (access_diagram_impl::access_diagram_impl): Pass manager to bit_to_table_map::populate. (access_diagram_impl::maybe_add_gap): Use svalue rather than tree for symbolic bit offsets. Port to new bit_size_expr representation. (access_diagram_impl::add_valid_vs_invalid_ruler): Port
[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 Eric Botcazou changed: What|Removed |Added Resolution|FIXED |--- CC||ebotcazou at gcc dot gnu.org Status|RESOLVED|REOPENED --- Comment #7 from Eric Botcazou --- This has introduced regressions on the 12 and 13 branches for x86-64/Linux: FAIL: g++.dg/opt/pr91838.C -std=c++14 scan-assembler pxors+%xmm0,s+%xmm0 FAIL: g++.dg/opt/pr91838.C -std=c++17 scan-assembler pxors+%xmm0,s+%xmm0 FAIL: g++.dg/opt/pr91838.C -std=c++20 scan-assembler pxors+%xmm0,s+%xmm0 https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/809244.html
[Bug middle-end/114348] Corrupt SARIF output on stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-03-18 --- Comment #3 from David Malcolm --- Thanks for reporting this. Note that -fanalyzer isn't needed to reproduce this problem, e.g. on trunk with: $ (./xgcc -B. -fdiagnostics-format=sarif-stderr -c test.c 2>&1) | python -m json.tool Extra data: line 24 column 1 (char 1839) Also affects -fdiagnostics-format=json-stderr. fnotice (stderr, ...) is used in ~150 places in trunk. I'm looking at ways of fixing this (perhaps by having fnotice bail out early on these machine-readable stderr formats when outputting to stderr).
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 --- Comment #6 from Andrew Pinski --- Note after my r13-7928-gcda1992a56779e5c60a70f251542a6f662fdfa60 patch we get from phiopt: ``` if (a.1_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: _3 = MAX_EXPR ; [local count: 1073741824]: # _2 = PHI <_3(3), 0(2)> ``` Which is correct. And then later on we get: ``` if (a.1_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870912]: [local count: 1073741824]: # _2 = PHI Note the trunk we get finally: ``` _10 = ~a.1_1; _11 = g_6 & _10; ``` Which is the best (well really `a < g` but that is a different known issue).
[Bug tree-optimization/111331] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331 Andrew Pinski changed: What|Removed |Added CC||patrick at rivosinc dot com --- Comment #17 from Andrew Pinski --- *** Bug 114386 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Yes this turns out to be a dup of bug 111331 which is already fixed on the GCC 13 branch . Tested the GCC 13 branch with revision right before r13-7928-gcda1992a56779e5c60a70f251542a6f662fdfa60 and it and it was broken before but it is working afterwards. This is a latent bug for a few years now even. *** This bug has been marked as a duplicate of bug 111331 ***
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 --- Comment #4 from Patrick O'Neill --- (In reply to Patrick O'Neill from comment #0) > ... > Issue is not present when targeting risc-v. This was in reference to tip-of-tree gcc - forgot to update this when I determined the upper bound of the regression. RISC-V is also likely affected in version 10/latent. Also forgot to mention - found via fuzzer. Thanks for the quick triage as always Andrew.
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- This is all quite confusing. First, who is the addressee of the FIXME? gfortran developers or users? And can someone explain this special distinguishment is made (F2008 or not)? Other compilers tested seem to be "uncomfortable" with Dominique's example in comment#2, as they are unable to recognize that two() is not a statement function. Even with an added statement in front. Can anyone point to the exact formulation in the standard that clarifies the situation? The first part of the error message seems to be emitted in any case. Thus, the second part appears to be aiming to help the user to fix his/her code. But is it the right recommendation?
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 --- Comment #3 from Andrew Pinski --- Note the reason why it might work on the trunk is due to replacement of `MAX_EXPR ` with `c.0_1 | a.2_2` so it might be a latent bug still on the trunk ...
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Known to work||14.0 Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- PHIOPT goes from: ``` if (a.1_1 != 0) goto ; [INV] else goto ; [INV] : _5 = MAX_EXPR ; iftmp.0_12 = (int) _5; : # iftmp.0_8 = PHI ``` to: ``` _5 = MAX_EXPR ; iftmp.0_8 = 0; ``` Due to: ``` PHI iftmp.0_8 changed to factor conversion out from COND_EXPR. ``` Which seems not to be done on the trunk ... Mine due it being phiopt.
[Bug tree-optimization/114386] [11/12/13 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386
Andrew Pinski changed:
What|Removed |Added
Summary|[11/12 Regression] |[11/12/13 Regression]
|Miscompile at -O1 |Miscompile at -O1
Last reconfirmed||2024-03-18
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Actually this still fails in GCC 13 with a slightly different testcase:
```
_Bool a, c = 1;
int b, d;
int main() {
_Bool g = c;
d = !a ? ({ c > a ? c : a; }) : 0;
__builtin_printf("%x, %x\n", d, (int)g);
}
```
[Bug tree-optimization/114386] [11/12 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |11.5 Component|target |tree-optimization Known to fail||13.1.0 Summary|[10/11/12 Regression] |[11/12 Regression] |Miscompile at -O1 |Miscompile at -O1
[Bug target/114386] New: [10/11/12 Regression] Miscompile at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114386
Bug ID: 114386
Summary: [10/11/12 Regression] Miscompile at -O1
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
int printf(const char *, ...);
_Bool a, c = 1;
int b, d;
int main() {
_Bool g = c;
d = !a ? ({ c > a ? c : a; }) : 0;
printf("%x\n", d);
}
Commands:
> gcc -O0 red.c -o red.o
> ./red.o
0
> gcc -O1 red.c -o red.o
> ./red.o
1
> gcc -O2 red.c -o red.o
> ./red.o
0
> gcc -O3 red.c -o red.o
> ./red.o
1
Tested/discovered on x86 - gcc v11.4.0.
Issue is not present when targeting risc-v.
Godbolt shows it's a regression starting at 10.1 (with -O1) and resolved as of
13.1.
Godbolt: https://godbolt.org/z/q4P9xs5dx
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 --- Comment #8 from Roland Illig --- (In reply to Jakub Jelinek from comment #7) > (In reply to Jerry DeLisle from comment #5) > > Another way is to build an error message with snprintf for example and use > > that string in the error message. > > That is translation unfriendly. And the German translator (me) is particularly picky about these topics, so whenever you assemble diagnostics using snprintf, you'll get a new bug report from me; see #114364 for an example.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #8 from Antoni --- Created attachment 57726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57726=edit Reproducer using union I tried switching to a union and I still get the same error. A union is used by std::optional, so I would assume that this should work. Or is copying uninitialized memory via a union also UB?
[Bug tree-optimization/114385] -Wrestrict false positive creating std::string from iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385 --- Comment #3 from Andrew Pinski --- I think this might be due to changes to std::copy which tries to skip memcpy if it is only one element. My bet is maybe std::copy could add `if (end < begin) __builtin_unreachable();` in it and the code would be better optimized but then some warnings might not show up. Basically if I read this code correctly, the preconditions for this function is both begin and end are proper iterators and that `end >= begin` is holds true. What is happening is GCC gets `end - begin < 2` but then does not know if that could be negative and all things break lose.
[Bug tree-optimization/114385] -Wrestrict false positive creating std::string from iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385 --- Comment #2 from Andrew Pinski --- This also works: if (end < begin) __builtin_unreachable();
[Bug tree-optimization/114385] -Wrestrict false positive creating std::string from iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385 --- Comment #1 from Andrew Pinski --- Another workaround is to add: if (end-begin < 0) __builtin_unreachable(); I notice that this is not the same as: [[assume(end-begin >= 0)]]; but that seems related to another bug report dealing with how we don't do IPA_SRA over assume statements yet.
[Bug c++/114385] New: -Wrestrict false positive creating std::string from iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385
Bug ID: 114385
Summary: -Wrestrict false positive creating std::string from
iterators
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wsf at fultondesigns dot co.uk
Target Milestone: ---
Observed in gcc-13.1.0, 13.2.0, gcc-14 (gcc-trunk-20240318).
Minimal testcase:
#include
template< class String_type >
String_type substitute_esc_chars( typename String_type::const_iterator
begin,
typename String_type::const_iterator end )
{
if( end - begin < 2 ) return String_type( begin, end );
//if( end - begin < 2 ) return String_type(1, *begin); // workaround 1
//if( end - begin == 0 || end - begin == 1 ) return String_type( begin,
end ); // workaround 2
String_type result;
result.resize( end - begin );
std::copy(begin, end, result.begin());
return result;
}
int main() {
std::string ss[] = {"hi", "a"};
for (const std::string& s : ss)
substitute_esc_chars(s.begin(), s.end());
return 0;
}
gcc-13.1 version info...
$ g++-13 -Wall -O1 -D_GLIBCXX_ASSERTIONS runme.cxx -o runme
In file included from /usr/include/c++/13/string:42,
from runme.cxx:1:
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/include/c++/13/bits/basic_string.h:420:21,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy_chars(_CharT*, const _CharT*, const _CharT*) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/basic_string.h:474:16,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy_chars(_CharT*, const_iterator, const_iterator) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/basic_string.h:463:22,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag)
[with _FwdIterator = __gnu_cxx::__normal_iterator >; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/basic_string.tcc:243:21,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&) [with
_InputIterator = __gnu_cxx::__normal_iterator >; = void; _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/basic_string.h:753:16,
inlined from ‘String_type substitute_esc_chars(typename
String_type::const_iterator, typename String_type::const_iterator) [with
String_type = std::__cxx11::basic_string]’ at runme.cxx:8:62:
/usr/include/c++/13/bits/char_traits.h:445:56: warning: ‘void*
__builtin_memcpy(void*, const void*, long unsigned int)’ accessing
9223372036854775808 or more bytes at offsets 0 and 0 may overlap up to
9223372036854775809 bytes at offset -1 [-Wrestrict]
445 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
$ g++-13 -v
Using built-in specs.
COLLECT_GCC=g++-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.1.0-8ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --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 --disable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~18.04)
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #19 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:b96c5436880d7926299314a33c953171082ab59e
commit r14-9523-gb96c5436880d7926299314a33c953171082ab59e
Author: Uros Bizjak
Date: Mon Mar 18 20:40:29 2024 +0100
i386: Unify {general,timode}_scalar_chain::convert_op [PR111822]
Recent PR111822 fix implemented REG_EH_REGION note copying to a STV
converted
preload instruction in general_scalar_chain::convert_op. However, the same
issue remains in timode_scalar_chain::convert_op. Instead of copying the
newly introduced code to timode_scalar_chain::convert_op, the patch unifies
both functions to a common function.
PR target/111822
gcc/ChangeLog:
* config/i386/i386-features.cc (smode_convert_cst): New function
to handle SImode, DImode and TImode immediates, generalized from
timode_convert_cst.
(timode_convert_cst): Remove.
(scalar_chain::convert_op): Unify from
general_scalar_chain::convert_op and
timode_scalar_chain::convert_op.
(general_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_insn): Update the call to
renamed timode_convert_cst.
* config/i386/i386-features.h (class scalar_chain):
Redeclare convert_op as protected class member.
(class general_calar_chain): Remove convert_op.
(class timode_scalar_chain): Ditto.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr111822.C (dg-do): Compile only for ia32
targets.
(dg-options): Add -march=x86-64.
[Bug testsuite/114384] Use of `target c++98/c++11/c++20` etc. is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #4 from Jonathan Wakely ---
Libstdc++ uses the same effective-target keywords, but uses its own variables
to override the defaults:
# Allow v3_std_list to be set in configuration files, e.g., ~/.dejagnurc
if ![info exists v3_std_list] {
set v3_std_list { }
}
# Allow v3_std_list to be set from the environment.
if [info exists env(GLIBCXX_TESTSUITE_STDS)] {
set v3_std_list [split $env(GLIBCXX_TESTSUITE_STDS) ","]
}
and defaults to -std=gnu++NN unless { dg-add-options strict_std } is present:
# If the testcase specifies a standard, use that one.
# If not, run it under several standards, allowing GNU extensions
# unless strict_std is requested.
if ![search_for $test "// \{ dg-*options*-std=*++"] {
if [search_for $test "{ dg-add-options strict_std }"] {
set std_prefix "-std=c++"
} else {
set std_prefix "-std=gnu++"
}
# See above for the initial value of this list.
global v3_std_list
if { [llength $v3_std_list] > 0 } {
set std_list $v3_std_list
} else {
# If the test requires a newer C++ version than which
# is tested by default, use that C++ version for that
# single test.
# These should be adjusted whenever the default -std is
# updated or newer C++ effective target is added.
set default_std 17
set max_std 26
set min_std [v3-minimum-std $test $default_std $max_std]
if { $min_std > $default_std } {
set std_list $min_std
if { $min_std != $max_std } {
# Also test the latest version.
lappend std_list "$max_std"
}
} else {
# Only run each test once with the default -std option.
# This avoids increasing the run time for most testers.
# Libstdc++ developers can override this with v3_std_list.
set std_list $default_std
}
}
For libstdc++ this is covered (briefly) in
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
and https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.new_tests
[Bug testsuite/114384] Use of `target c++98/c++11/c++20` etc. is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Andrew Pinski from comment #0)
> > and even how to describe the above
> > would be very useful. Do we need 3 testcases, one for pre C++11, one for
> > C++11/C++14 and one for C++17+ ?
>
> No, you could use { target { c++11 && c++14_down } }
And this should be equivalent: { target c++11_only c++14_only }
[Bug testsuite/114384] Use of `target c++98/c++11/c++20` etc. is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #2 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #0)
> While trying to understand how to use `{ target c++20 }` option to dg-do I
> noticed it is not documented in the internals manual (sourcebuild.texi)
> while all other target support options are there.
>
> It would be useful to have this documented because the rules seems to get
> complex if you have a testcase which says works one way for C++11 to C++14
> but works another way for C++98 and C++17+.
That seems extremely unlikely in practice :-)
>
> Where is it valid to place these targets
It's an effective-target keyword, so you can use it anywhere those are used.
> and even how to describe the above
> would be very useful. Do we need 3 testcases, one for pre C++11, one for
> C++11/C++14 and one for C++17+ ?
No, you could use { target { c++11 && c++14_down } }
c++NN means that standard and later
c++NN_down means that standard and earlier
c++NN_only means exactly what it says
The current test flags are inspected to see which -std is in effect for the
test, and if no -std is present, it assumes the default set by:
set cxx_default "c++17"
Those effective target keywords check the -std option in effect and decide
whether the test should be run or skipped.
By default, each g++ test is run multiple times with different -std options,
which will get compared to the effective-target keywords each time. The set of
tests to run is controllable by the user via:
set gpp_compile_options ""
# Allow gpp_std_list to be set in configuration files, e.g., ~/.dejagnurc
if ![info exists gpp_std_list] {
set gpp_std_list { }
}
# Allow gpp_std_list to be set from the environment.
if [info exists env(GXX_TESTSUITE_STDS)] {
set gpp_std_list [split $env(GXX_TESTSUITE_STDS) ","]
}
That gpp_std_list is used by g++-dg-runtest in g++-dg.exp, and if the list is
empty, the default set depends on the test:
# See g++.exp for the initial value of this list.
global gpp_std_list
if { [llength $gpp_std_list] > 0 } {
set std_list $gpp_std_list
} else {
# If the test requires a newer C++ version than which
# is tested by default, use that C++ version for that
# single test. Or if a test checks behavior specifically for
# one C++ version, include that version in the default list.
# These should be adjusted whenever the default std_list is
# updated or newer C++ effective target is added.
if [search_for $test "\{ dg-do * \{ target c++23"] {
set std_list { 23 26 }
} elseif [search_for $test "\{ dg-do * \{ target c++26"] {
set std_list { 26 }
} elseif [search_for $test "c++11_only"] {
set std_list { 98 11 14 20 }
} else {
set std_list { 98 14 17 20 }
}
}
(In reply to Andrew Pinski from comment #1)
> Oh and how it interacts with -std=gnu++17 vs -std=c++17 (etc.).
For g++ that seems to be controlled by the presence of any dg-options
directive:
if [search_for $test "dg-options"] {
set std_prefix "-std=gnu++"
} else {
set std_prefix "-std=c++"
}
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 --- Comment #7 from Jakub Jelinek --- (In reply to Jerry DeLisle from comment #5) > Another way is to build an error message with snprintf for example and use > that string in the error message. That is translation unfriendly.
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012
--- Comment #6 from Jakub Jelinek ---
At least in the middle-end or C/C++ FEs such diagnostics is done with
error{,_at}/warning{,_at} etc. followed by inform, for warning inform only
called if warning* returned true, and wrapped with auto_diagnostic_group d;
because it is really just one error (or warning) with extra explanation, not
two separate errors.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #32 from Edwin Lu --- riscv patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647963.html tested with rv64gcv-lp64d. waiting on precommit testing results
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I have not looked at this in detail. Generally, you can do conditional errors depending on what -std=f a user specifies at compile time. So theoretically you can do two different errors depending on these options. Also look in the codes for examples of 'notify' or 'notification' to see ways to do these things. Another way is to build an error message with snprintf for example and use that string in the error message.
[Bug testsuite/114384] Use of `target c++98/c++11/c++20` etc. is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384 --- Comment #1 from Andrew Pinski --- Oh and how it interacts with -std=gnu++17 vs -std=c++17 (etc.).
[Bug testsuite/114384] New: Use of `target c++98/c++11/c++20` etc. is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
Bug ID: 114384
Summary: Use of `target c++98/c++11/c++20` etc. is not
documented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: trivial
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While trying to understand how to use `{ target c++20 }` option to dg-do I
noticed it is not documented in the internals manual (sourcebuild.texi) while
all other target support options are there.
It would be useful to have this documented because the rules seems to get
complex if you have a testcase which says works one way for C++11 to C++14 but
works another way for C++98 and C++17+.
Where is it valid to place these targets and even how to describe the above
would be very useful. Do we need 3 testcases, one for pre C++11, one for
C++11/C++14 and one for C++17+ ?
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 --- Comment #8 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3be2b8f475f22c531d6cef1b041c0573b3ea5133 commit r14-9522-g3be2b8f475f22c531d6cef1b041c0573b3ea5133 Author: Harald Anlauf Date: Mon Mar 18 19:36:59 2024 +0100 Fortran: error recovery in frontend optimization [PR103715] gcc/fortran/ChangeLog: PR fortran/103715 * frontend-passes.cc (check_externals_expr): Prevent invalid read in case of mismatch of external subroutine with function. gcc/testsuite/ChangeLog: PR fortran/103715 * gfortran.dg/pr103715.f90: New test.
[Bug c++/114383] Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383 --- Comment #4 from Andrew Pinski --- https://github.com/llvm/llvm-project/commit/aaa79a59317f859485d701d1eb68ac4cb213e1d1
[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286 --- Comment #5 from David Malcolm --- Aha - thanks! Am working on a fix.
[Bug c++/114383] Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383 Andrew Pinski changed: What|Removed |Added Status|SUSPENDED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100825
[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
--- Comment #4 from Jakub Jelinek ---
No, the documentation is correct.
It describes all that the user cares about, what arguments should be passed to
it when it is called.
Under the hood, it is then either optimized into __atomic_load_{1,2,4,8,16} (or
similarly for other atomic APIs), or to the generic one, based on the type.
And, for the generic one the size argument is added because the type is
irrelevant after the lowering.
See c-family/c-common.cc (resolve_overloaded_builtin) for details.
[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286 --- Comment #3 from David Malcolm --- Looking at https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#index-_005f_005fatomic_005fload I see this signature for __atomic_load with 3 arguments: Built-in Function: void __atomic_load (type *ptr, type *ret, int memorder) and that's what I tried to implement in r14-1497-gef768035ae8090 in kf.cc's class kf_atomic_load. However, looking at the gimple, I see this call: __atomic_load (128, , , 0); and sync-builtins.def has this: DEF_SYNC_BUILTIN (BUILT_IN_ATOMIC_LOAD, "__atomic_load", BT_FN_VOID_SIZE_CONST_VPTR_PTR_INT, ATTR_NOTHROWCALL_LEAF_LIST) so presumably the documentation for __atomic_load is wrong. Presumably the signature should be: void __atomic_load (size_t sz, const void *src, void *dst, int memorder);
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #6) > (In reply to anlauf from comment #5) > > Obvious fix for the invalid read (untested): > > > If it test OK feel free to commit. Unsurprisingly it regtests fine :-) Will commit soon.
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to anlauf from comment #5) > Obvious fix for the invalid read (untested): > If it test OK feel free to commit.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- Let me look into that for GCC 15. Note libobjc is not used by many folks even the GNUStep folks don't use it any more ...
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Obvious fix for the invalid read (untested): diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc index 06dfa1a3232..3c06018fdbb 100644 --- a/gcc/fortran/frontend-passes.cc +++ b/gcc/fortran/frontend-passes.cc @@ -5807,6 +5807,9 @@ check_externals_expr (gfc_expr **ep, int *walk_subtrees ATTRIBUTE_UNUSED, if (e->expr_type != EXPR_FUNCTION) return 0; + if (e->symtree && e->symtree->n.sym->attr.subroutine) +return 0; + sym = e->value.function.esym; if (sym == NULL) return 0;
[Bug c++/114383] Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 Last reconfirmed||2024-03-18 --- Comment #3 from Andrew Pinski --- Let's keep this suspended until the clang folks decide if this was on purpose or not.
[Bug fortran/114373] [12/13 Regression] BLOCK construct not correctly analyzed with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114373 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|BLOCK construct not |[12/13 Regression] BLOCK |correctly analyzed with |construct not correctly |-fopenmp|analyzed with -fopenmp Known to work||10.5.0, 11.4.1, 14.0, 9.5.0 Last reconfirmed||2024-03-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 Known to fail||12.3.1, 13.2.1 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Appears to be fixed on 14-mainline. Can we identify the fix for it?
[Bug c++/114383] Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/itanium- ||cxx-abi/cxx-abi/issues/47 --- Comment #2 from Andrew Pinski --- I think it is https://github.com/itanium-cxx-abi/cxx-abi/issues/47 but the ABI issue is still open ...
[Bug c++/114383] Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383 --- Comment #1 from Andrew Pinski --- https://github.com/llvm/llvm-project/commit/4b163e343cfa54c8d55c9da73c70d58f55ea9df2
[Bug c++/114383] New: Wrong std::enable_if mangling ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114383
Bug ID: 114383
Summary: Wrong std::enable_if mangling ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Following this bug on clang side:
https://github.com/llvm/llvm-project/issues/85656 where apparently clang folks
claim they fixed a mangling issue, I found out that clang >= 18 and gcc now
differ in mangling some std::enable_if expression. I am opening this bug to
track an potential mangling change needed on gcc side to be on par with the
current clang logic. I definitely don't have the knowledge to say which
mangling is correct, so I am going to trust clang folks who apparently changed
on purpose ;)
This snippet:
#include
template class SomeCondition
{
public:
static constexpr bool value = true;
};
template ::value,
int>::type = 0> void SomeFunction(const T&);
void f()
{
SomeFunction(0);
}
results in mangling the call to "SomeFunction" as
_Z12SomeFunctionIiTnNSt9enable_ifIXsr13SomeConditionIT_EE5valueEiE4typeELi0EEvRKS1_
by clang >= 18 while gcc for now mangles it as _Z12SomeFunctionIiLi0EEvRKT_.
Does gcc need any long term mangling change to handle this case ?
[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks; taking a look.
[Bug target/113960] [11 Regression] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 --- Comment #20 from mfarca --- Thank you for your help Jonathan.
[Bug modula2/114380] Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/114380] Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380 --- Comment #4 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:d2029bbc69df7341775faf6cf1aa13d978c223a1 commit r14-9520-gd2029bbc69df7341775faf6cf1aa13d978c223a1 Author: Gaius Mulley Date: Mon Mar 18 16:40:35 2024 + PR modula2/114380 Incorrect type specified in an error message This patch corrects an error message relating to a variable of a SET type. The bugfix is not to skip over set types (in GetLowestType). gcc/m2/ChangeLog: PR modula2/114380 * gm2-compiler/SymbolTable.mod (GetLowestType): Do not skip over a set type, but return sym. gcc/testsuite/ChangeLog: PR modula2/114380 * gm2/pim/fail/badset7.mod: New test. Signed-off-by: Gaius Mulley
[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #18 from Uroš Bizjak ---
When we split
(insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
(mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct
SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84
{*movdi_internal}
(expr_list:REG_EH_REGION (const_int -11 [0xfff5])
into
(insn 104 36 37 10 (set (subreg:V2DI (reg:DI 124) 0)
(vec_concat:V2DI (mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6
MEM[(struct SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])
(const_int 0 [0]))) "test.C":22:42 -1
(nil)))
(insn 37 104 105 10 (set (subreg:V2DI (reg:DI 104 [ _18 ]) 0)
(subreg:V2DI (reg:DI 124) 0)) "test.C":22:42 2024 {movv2di_internal}
(expr_list:REG_EH_REGION (const_int -11 [0xfff5])
(nil)))
we must copy the REG_EH_REGION note to the first insn and split the block
after the newly added insn. The REG_EH_REGION on the second insn will be
removed later since it no longer traps.
gcc/ChangeLog:
* config/i386/i386-features.cc
(general_scalar_chain::convert_op): Handle REG_EH_REGION note.
(convert_scalars_to_vector): Ditto.
* config/i386/i386-features.h (class scalar_chain): New
memeber control_flow_insns.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr111822.C: New test.
[Bug pch/114381] (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114381 --- Comment #1 from Andrew Pinski --- *** Bug 114382 has been marked as a duplicate of this bug. ***
[Bug pch/114382] (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114382 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 114381 ***
[Bug pch/114382] New: (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114382 Bug ID: 114382 Summary: (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: roland.mainz at nrubsig dot org Target Milestone: --- Building gcc from scratch crashes generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch. Note while the crash happens on Cygwin it looks like a *generic* memory corruption issue. Versions: $ gcc --version gcc (GCC) 11.4.0 $ uname -a CYGWIN_NT-10.0-19045 wingrendel02 3.5.1-1.x86_64 2024-02-27 11:54 UTC x86_64 Cygwin Steps to reproduce: - Note that this happens only SPORADICALLY - Cygwin is NOT Windows, Cygwin is a POSIX layer on top of Win32 and has it's own memory allocator, which works more like Linux/UNIX than Win32. So the IRC comments about memory layout vs. Windows should be taken with a grain/mountain of salt - Compile with: # crash happens with "releases/gcc-13.1.0" and "releases/gcc-13.2.0"! $ git clone -b releases/gcc-13.1.0 --single-branch ../gcc.bundle $ cd gcc $ configure $ yes | make -j8 all Log output: snip /cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc -B/cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc -nostdinc++ -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/libsupc++ -O2 -g /cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86_64-pc-cygwin/bits/stdtr1c++.h.gch/O2g.gch mkdir -p ./x86_64-pc-cygwin/bits/extc++.h.gch /cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc -B/cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc -nostdinc++ -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/libsupc++ -O2 -g /cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/include/precompiled/extc++.h -o x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch *** starting 'dumper "M:/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/cc1plus.exe" 8244' for pid 0, tid 1164 make[5]: *** [Makefile:1938: x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch] Error 1 make[5]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include' make[4]: *** [Makefile:576: all-recursive] Error 1 make[4]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3' make[3]: *** [Makefile:501: all] Error 2 make[3]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3' make[2]: *** [Makefile:18286: all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc' make[1]: *** [Makefile:25094: stage1-bubble] Error 2 make[1]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc' make: *** [Makefile:1080: all] Error 2 snip Stack trace: snip roland_mainz@wingrendel02 /cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include $ gdb ../../../host-x86_64-pc-cygwin/gcc/cc1plus.exe cc1plus.exe.core GNU gdb (GDB) (Cygwin 13.2-1) 13.2 [snip] [New Thread 0x48c] [New Thread 0x18c4] [New Thread 0x1370] #0 0x7ffaa106d664 in ntdll!ZwDelayExecution () from C:/Windows/SYSTEM32/ntdll.dll [Current thread is 1 (Thread 0x48c)] (gdb) bt #0 0x7ffaa106d664 in ntdll!ZwDelayExecution () from C:/Windows/SYSTEM32/ntdll.dll #1 0x7ffa9ec9b62e in SleepEx () from C:/Windows/System32/KERNELBASE.dll #2 0x7ffa9429e567 in secure_getenv () from C:/cygwin64/bin/cygwin1.dll #3 0x7ffa942a01cc in secure_getenv ()
[Bug pch/114381] New: (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114381 Bug ID: 114381 Summary: (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: roland.mainz at nrubsig dot org Target Milestone: --- Building gcc from scratch crashes generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch. Note while the crash happens on Cygwin it looks like a *generic* memory corruption issue. Versions: $ gcc --version gcc (GCC) 11.4.0 $ uname -a CYGWIN_NT-10.0-19045 wingrendel02 3.5.1-1.x86_64 2024-02-27 11:54 UTC x86_64 Cygwin Steps to reproduce: - Note that this happens only SPORADICALLY - Cygwin is NOT Windows, Cygwin is a POSIX layer on top of Win32 and has it's own memory allocator, which works more like Linux/UNIX than Win32. So the IRC comments about memory layout vs. Windows should be taken with a grain/mountain of salt - Compile with: # crash happens with "releases/gcc-13.1.0" and "releases/gcc-13.2.0"! $ git clone -b releases/gcc-13.1.0 --single-branch ../gcc.bundle $ cd gcc $ configure $ yes | make -j8 all Log output: snip /cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc -B/cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc -nostdinc++ -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/libsupc++ -O2 -g /cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h -o x86_64-pc-cygwin/bits/stdtr1c++.h.gch/O2g.gch mkdir -p ./x86_64-pc-cygwin/bits/extc++.h.gch /cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc -B/cygdrive/m/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc -nostdinc++ -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem /usr/local/x86_64-pc-cygwin/include -isystem /usr/local/x86_64-pc-cygwin/sys-include -fno-checking -x c++-header -nostdinc++ -g -O2 -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include -I/cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/libsupc++ -O2 -g /cygdrive/m/builds/gcc20240317_50m/gcc/libstdc++-v3/include/precompiled/extc++.h -o x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch *** starting 'dumper "M:/builds/gcc20240317_50m/gcc/host-x86_64-pc-cygwin/gcc/cc1plus.exe" 8244' for pid 0, tid 1164 make[5]: *** [Makefile:1938: x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch] Error 1 make[5]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include' make[4]: *** [Makefile:576: all-recursive] Error 1 make[4]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3' make[3]: *** [Makefile:501: all] Error 2 make[3]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3' make[2]: *** [Makefile:18286: all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc' make[1]: *** [Makefile:25094: stage1-bubble] Error 2 make[1]: Leaving directory '/cygdrive/m/builds/gcc20240317_50m/gcc' make: *** [Makefile:1080: all] Error 2 snip Stack trace: snip roland_mainz@wingrendel02 /cygdrive/m/builds/gcc20240317_50m/gcc/x86_64-pc-cygwin/libstdc++-v3/include $ gdb ../../../host-x86_64-pc-cygwin/gcc/cc1plus.exe cc1plus.exe.core GNU gdb (GDB) (Cygwin 13.2-1) 13.2 [snip] [New Thread 0x48c] [New Thread 0x18c4] [New Thread 0x1370] #0 0x7ffaa106d664 in ntdll!ZwDelayExecution () from C:/Windows/SYSTEM32/ntdll.dll [Current thread is 1 (Thread 0x48c)] (gdb) bt #0 0x7ffaa106d664 in ntdll!ZwDelayExecution () from C:/Windows/SYSTEM32/ntdll.dll #1 0x7ffa9ec9b62e in SleepEx () from C:/Windows/System32/KERNELBASE.dll #2 0x7ffa9429e567 in secure_getenv () from C:/cygwin64/bin/cygwin1.dll #3 0x7ffa942a01cc in secure_getenv ()
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587 --- Comment #19 from Kaz Kylheku --- (In reply to Jonathan Wakely from comment #18) > Was there an earlier submission? No there wasn't; that's my mistake in my comment.
[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #2 from Richard Biener --- >> possibly "fallout" of r14-9193-ga0b1798042d033 > > It's not: I've reverted that patch locally, rebuilt cc1 and re-tested: > the XPASSes remain. A reghunt identified this patch: commit d30846a02eb9ea43b61311e74fbf05692ffefba2 Author: Fei Yang Date: Fri Jun 12 11:37:00 2020 +0100 vect: Fix an ICE in vect_loop_versioning [PR95570]
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #16 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #15) > (In reply to Peter Bergner from comment #12) > > (In reply to Sergey Fedorov from comment #11) > > > (In reply to GCC Commits from comment #10) > > > > The master branch has been updated by Iain D Sandoe : > > > > > > Iain, thank you very much for addressing this! > > > > If this is fixed for you, can you please move this to RESOLVED / FIXED? > > I will need to rebuild gcc13 and try it out, allow me some time please. it is only fixed on trunk so far - I am currently working on back ports to earlier branches and this will be one of them - so please leave open for now.
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-18
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||pinskia at gcc dot gnu.org
--- Comment #5 from Andrew Pinski ---
Confirmed.
For some reason doing changing `loop++` to what it does manually does not warn:
That is for
```
void f() {
char buf[11];
int loop(1);
do {
__builtin_snprintf(buf,sizeof(buf),"%d",loop++);
} while(loop<10);
}
void g() {
char buf[11];
int loop(1);
do {
int old = loop;
loop++;
__builtin_snprintf(buf,sizeof(buf),"%d",old);
} while(loop<10);
}
```
f is being warned about but g is not.
[Bug modula2/114380] Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380
--- Comment #3 from Gaius Mulley ---
$ gm2 tiny4.mod
tiny4.mod:13:17: error: In program module ‘tiny4’: type incompatibility between
‘BITSET’ and ‘WORD’
13 |b := func () - {6..31}
| ^
[Bug modula2/114380] Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380 --- Comment #2 from Gaius Mulley --- Created attachment 57725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57725=edit Proposed fix PR modula2/114380 Incorrect type specified in an error message This patch corrects an error message relating to a variable of a SET type. The bugfix is not to skip over set types (in GetLowestType). gcc/m2/ChangeLog: * gm2-compiler/SymbolTable.mod (GetLowestType): Do not skip over a set type, but return sym. gcc/testsuite/ChangeLog: * gm2/pim/fail/badset7.mod: New test.
[Bug libstdc++/114368] FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368 --- Comment #2 from dave.anglin at bell dot net --- I'll see if it's reproducible,
[Bug modula2/114380] Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2024-03-18 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/114380] New: Incorrect type specified in an error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114380
Bug ID: 114380
Summary: Incorrect type specified in an error message
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: gaius at gcc dot gnu.org
Target Milestone: ---
The source code:
MODULE tiny4 ;
FROM SYSTEM IMPORT WORD ;
PROCEDURE func () : WORD ;
BEGIN
RETURN WORD (0)
END func ;
VAR
b: BITSET ;
BEGIN
b := func () - {6..31}
END tiny4.
when compiled should complain about BITSET rather than CARDINAL.
$ gm2 tiny4.mod
tiny4.mod:13:17: error: In program module 'tiny4': type incompatibility between
'CARDINAL' and 'WORD'
13 |b := func () - {6..31}
| ^
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 --- Comment #5 from Patrick Palka --- (In reply to Nathaniel Shead from comment #4) > I suspect there are a number of issues tied together here. Some of the > things I've discovered so far: > > - 'tsubst_friend_class' calls 'lookup_name', which when called from a module > that doesn't export the class that was befriended fails to find it, and so > it substitutes in a new instance of that type (which then later fails > duplicate_decls). > > - Instantiating an elaborated type specifier doesn't attach it to the module > the containing template was declared in. Nathan's comments from the threads https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603288.html https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611215.html seem relevant here. > > - Sometimes it seems that the container of a MK_local_friend decl is not > always correctly streamed: in particular, in the comment 2 testcase the > container streamed is a complete type on write, but on read is not complete > (TYPE_SIZE is null) and so is not properly read on stream-in in the first > place. Interesting, it looks like the definition does eventually get streamed in but only after streaming in the MK_local_friend decl. MK_field decls seem to get streamed in beforehand too. > > Additionally, it looks like you can hide some of the errors by making the > importer a named module, because on instantiation it only calls > 'duplicate_decls' on names imported from a partition.
[Bug libstdc++/114368] FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368 --- Comment #1 from Jonathan Wakely --- I don't see this on aarch64-unknown-linux-gnu or x86_64-pc-linux-gnu.
[Bug c++/114379] stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114379 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- (In reply to Richard Biener from comment #1) > The diagnostic hints at jump threading producing an access to nullptr. Yes, I saw this happening with std::atomic recently too - I can't remember if I still have the code to reproduce it.
[Bug sanitizer/112709] [13 Regression] address sanitize and returns_twice causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug target/114339] [13 regression] Tor miscompiled with -O2 -mavx -fno-vect-cost-model since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug rtl-optimization/110079] [11/12 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE with |with|-freorder-blocks-and-partit |-freorder-blocks-and-partit |ion and inline-asm goto |ion and inline-asm goto | --- Comment #8 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug target/114310] [11/12 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |[aarch64] |[aarch64] |__sync_val_compare_and_swap |__sync_val_compare_and_swap |fails on __int128_t with|fails on __int128_t with |newval = 0 |newval = 0 --- Comment #8 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug rtl-optimization/114211] [13 Regression] wrong code with -O -fno-tree-coalesce-vars since r13-1907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug target/114184] [12 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with _Complex long double and vector VCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114184 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] ICE: in |[12 Regression] ICE: in |extract_insn, at|extract_insn, at |recog.cc:2812 |recog.cc:2812 |(unrecognizable insn ) with |(unrecognizable insn ) with |_Complex long double and|_Complex long double and |vector VCE |vector VCE --- Comment #6 from Jakub Jelinek --- Fixed for 13.3+ too.
[Bug c++/114379] stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114379 Richard Biener changed: What|Removed |Added Keywords||diagnostic Blocks||88443 --- Comment #1 from Richard Biener --- The diagnostic hints at jump threading producing an access to nullptr. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug libstdc++/111172] Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.3|12.4
[Bug libstdc++/111172] Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72 --- Comment #5 from Jonathan Wakely --- Fixed for 13.3 and 12.4 too.
[Bug libstdc++/112473] integer_sequence accepts non-integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for 13.3 and 12.4
[Bug libstdc++/114147] [11 Regression] tuple allocator-extended constructor requires non-explicit default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147 Jonathan Wakely changed: What|Removed |Added Summary|[11/12 Regression] tuple|[11 Regression] tuple |allocator-extended |allocator-extended |constructor requires|constructor requires |non-explicit default|non-explicit default |constructor |constructor --- Comment #11 from Jonathan Wakely --- backported for 13.3 and 12.4
[Bug libstdc++/107376] regex executor requires allocator to be default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.0|12.4 --- Comment #5 from Jonathan Wakely --- Backported for 12.4
