[Bug analyzer/107072] Analyzer call summarization not taking into account side-effects of calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107072 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-10-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- The above patch greatly improves the behavior, and fixes things for the reproducer. Keeping this open as numerous issues remain: see the TODOs in the above patch.
[Bug analyzer/107072] Analyzer call summarization not taking into account side-effects of calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107072 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:bfca9505f6fce631c2488f89aa156d56c7fae9ed commit r13-3077-gbfca9505f6fce631c2488f89aa156d56c7fae9ed Author: David Malcolm Date: Tue Oct 4 20:19:07 2022 -0400 analyzer: revamp side-effects of call summaries [PR107072] With -fanalyzer-call-summaries the analyzer canl attempt to summarize the effects of some function calls at their call site, rather than simulate the call directly, which can avoid big slowdowns during analysis. Previously, this summarization was extremely simplistic: no attempt was made to update sm-state, and region_model::update_for_call_summary would simply set the return value of the function to UNKNOWN, and assume the function had no side effects. This patch implements less simplistic summarizations: it tracks each possible return enode from the called function, and attempts to generate a successor enode from the callsite for each that have compatible conditions, mapping state changes in the summary to state changes at the callsite. It also implements the beginnings of heuristics for generating user-facing descriptions of a summary e.g. "when 'foo' returns NULL" versus: "when 'foo' returns a heap-allocated buffer" This still has some bugs, but much more accurately tracks the effects of a call, and so is an improvement; it should only have an effect when -fanalyzer-call-summaries is enabled. As before, -fanalyzer-call-summaries is disabled by default in analyzer.opt (but enabled by default in the test suite). gcc/ChangeLog: PR analyzer/107072 * Makefile.in (ANALYZER_OBJS): Add analyzer/call-summary.o. gcc/analyzer/ChangeLog: PR analyzer/107072 * analyzer-logging.h: Include "diagnostic-core.h". * analyzer.h: Include "function.h". (class call_summary): New forward decl. (class call_summary_replay): New forward decl. (struct per_function_data): New forward decl. (struct interesting_t): New forward decl. (custom_edge_info::update_state): New vfunc. * call-info.cc (custom_edge_info::update_state): New. * call-summary.cc: New file. * call-summary.h: New file. * constraint-manager.cc: Include "analyzer/call-summary.h". (class replay_fact_visitor): New. (constraint_manager::replay_call_summary): New. * constraint-manager.h (constraint_manager::replay_call_summary): New. * engine.cc: Include "analyzer/call-summary.h". (exploded_node::on_stmt): Handle call summaries. (class call_summary_edge_info): New. (exploded_node::replay_call_summaries): New. (exploded_node::replay_call_summary): New. (per_function_data::~per_function_data): New. (per_function_data::add_call_summary): Move here from header and reimplement. (exploded_graph::process_node): Call update_state rather than update_model when handling bifurcation (viz_callgraph_node::dump_dot): Use a regular label rather than an HTML table; add summaries to dump. * exploded-graph.h: Include "alloc-pool.h", "fibonacci_heap.h", "supergraph.h", "sbitmap.h", "shortest-paths.h", "analyzer/sm.h", "analyzer/program-state.h", and "analyzer/diagnostic-manager.h". (exploded_node::replay_call_summaries): New decl. (exploded_node::replay_call_summary): New decl. (per_function_data::~per_function_data): New decl. (per_function_data::add_call_summary): Move implemention from header. (per_function_data::m_summaries): Update type of element. * known-function-manager.h: Include "analyzer/analyzer-logging.h". * program-point.h: Include "pretty-print.h" and "analyzer/call-string.h". * program-state.cc: Include "analyzer/call-summary.h". (sm_state_map::replay_call_summary): New. (program_state::replay_call_summary): New. * program-state.h (sm_state_map::replay_call_summary): New decl. (program_state::replay_call_summary): New decl. * region-model-manager.cc (region_model_manager::get_or_create_asm_output_svalue): New overload. * region-model-manager.h (region_model_manager::get_or_create_asm_output_svalue): New overload decl. * region-model.cc: Include "analyzer/call-summary.h". (region_model::maybe_update_for_edge): Remove call to region_model::update_for_call_summary on SUPEREDGE_INTRAPROCEDURAL_CALL.
[Bug debug/107154] [12/13 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ce3a1b5976079b1467473b4628f05797fd2eae08 commit r13-3072-gce3a1b5976079b1467473b4628f05797fd2eae08 Author: Jason Merrill Date: Tue Oct 4 17:06:04 2022 -0400 c++: fix debug info for array temporary [PR107154] In the testcase the elaboration of the array init that happens at genericize time was getting the location info for the end of the function; fixed by doing the expansion at the location of the original expression. PR c++/107154 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_init_expr): Use iloc_sentinel. (cp_genericize_target_expr): Likewise. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/lineno-array1.C: New test.
[Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- For the testcases in comment 2 and comment 4, the problem was the loss of macro tracking information for the _Pragma token, and r9-1926 (for PR69558) fixed that, resolving a large class of diagnostic _Pragma location problems including these. For the current PR's original testcase (attachment 42777), there are two separate issues combined together: -For -Wuninitialized, this was caused for both C and C++ by -Wuninitialized using the spelling location rather than the macro expansion location. It has been fixed recently (r13-2994) for GCC 13. That fix has so far not been backported but it would backport fine if someone wants it. -For -Wattribute-alias, this one is applicable only to C, since C++ issues a hard error for this testcase rather than a warning. Note, to avoid potential confusion, the testcase as posted does not fail, it is needed to remove the "struct s;" line to exhibit the problem. This was fixed by r13-1596 (for PR97498) and was the same issue. (That was the fact that in C, input_location was often pointing to the start of the line.) This is backported to 10,11,12 branches already. It seems to me that the testcases added for the above three cases cover everything in this PR, so I am resolving it now.
[Bug target/107155] ppc_intrinsics is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107155 --- Comment #2 from Andrew Pinski --- And yes it was an Apple extension: https://opensource.apple.com/source/gcc/gcc-5026/more-hdrs/ppc_intrinsics.h.auto.html
[Bug target/107155] ppc_intrinsics is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107155 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- ppc_intrinsics.h never existed upstream. If it existed it was in Apple's port but I don't think it was. Really just a dup of bug 93177. *** This bug has been marked as a duplicate of bug 93177 ***
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 Andrew Pinski changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #15 from Andrew Pinski --- *** Bug 107155 has been marked as a duplicate of this bug. ***
[Bug target/107155] New: ppc_intrinsics is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107155 Bug ID: 107155 Summary: ppc_intrinsics is missing Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vital.had at gmail dot com CC: iains at gcc dot gnu.org Target Milestone: --- Target: powerpc-apple-darwin Some ports ask for intrinsics header, however GCC12 currently has only `ppu_intrinsics.h` for Cell, no `ppc_intrinsics.h` is there. `ppc_intrinsics.h` existed in earlier GCC and likely can (and should) be implemented into the current GCC.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #21 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058280.html
[Bug debug/107154] [12/13 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #3 from Jonathan Wakely --- It started with r12-6329 c++: EH and partially constructed aggr temp [PR66139]
[Bug debug/107154] [12/13 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 Jason Merrill changed: What|Removed |Added Last reconfirmed||2022-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug debug/107154] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #2 from Andrew Pinski --- I think there is another bug about this one ...
[Bug debug/107154] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #1 from Jonathan Wakely --- This is with the Fedora packages but I see it with GCC trunk too. $ rpm -q gcc gdb gcc-12.2.1-2.fc36.x86_64 gdb-12.1-1.fc36.x86_64
[Bug debug/107154] New: GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154
Bug ID: 107154
Summary: GDB jumping to end of block when stepping over
construction of local variable
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
struct X {
X(std::initializer_list, int) { }
};
int main()
{
X x( {"", "", "", ""}, 1|4 );
return 0;
}
tmp$ g++ -g debug.C -o debug
tmp$ gdb -q debug
Reading symbols from debug...
(gdb) start
Temporary breakpoint 1 at 0x40123a: file debug.C, line 12.
Starting program: /tmp/debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at debug.C:12
12 }
(gdb) n
10X x( {"", "", "", ""}, 1|4 );
(gdb)
12 }
(gdb)
11return 0;
(gdb)
__libc_start_call_main (main=main@entry=0x401226 , argc=argc@entry=1,
argv=argv@entry=0x7fffd7a8) at ../sysdeps/nptl/libc_start_call_main.h:74
74exit (result);
(gdb)
[Inferior 1 (process 577012) exited normally]
Why does "start" break on the closing brace of main(), and then the
construction of 'x' also jumps to the closing brace?
In less trivial examples I've seen it jump back and forth multiple times:
243 libmap libs;
(gdb) n
245 redi::ipstream in({"ldd", argv[arg]}, pstdout|pstderr);
(gdb)
310 }
(gdb)
245 redi::ipstream in({"ldd", argv[arg]}, pstdout|pstderr);
(gdb)
310 }
(gdb)
245 redi::ipstream in({"ldd", argv[arg]}, pstdout|pstderr);
(gdb)
[Detaching after fork from child process 845854]
310 }
(gdb)
[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
--- Comment #7 from Marek Polacek ---
...which could be fixed with
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -9186,7 +9186,9 @@ conv_is_prvalue (conversion *c)
{
if (c->kind == ck_rvalue)
return true;
- if (c->kind == ck_base && c->need_temporary_p)
+ if (c->kind == ck_base
+ /* TODO */
+ && (c->need_temporary_p || conv_is_prvalue (next_conversion (c
return true;
if (c->kind == ck_user && !TYPE_REF_P (c->type))
return true;
but that then causes ICEs in build_over_call, at cp/call.cc:9987
[Bug fortran/107074] ICE: Bad IO basetype (8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 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 --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058278.html
[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
--- Comment #6 from Marek Polacek ---
(In reply to Roy Jacobson from comment #3)
> Thanks! But a Base const& is still not detected:
>
> static_assert(__reference_constructs_from_temporary(Base const&, Derived));
>
> And in this case I think it _is_ a bug that this doesn't compile?
To make sure I understand this correctly, __reference_constructs_from_temporary
should say "yes" here, because it's just like
const Base& b(Derived{});
where we bind 'b' to the Base subobject of a temporary Derived object, yes?
[Bug fortran/107143] ICE: 'verify_gimple' failed (Error: non-trivial conversion in 'mem_ref')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-10-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Replacing the forall construct by an ordinary do loop avoids the ICE.
[Bug fortran/77884] [Coarray] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from anlauf at gcc dot gnu.org --- Both testcases in comment#0 are rejected with current mainline and all open branches on x86_64-pc-linux-gnu: pr77884-z1.f90:5:9: 5 | call s(x) | 1 Error: Actual argument to 'x' at (1) must be a coarray and pr77884-z4.f90:3:9: 3 | call s(x) | 1 Error: Actual argument to 'x' at (1) must be a coarray
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589 Andrew Pinski changed: What|Removed |Added CC||tim at klingt dot org --- Comment #7 from Andrew Pinski --- *** Bug 107146 has been marked as a duplicate of this bug. ***
[Bug c++/107146] [ICE] in build_value_init, at cp/init.cc:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107146 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 105589 ***
[BUG] bug in shift/add optimizer for avr targets
hi,
I realized gcc does not use optimized const shifts well but instead does
replace some (3-7) left shifts on 32bit variables with add and adc
operations.
If the shift is not optimized and just unrolled they should be the same
cycle count but for some reason it also adds some mov operations in the
later part making it even worse performance wise. In terms of bytecode size
shifts are better than add and adc operations. Also all const shifts can
get optimized even better as one can see for the other variable sizes e.g.
16bit. Also I should mention this only happens with left shifts on 32bit
(maybe also on 24bit) and with some non Os optimizer option.
I sent const case optimisation to the patch mailing list but was not able
to figure out where this bad optimisation is coming from.
I prepared a compiler explorer example for you to get a easy grasp on it:
https://godbolt.org/z/x75EM94rE
In case compiler explorer does not work out for you the example code is:
unsigned long lshift32_c(const unsigned long value) {
return value << 7;
}
resulting in a lot of in case of O0 showing the wrong replacement by
optimizer:
add r24,r24
adc r25,r25
adc r26,r26
adc r27,r27
resulting in a lot of singe not optimized shifts and some additional
useless mov near the end with O2:
lsl r24
rol r25
rol r26
rol r27
...
movw r18,r24
movw r20,r26
lsl r18
rol r19
rol r20
rol r21
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 --- Comment #3 from Jakub Jelinek --- The code is different though. C has that case EQ_EXPR: case NE_EXPR: case LE_EXPR: case GE_EXPR: case LT_EXPR: case GT_EXPR: /* Excess precision for implicit conversions of integers to floating point in C11 and later. */ may_need_excess_precision = (flag_isoc11 && (ANY_INTEGRAL_TYPE_P (type0) || ANY_INTEGRAL_TYPE_P (type1))); break; part in which is from PR82071 and I can't find in the C++ standard a similar change to what has changed from C99 to C11. If you mean to share just case PLUS_EXPR: case MINUS_EXPR: case MULT_EXPR: case TRUNC_DIV_EXPR: case CEIL_DIV_EXPR: case FLOOR_DIV_EXPR: case ROUND_DIV_EXPR: case EXACT_DIV_EXPR: then that sounds something not worth sharing to me.
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I know it's just a WIP, but could we share the setting of may_need_excess_precision between C and C++?
[Bug c++/107097] Implement floating point excess precision in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107097 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53667=edit gcc13-pr107097-wip.patch Untested WIP. ?: handling isn't there, neither call argument, will need to check assignments and whether I got all the cast spots that need tweaking.
[Bug demangler/98886] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98886 Andrew Pinski changed: What|Removed |Added CC||bjchan9an at foxmail dot com --- Comment #14 from Andrew Pinski --- *** Bug 107108 has been marked as a duplicate of this bug. ***
[Bug demangler/107108] Uncontrolled stack recursion in rust-demangler.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107108 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 98886 then. *** This bug has been marked as a duplicate of bug 98886 ***
[Bug c++/107136] [13 Regression] File cp/cp-trait.def file not installed for plugin suport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107136 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed
[Bug c++/107136] [13 Regression] File cp/cp-trait.def file not installed for plugin suport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107136 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e87879a9f5c2869de177c4dde2172f277e81ef1a commit r13-3065-ge87879a9f5c2869de177c4dde2172f277e81ef1a Author: Patrick Palka Date: Tue Oct 4 12:23:46 2022 -0400 c++: install cp-trait.def as part of plugin headers [PR107136] This is apparently needed since we include cp-trait.def from cp-tree.h (in order to define the cp_trait_kind enum), as with operators.def. PR c++/107136 gcc/cp/ChangeLog: * Make-lang.in (CP_PLUGIN_HEADERS): Add cp-trait.def.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #10 from Vadim Zeitlin ---
There definitely was a change in behaviour in gcc 11 because I had to make this
change
https://github.com/wxWidgets/wxWidgets/commit/95c98a0b5ff71caca6654327bf341719c6587766
to avoid getting warnings with it that we didn't get with the previous
versions.
The idea there is that we define some macros whose expansion contains
declarations of overridden virtual functions, which inevitably results in
-Wsuggest-override when used in user classes using or not using "override" for
their other functions, so we have to disable this warning locally.
wxWARNING_SUPPRESS_MISSING_OVERRIDE, which expands to
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wsuggest-override\"")
worked for this until gcc 11 but not with it.
[Bug target/107102] SVE function fails to realize it doesn't need the frame-pointer in the tail call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107102 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-10-04 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed, clang tail-calls this: bar:// @bar ptrue p1.b ptrue p0.s and p0.b, p1/z, p1.b, p0.b b foo
[Bug libgcc/106949] Memory leak using VLA/alloca with -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949 --- Comment #5 from Anton Fedorov --- Hhhhmmm... Interesting, it doesn't seems to be possible, but it would be fun way to fix to add cleanup(free) attribute to the variable if it has to be malloc'ed...
[Bug debug/60833] Inheritance via typedef skips the typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833 --- Comment #3 from David Blaikie --- FWIW, bug on the GDB side seems to have been fixed ( https://sourceware.org/bugzilla/show_bug.cgi?id=16841 ) - might be nice to fix the GCC side too. (though, admittedly, I don't know that this extra debug info provides much value at the moment - I think GDB mostly looks straight through typedefs)
[Bug libstdc++/103924] views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
--- Comment #1 from Patrick Palka ---
I encountered a similar problem when testing views::join_with:
#include
#include
constexpr std::string_view rs[] = {"42"};
static_assert(!std::ranges::empty(rs |
std::views::join_with(std::string("";
error: accessing ‘std::__cxx11::basic_string_M_allocated_capacity’ member instead of initialized
‘std::__cxx11::basic_string_M_local_buf’ member in
constant expression
[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605 --- Comment #16 from Jonathan Wakely --- Oops, I put the wrong PR number on this commit: https://gcc.gnu.org/g:7cdab65f3d770345903023f357b6ca96bc85a002 commit r13-3059-g7cdab65f3d770345903023f357b6ca96bc85a002 Author: Jonathan Wakely Date: Mon Oct 3 21:49:27 2022 +0100 libstdc++: Make work freestanding [PR107134] When gcc/config.gcc defines use_gcc_stdin=wrap, GCC's tries to use libc's unless -ffreestanding is used. When libstdc++ is configured --disable-hosted-libstdcxx we want to work even without -ffreestanding being given. This is a kluge to make it include GCC's directly even without -ffreestanding. libstdc++-v3/ChangeLog: PR libstdc++/107134 * include/c_global/cstdint [!_GLIBCXX_HOSTED]: Include directly. This should be fixed now, please check. I think we still want Arsen's patch in comment 10 for correctness, but this makes libstdc++ cope without it.
[Bug libstdc++/107135] array::at() method should not be in for freestanding C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107135 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |13.0 --- Comment #9 from Jonathan Wakely --- Fixed. Doing something other than std::terminate is a decision for another day. For now, the freestanding environment needs to provide abort().
[Bug demangler/107108] Uncontrolled stack recursion in rust-demangler.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107108 --- Comment #4 from bjchan9an at foxmail dot com --- (In reply to Andrew Pinski from comment #3) > Can you try binutils 2.39? Yes, this bug has been repaired in binutils 2.39.
[Bug c++/107134] fatal error: stdint.h: No such file or directory for freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107134 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7cdab65f3d770345903023f357b6ca96bc85a002 commit r13-3059-g7cdab65f3d770345903023f357b6ca96bc85a002 Author: Jonathan Wakely Date: Mon Oct 3 21:49:27 2022 +0100 libstdc++: Make work freestanding [PR107134] When gcc/config.gcc defines use_gcc_stdin=wrap, GCC's tries to use libc's unless -ffreestanding is used. When libstdc++ is configured --disable-hosted-libstdcxx we want to work even without -ffreestanding being given. This is a kluge to make it include GCC's directly even without -ffreestanding. libstdc++-v3/ChangeLog: PR libstdc++/107134 * include/c_global/cstdint [!_GLIBCXX_HOSTED]: Include directly.
[Bug libstdc++/107135] array::at() method should not be in for freestanding C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107135 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7d8189882fc89f6f410fc9bcf0f8226787316f83 commit r13-3058-g7d8189882fc89f6f410fc9bcf0f8226787316f83 Author: Jonathan Wakely Date: Mon Oct 3 20:53:35 2022 +0100 libstdc++: Define functions for freestanding [PR107135] We don't compile src/c++11/functexcept.cc for freestanding, so just define the functions used by freestanding entities as inline calls to std::terminate. libstdc++-v3/ChangeLog: PR libstdc++/107135 * include/bits/functexcept.h [!_GLIBCXX_HOSTED] (__throw_invalid_argument, __throw_out_of_range) (__throw_out_of_range_fmt, __throw_runtime_error) (__throw_overflow_error): Define inline. * include/std/bitset (_M_copy_from_ptr) [!_GLIBCXX_HOSTED]: Replace __builtin_abort with __throw_invalid_argument.
[Bug libstdc++/107139] Time to remove #if _GLIBCXX_HOSTED guard for coroutine for freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107139 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b74ab7a1609f01afaab9b82cfabfb96ae9e1145d commit r13-3060-gb74ab7a1609f01afaab9b82cfabfb96ae9e1145d Author: Jonathan Wakely Date: Tue Oct 4 09:37:14 2022 +0100 libstdc++: Enable std::hash> [PR107139] Everything that depends on is available for freestanding now. libstdc++-v3/ChangeLog: PR libstdc++/107139 * include/std/coroutine: Remove all _GLIBCXXHOSTED preprocessor conditionals.
[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107148 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-10-04 Status|UNCONFIRMED |NEW
[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107153 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-04 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org
[Bug tree-optimization/107153] New: [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107153
Bug ID: 107153
Summary: [13 Regression] ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs
when compiling the following testcase w/ -O1 -floop-parallelize-all
-ftree-parallelize-loops=2 -fno-tree-dominator-opts:
void
foo (int x, int y)
{
int i;
for (i = 0; i < 2; i++)
{
}
while (x)
if (!y)
while (y)
++y;
}
% gcc-13.0.0 -O1 -floop-parallelize-all -ftree-parallelize-loops=2
-fno-tree-dominator-opts -c rssq9kpi.c
during GIMPLE pass: ompexpssa
rssq9kpi.c: In function 'foo':
rssq9kpi.c:2:1: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:645
2 | foo (int x, int y)
| ^~~
0x77e395 check_loop_closed_ssa_def
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree-ssa-loop-manip.cc:645
0x106f1a4 check_loop_closed_ssa_bb
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree-ssa-loop-manip.cc:659
0x1070566 verify_loop_closed_ssa(bool, loop*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree-ssa-loop-manip.cc:695
0x1070566 verify_loop_closed_ssa(bool, loop*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree-ssa-loop-manip.cc:679
0xdfcf64 execute_function_todo
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/passes.cc:2109
0xdfd33e execute_todo
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/passes.cc:2145
[Bug c++/107152] New: ICE: Segmentation fault (in get_shorthand_constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107152
Bug ID: 107152
Summary: ICE: Segmentation fault (in get_shorthand_constraints)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++ 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs
when compiling the following testcase, reduced from
test/Modules/template-function-specialization.cpp from the clang 15.0.1 test
suite:
export template <>
void foo4() {
}
% g++-13.0.0 -std=c++20 -w -c rnforwjm.cpp
rnforwjm.cpp:1:18: error: invalid explicit specialization before '>' token
1 | export template <>
| ^
rnforwjm.cpp:1:18: internal compiler error: Segmentation fault
0x11dc98f crash_signal
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/toplev.cc:314
0x9c7cd6 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.h:3519
0x9c7cd6 get_shorthand_constraints(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/constraint.cc:1558
0xb2de2b cp_parser_explicit_template_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:31825
0xb3094a cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:15038
0xb31509 cp_parser_toplevel_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:15130
0xb31509 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:5068
0xb31509 c_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:48606
0xc6e3a1 c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/c-family/c-opts.cc:1255
[Bug libgcc/106949] Memory leak using VLA/alloca with -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949
--- Comment #4 from Anton Fedorov ---
> You can't just add a stack segment without changing the stack pointer.
I can -- since we are on the initial stack at this point, no return into
__morestack will happen so no attempt to release it, thus there is no problem
and it won't affect subsequent allocations of frames would it be necessary.
But that's the catch: the allocated blocks won't be released no matter is we on
the initial stack or deep inside, until we try to release the frame, which may
never happen no matter are we on the initial stack or not.
the easiest way may be change gcc generate the code like:
```
struct __morestack_blocks {
struct __morestack_blocks * next;
void * block;
};
void __morestack_free_blocks(struct __morestack_blocks ** blocks) {
struct __morestack_blocks * cur = *blocks;
while(cur) {
free(cur->block);
cur = cur->next;
}
}
void* __morestack_allocate_stack_space(int size, struct __morestack_blocks **
blocks){ ... }
somefunction(someargs) {
struct __morestack_blocks __attribute__((cleanup(__morestack_free_blocks))) =
nullptr;
// void * a = alloca(x);
a = __morestack_allocate_stack_space(x, &__morestack_blocks);
}
```
But that local variable to be used as a reference, but makes it trivial
(although, I don't know how to generate local variable with assigned destructor
from the gcc code, will look for it)...
[Bug c++/107151] New: Specializing a concepted template can emit bogus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107151
Bug ID: 107151
Summary: Specializing a concepted template can emit bogus
assembly
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
template
void fun(T);
template <>
void fun(char c)
{
std::puts("foo()");
}
template
void fun(I i)
{
std::puts("foo()");
}
int main()
{
fun(' ');
}
Compile with -std=c++20.
Result:
/tmp/cctfBAWi.s: Assembler messages:
/tmp/cctfBAWi.s:63: Error: symbol `_Z3funIcEvT_' is already defined
/tmp/cctfBAWi.s: Error: .size expression for _Z3funIcEvT_ does not evaluate to
a constant
Expected: Prints foo(), or at least a less cryptic error. With -O2, GCC
only emits one _Z3funIcEvT_, but the resulting program prints
foo().
https://godbolt.org/z/axvdbK1Eh
Clang and MSVC have similar bugs:
https://github.com/llvm/llvm-project/issues/58142
https://developercommunity.visualstudio.com/t/Template-explicit-specializationconcept/10012835
[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088 --- Comment #10 from Stefan Schulze Frielinghaus --- (In reply to rsand...@gcc.gnu.org from comment #8) > Looks good, but maybe: > > GET_MODE_SIZE (int_mode) > 1 > > would be more general. I very much like the idea of a size guard. Posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602776.html
[Bug c++/107150] ICE: tree check: expected function_type or method_type, have lang_type in deduce_noexcept_on_destructor, at cp/class.cc:5183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107150 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r8-2664-g2e12a8554c9ed35f.
[Bug c++/107150] New: ICE: tree check: expected function_type or method_type, have lang_type in deduce_noexcept_on_destructor, at cp/class.cc:5183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107150
Bug ID: 107150
Summary: ICE: tree check: expected function_type or
method_type, have lang_type in
deduce_noexcept_on_destructor, at cp/class.cc:5183
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++ 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs
when compiling the following testcase, reduced from
clang/testsuite/CXX/class/class.dtor/p4.cpp from the clang 15.0.1 test suite:
template
struct D {
~D() requires(N != 0) = delete;
~D() requires(N == 1) = delete;
};
template struct D<0>;
% g++-13.0.0 -fconcepts -c ghba8ll9.cpp
ghba8ll9.cpp: In instantiation of 'struct D<0>':
ghba8ll9.cpp:7:17: required from here
ghba8ll9.cpp:2:8: internal compiler error: tree check: expected function_type
or method_type, have lang_type in deduce_noexcept_on_destructor, at
cp/class.cc:5183
2 | struct D {
|^
0x891780 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.cc:8827
0x690b3a tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.h:3539
0x690b3a deduce_noexcept_on_destructor(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/class.cc:5183
0x99d6c9 check_bases_and_members
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/class.cc:6045
0x9a150b finish_struct_1(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/class.cc:7492
0xb8ead0 instantiate_class_template(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:12468
0xbe5c28 complete_type(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/typeck.cc:138
0xb850ca do_type_instantiation(tree_node*, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:26074
0xb1ea7f cp_parser_explicit_instantiation
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:19262
0xb308ac cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:15075
0xb31509 cp_parser_toplevel_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:15130
0xb31509 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:5068
0xb31509 c_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:48606
0xc6e3a1 c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/c-family/c-opts.cc:1255
g++ 12 and earlier releases ICE with a splat identical to the one reported in
PR96745. I'm not sure if this PR is a duplicate of that earlier one.
[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107094 --- Comment #4 from Tobias Burnus --- Cross ref: The PR mentioned in comment 1 contains a patch suggestion that fixes the issue of this PR: PR 107088 comment 6 (the patch) PR 107088 comment 9 (comment that it fixes the issue)
[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107094 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Martin Liška --- *** Bug 107149 has been marked as a duplicate of this bug. ***
[Bug middle-end/107149] [13 Regression] ICE during RTL pass: dse2 - internal compiler error: in require, at machmode.h:297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107149 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 107094 ***
[Bug middle-end/107149] New: [13 Regression] ICE during RTL pass: dse2 - internal compiler error: in require, at machmode.h:297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107149 Bug ID: 107149 Summary: [13 Regression] ICE during RTL pass: dse2 - internal compiler error: in require, at machmode.h:297 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org Target Milestone: --- Target: amdgcn-amdhsa Building current GCC mainline for AMDGCN, it fails when building libgfortran for several files with: during RTL pass: dse2 src/gcc-mainline/libgfortran/generated/maxloc1_16_i1.c: In function 'mmaxloc1_16_i1': src/gcc-mainline/libgfortran/generated/maxloc1_16_i1.c:460:1: internal compiler error: in require, at machmode.h:297 460 | } | ^ 0x672c50 opt_mode::require() const src/gcc-mainline/gcc/machmode.h:297 0x67474a opt_mode::require() const src/gcc-mainline/gcc/cselib.cc:1567 0x67474a void mode_iterator::get_known_wider(scalar_int_mode*) src/gcc-mainline/gcc/machmode.h:1124 0x67474a new_cselib_val src/gcc-mainline/gcc/cselib.cc:1579 0xabbc6b cselib_lookup_1 src/gcc-mainline/gcc/cselib.cc:2315 0xabbf4e cselib_lookup(rtx_def*, machine_mode, int, machine_mode) src/gcc-mainline/gcc/cselib.cc:2431 0xabeaf0 cselib_record_sets src/gcc-mainline/gcc/cselib.cc:2932 0xabfb59 cselib_process_insn(rtx_insn*) src/gcc-mainline/gcc/cselib.cc:3159 0x178d554 dse_step1 src/gcc-mainline/gcc/dse.cc:2771 0x178d554 rest_of_handle_dse src/gcc-mainline/gcc/dse.cc:3687 0x178d554 execute src/gcc-mainline/gcc/dse.cc:3760 Side note: I did spot in the log file the follow warning, which looks as if it could be related: src/gcc-mainline/gcc/expmed.cc: In function 'rtx_def* extract_bit_field_1(rtx, poly_uint64, poly_uint64, int, rtx, machine_mode, machine_mode, bool, bool, rtx_def**)': src/gcc-mainline/gcc/expmed.cc:1838:45: warning: '*(unsigned int*)((char*) + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' may be used uninitialized in this function [-Wmaybe-uninitialized] 1838 | rtx sub = extract_bit_field_as_subreg (mode1, op0, imode, | ^~~ 1839 | bitsize, bitnum); |
[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107148 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started likely with r11-7844-g6081d8994ed1a0ae.
[Bug c++/107147] [13 Regression] ICE in register_local_var_uses, at cp/coroutines.cc:3923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-10-04 --- Comment #2 from Martin Liška --- It's there since coroutines were added in r10-6063-g49789fd08378e3ff.
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-10-04 --- Comment #1 from Martin Liška --- Confirmed, it's old issue.
[Bug c++/107148] New: [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107148
Bug ID: 107148
Summary: [10/11/12/13 Regression] ICE in bot_manip, at
cp/tree.cc:3252
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++ 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs
when compiling the following testcase, reduced from
test/Sema/stmt-expr-in-default-arg.cpp from the clang 15.0.1 test suite:
template
int bar(Callable &) {
return Call();
}
int baz() {
auto l = [](int a = ({ int x = 12; x; })) {
return 1;
};
return bar(l);
}
% g++-13.0.0 -c wi2ugigv.cpp
wi2ugigv.cpp: In function 'int baz()':
wi2ugigv.cpp:7:30: error: ISO C++ forbids in-class initialization of non-const
static member 'baz()x'
7 | auto l = [](int a = ({ int x = 12; x; })) { // expected-error
{{default argument may not use a GNU statement expression}}
| ^
wi2ugigv.cpp:7:38: error: 'x' was not declared in this scope
7 | auto l = [](int a = ({ int x = 12; x; })) { // expected-error
{{default argument may not use a GNU statement expression}}
| ^
wi2ugigv.cpp:7:23: error: could not convert '({...})' from 'void' to 'int'
7 | auto l = [](int a = ({ int x = 12; x; })) { // expected-error
{{default argument may not use a GNU statement expression}}
| ^~~~
| |
| void
wi2ugigv.cpp: In instantiation of 'int bar(Callable&&) [with Callable =
baz()::&]':
wi2ugigv.cpp:10:13: required from here
wi2ugigv.cpp:3:14: internal compiler error: in bot_manip, at cp/tree.cc:3252
3 | return Call();
| ^~
0x75052d bot_manip
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/tree.cc:3252
0x14f3003 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.cc:11249
0xbd29f8 break_out_target_exprs(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/tree.cc:
0x96fd52 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:8755
0x97d73f build_over_call
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:9655
0x981621 build_op_call(tree_node*, vec**, int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:5137
0xbad4a1 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/semantics.cc:2925
0xb59a1d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:21204
0xb6f001 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:19722
0xb7036f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:18707
0xb6fdcd tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:19059
0xb837b6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:18683
0xb837b6 instantiate_body
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:26657
0xb84994 instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:26949
0xb903b3 instantiate_pending_templates(int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:27027
0xa3e5cc c_parse_final_cleanups()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/decl2.cc:4917
0xc6e3cf c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/c-family/c-opts.cc:1273
[Bug c++/107147] [13 Regression] ICE in register_local_var_uses, at cp/coroutines.cc:3923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147 --- Comment #1 from Arseny Solokha --- (In reply to Arseny Solokha from comment #0) > gfortran 13.0.0 20220925 snapshot g++, of course.
