[Bug tree-optimization/107301] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107301 Martin Liška changed: What|Removed |Added CC||amonakov at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r13-1753-g26cea5f108e0facd.
[Bug c++/107147] ICE in register_local_var_uses, at cp/coroutines.cc:3923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107147 Richard Biener changed: What|Removed |Added Keywords||C++-coroutines, ||ice-checking Target Milestone|13.0|--- Summary|[13 Regression] ICE in |ICE in |register_local_var_uses, at |register_local_var_uses, at |cp/coroutines.cc:3923 |cp/coroutines.cc:3923 --- Comment #5 from Richard Biener --- so not really a regression then
[Bug c++/107163] [10/11/12/13 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/107275] [13 Regression] Recent ifcvt changes resulting in references to SSA_NAME on free list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Priority|P3 |P4 Keywords||wrong-code
[Bug tree-optimization/95569] ICE in tmmark：verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95569 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug c++/107198] [13 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #4 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #3) > We are failing while trying to fold: > > c_92 = __builtin_copysignf128 (0.0, c_80(D)); > > The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype has a > precision of 127 whereas _Float128 has a precision of 128. This causes the > assert in fold_using_range::fold_stmt to fail because range_compatible_p is > false. > > Are both operands of copysign allowed to have different types / precisions? Sorry, what I meant to say is that c_92 is TFtype, whereas __builtin_copysignf128 is assuming to return the type of the first operand (0.0, which is _Float128). Is this correct?
[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I will try to have a closer look.
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 CC||amacleod at redhat dot com Status|UNCONFIRMED |NEW Last reconfirmed||2022-10-18 --- Comment #3 from Aldy Hernandez --- We are failing while trying to fold: c_92 = __builtin_copysignf128 (0.0, c_80(D)); The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype has a precision of 127 whereas _Float128 has a precision of 128. This causes the assert in fold_using_range::fold_stmt to fail because range_compatible_p is false. Are both operands of copysign allowed to have different types / precisions?
[Bug sanitizer/107298] Failure to compile code with std::optional and ASan/UBSan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107298 --- Comment #3 from John Zwinck --- Martin, this bug is the only false positive I see in a large corporate codebase. I think your comment makes it sound like this is a documented thing where there are tons of false positives and it's not practical to do anything about them, and I am not sure how to square this with my experience that almost all warnings from -Wall and -Wextra work just fine with ASan & UBSan. Is there some documentation explaining this, or telling Sanitizer users to turn off warnings-as-errors?
[Bug tree-optimization/107302] New: [13 Regression] ICE in as_a, at is-a.h:242 since r13-3327-g46a8e017d048ec32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107302
Bug ID: 107302
Summary: [13 Regression] ICE in as_a, at is-a.h:242 since
r13-3327-g46a8e017d048ec32
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: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
The following crashes:
$ cat tsvc.i
int a[0];
int s292_im1;
void
s292() {
for (int i = 0; i < 2000; i++) {
a[i] = s292_im1;
s292_im1 = i;
}
}
$ gcc tsvc.i -fno-tree-pre -O2
during GIMPLE pass: vect
tsvc.i: In function ‘s292’:
tsvc.i:5:1: internal compiler error: in as_a, at is-a.h:242
5 | s292() {
| ^~~~
0x7fa8a6 gimple_statement_with_memory_ops*
as_a(gimple*)
/home/marxin/Programming/gcc/gcc/is-a.h:242
0x7fde52 gphi* as_a(gimple*)
/home/marxin/Programming/gcc/gcc/gimple-iterator.h:129
0x7fde52 gphi_iterator::phi() const
/home/marxin/Programming/gcc/gcc/gimple-iterator.h:43
0x7fde52 vect_transform_loop(_loop_vec_info*, gimple*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:10894
0x124f32e vect_transform_loops
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1007
0x124f90f try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1153
0x124f90f try_vectorize_loop
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1183
0x124fca4 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1299
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/106921] [11/12/13 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4 Priority|P3 |P2
[Bug c++/107211] [10/11/12/13 Regression] GCC compiles invalid use of non static member function in noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107211 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5
[Bug tree-optimization/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107209 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107209
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #3 from Richard Biener ---
_24 = 4.34763122374727917218706352286972105503082275390625e+0;
aarch64_general_gimple_fold_builtin builds
_24 = 3.1415926535906156975359772332012653350830078125e+0 *
1.38389399574953335468308068811893463134765625e+0;
and then rvrp_folder::fold_stmt folds this further.
Now, aarch64_general_gimple_fold_builtin uses gsi_replace with (..., true)
and so that moves EH info to the new stmt, but then
/* Now cleanup. */
if (did_replace)
{
...
/* If we cleaned up EH information from the statement,
remove EH edges. */
if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
bitmap_set_bit (need_eh_cleanup, bb->index);
no longer triggers. So this is a target bug, aarch64 folding should _not_
update EH info, folding shouldn't update any of the on-the-side info.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 1d0f994f281..890062d359b 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -15157,7 +15157,7 @@ aarch64_gimple_fold_builtin (gimple_stmt_iterator *gsi)
if (!new_stmt)
return false;
- gsi_replace (gsi, new_stmt, true);
+ gsi_replace (gsi, new_stmt, false);
return true;
}
fixes this. aarch64 folks please test
[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |ipa
Summary|ICE: verify_ssa failed |[13 Regression] ICE:
|(error: virtual definition |verify_ssa failed (error:
|of statement not up to |virtual definition of
|date) |statement not up to date)
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||marxin at gcc dot gnu.org
Last reconfirmed||2022-10-18
Target Milestone|--- |13.0
--- Comment #1 from Richard Biener ---
Confirmed. The unreachable doesn't have virtual operands but trap() should
have. Oddly enough the abort is also replaced with trap!?
void bar.constprop ()
{
int x;
int y;
[local count: 1073741824]:
[local count: 1073741824]:
if (0 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_trap ();
[local count: 1073741824]:
if (0 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
# .MEM_2 = VDEF <.MEM_1(D)>
__builtin_trap ();
[local count: 1073741824]:
# VUSE <.MEM_1(D)>
return;
smells like a deeper regression in IPA (I suppose IPA CP marks stuff
unreachable and then we turn that into traps!?)
[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||ice-checking
[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Martin Liška --- Btw. started with r13-2541-g78ef801b7263606d.
[Bug tree-optimization/107301] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107301 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/107295] [13 Regression] Rejected code in libreoffice with -m32 since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107295 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/107271] [13 Regression] ICE: in expand_vec_perm_shufps_shufps, at config/i386/i386-expand.cc:19676 with __builtin_shuffle() since r13-2843-g3db8e9c2422d924a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107271 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/107301] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107301 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #5 from Richard Biener --- (In reply to Aldy Hernandez from comment #4) > (In reply to Aldy Hernandez from comment #3) > > We are failing while trying to fold: > > > > c_92 = __builtin_copysignf128 (0.0, c_80(D)); > > > > The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype has a > > precision of 127 whereas _Float128 has a precision of 128. This causes the > > assert in fold_using_range::fold_stmt to fail because range_compatible_p is > > false. > > > > Are both operands of copysign allowed to have different types / precisions? > > Sorry, what I meant to say is that c_92 is TFtype, whereas > __builtin_copysignf128 is assuming to return the type of the first operand > (0.0, which is _Float128). Is this correct? It looks like 0.0 has the wrong type here. Maybe the copysign is the result of folding that left us with unconverted 0.0 here? Reduced preprocessed source would be nice, but you can see if -fdump-tree-all-folding shows a bogus match.pd pattern (but the issue might be in fold-const.cc as well).
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 Richard Biener changed: What|Removed |Added Keywords||build, ice-on-valid-code CC||rguenth at gcc dot gnu.org Target Milestone|--- |13.0
[Bug tree-optimization/107302] [13 Regression] ICE in as_a, at is-a.h:242 since r13-3327-g46a8e017d048ec32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107302 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P1 Status|NEW |ASSIGNED --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/107302] [13 Regression] ICE in as_a, at is-a.h:242 since r13-3327-g46a8e017d048ec32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107302 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |13.0 Last reconfirmed||2022-10-18 Status|UNCONFIRMED |NEW
[Bug target/107271] [13 Regression] ICE: in expand_vec_perm_shufps_shufps, at config/i386/i386-expand.cc:19676 with __builtin_shuffle() since r13-2843-g3db8e9c2422d924a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107271
--- Comment #3 from Hongtao.liu ---
I remember GIMPLE will canonicalize the selector index to make the first index
always comes the frist vector, means
It excepts canonicalized form like { 3, 0, 0, 4 } with op0 and op1 swapped.
[Bug fortran/107214] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107214 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid Priority|P3 |P1
[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/107179] [11/12/13 Regression] requires-expression gives hard error for inaccessible constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107179 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/107301] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107301 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-18 Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Component|translation |tree-optimization --- Comment #1 from Richard Biener --- Confirmed. We fail to check whether we can duplicate a block.
[Bug lto/91299] [10/11/12/13 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 Richard Biener changed: What|Removed |Added Status|WAITING |NEW Target Milestone|--- |10.5 CC||hubicka at gcc dot gnu.org Priority|P3 |P2 --- Comment #15 from Richard Biener --- 1 a-weakdef.o 2 195 5359582ee909af0f PREEMPTED_REG foo 198 5359582ee909af0f PREVAILING_DEF main Considering foo/0 with 3 size to be inlined into main/1 in unknown:-1 Estimated badness is -inf, frequency 1.00. Badness calculation for main/1 -> foo/0 size growth -1, time 0.00 unspec 2.00 big_speedup -inf: Growth -1 <= 0 Adjusted by hints -inf Updated mod-ref summary for main/1 loads: Limits: 32 bases, 16 refs stores: Limits: 32 bases, 16 refs optimized: Inlined foo/0 into main/1 which now has time 2.00 and size 3, net change of -1. but foo/0 (foo) @0x765b5110 Type: function definition analyzed Visibility: externally_visible preempted_reg external public weak References: Referring: Read from file: a-weakdef.o Availability: available Unit id: 1 Function flags: count:1073741824 (estimated locally) Called by: main/1 (1073741824 (estimated locally),1.00 per call) Calls: Honza? This looks like a bug in handling of PREEMTED_REG? Or do we apply some sort of ODR argument here? We also see 'foo' as 'const' at IPA time (but at local time we see it's interposable and thus do not analyze it)
[Bug tree-optimization/107301] [13 Regression] ICE in duplicate_block, at cfghooks.cc:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107301 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5ad3cc1ecc3c7c61d5e319f74cb7287fb80944fd commit r13-3352-g5ad3cc1ecc3c7c61d5e319f74cb7287fb80944fd Author: Richard Biener Date: Tue Oct 18 09:38:03 2022 +0200 tree-optimization/107301 - check if we can duplicate block before doing so Path isolation failed to do that. PR tree-optimization/107301 * gimple-ssa-isolate-paths.cc (handle_return_addr_local_phi_arg): Check whether we can duplicate the block. (find_implicit_erroneous_behavior): Likewise. * gcc.dg/torture/pr107301.c: New testcase.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4dda30e9910c4f04a6258b053401249e213f29be
commit r13-3353-g4dda30e9910c4f04a6258b053401249e213f29be
Author: Jakub Jelinek
Date: Tue Oct 18 10:31:20 2022 +0200
middle-end IFN_ASSUME support [PR106654]
My earlier patches gimplify the simplest non-side-effects assumptions
into if (cond) ; else __builtin_unreachable (); and throw the rest
on the floor.
The following patch attempts to do something with the rest too.
For -O0, it throws the more complex assumptions on the floor,
we don't expect optimizations and the assumptions are there to allow
optimizations. Otherwise arranges for the assumptions to be
visible in the IL as
.ASSUME (_Z2f4i._assume.0, i_1(D));
call where there is an artificial function like:
bool _Z2f4i._assume.0 (int i)
{
bool _2;
[local count: 1073741824]:
_2 = i_1(D) == 43;
return _2;
}
with the semantics that there is UB unless the assumption function
would return true.
Aldy, could ranger handle this? If it sees .ASSUME call,
walk the body of such function from the edge(s) to exit with the
assumption that the function returns true, so above set _2 [true, true]
and from there derive that i_1(D) [43, 43] and then map the argument
in the assumption function to argument passed to IFN_ASSUME (note,
args there are shifted by 1)?
During gimplification it actually gimplifies it into
[[assume (D.2591)]]
{
{
i = i + 1;
D.2591 = i == 44;
}
}
which is a new GIMPLE_ASSUME statement wrapping a GIMPLE_BIND and
specifying a boolean_type_node variable which contains the result.
The GIMPLE_ASSUME then survives just a couple of passes and is lowered
during gimple lowering into an outlined separate function and
IFN_ASSUME call. Variables declared inside of the
condition (both static and automatic) just change context, automatic
variables from the caller are turned into parameters (note, as the code
is never executed, I handle this way even non-POD types, we don't need to
bother pretending there would be user copy constructors etc. involved).
The assume_function artificial functions are then optimized until the
new assumptions pass which doesn't do much right now but I'd like to see
there the backwards ranger walk and filling up of SSA_NAME_RANGE_INFO
for the parameters.
There are a few further changes I'd like to do, like ignoring the
.ASSUME calls in inlining size estimations (but haven't figured out where
it is done), or for LTO arrange for the assume functions to be emitted
in all partitions that reference those (usually there will be just one,
unless code with the assumption got inlined, versioned etc.).
2022-10-18 Jakub Jelinek
PR c++/106654
gcc/
* gimple.def (GIMPLE_ASSUME): New statement kind.
* gimple.h (struct gimple_statement_assume): New type.
(is_a_helper ::test,
is_a_helper ::test): New.
(gimple_build_assume): Declare.
(gimple_has_substatements): Return true for GIMPLE_ASSUME.
(gimple_assume_guard, gimple_assume_set_guard,
gimple_assume_guard_ptr, gimple_assume_body_ptr,
gimple_assume_body):
New inline functions.
* gsstruct.def (GSS_ASSUME): New.
* gimple.cc (gimple_build_assume): New function.
(gimple_copy): Handle GIMPLE_ASSUME.
* gimple-pretty-print.cc (dump_gimple_assume): New function.
(pp_gimple_stmt_1): Handle GIMPLE_ASSUME.
* gimple-walk.cc (walk_gimple_op): Handle GIMPLE_ASSUME.
* omp-low.cc (WALK_SUBSTMTS): Likewise.
(lower_omp_1): Likewise.
* omp-oacc-kernels-decompose.cc (adjust_region_code_walk_stmt_fn):
Likewise.
* tree-cfg.cc (verify_gimple_stmt, verify_gimple_in_seq_2):
Likewise.
* function.h (struct function): Add assume_function bitfield.
* gimplify.cc (gimplify_call_expr): If the assumption isn't
simple enough, expand it into GIMPLE_ASSUME wrapped block or
for -O0 drop it.
* gimple-low.cc: Include attribs.h.
(create_assumption_fn): New function.
(struct lower_assumption_data): New type.
(find_assumption_locals_r, assumption_copy_decl,
adjust_assumption_stmt_r, adjust_assumption_stmt_op,
lower_assumption): New functions.
(lower_stmt): Handle GIMPLE_ASSUME.
* tree-ssa-ccp.cc (pass_fold_builtins::execute): Remove
IFN_ASSUME calls.
* lto-streamer-out.cc (output_struct_function_base): Pack
assume_function bit.
[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #10 from Richard Biener --- Not a bug.
[Bug c++/107303] New: [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 Bug ID: 107303 Summary: [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 53720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53720=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.C testcase.C: In function 'void foo()': testcase.C:10:6: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3060 10 | u0 *= +__builtin_shufflevector (__builtin_shufflevector (u1, v, 3, 1), u2, 0); 0x7f7d51 gimplify_var_or_parm_decl /repo/gcc-trunk/gcc/gimplify.cc:3060 0x13b9655 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /repo/gcc-trunk/gcc/gimplify.cc:16789 0x13b9527 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /repo/gcc-trunk/gcc/gimplify.cc:17110 0x13ca377 gimplify_modify_expr /repo/gcc-trunk/gcc/gimplify.cc:6121 0x13b9642 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /repo/gcc-trunk/gcc/gimplify.cc:16328 0x13dc96b gimplify_cleanup_point_expr /repo/gcc-trunk/gcc/gimplify.cc:7187 0x13b9a93 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /repo/gcc-trunk/gcc/gimplify.cc:16721 0x13dbfaf gimplify_stmt(tree_node**, gimple**) /repo/gcc-trunk/gcc/gimplify.cc:7187 0x13dbfaf gimplify_body(tree_node*, bool) /repo/gcc-trunk/gcc/gimplify.cc:17588 0x13dc3db gimplify_function_tree(tree_node*) /repo/gcc-trunk/gcc/gimplify.cc:17787 0x11ef407 cgraph_node::analyze() /repo/gcc-trunk/gcc/cgraphunit.cc:676 0x11f1f37 analyze_functions /repo/gcc-trunk/gcc/cgraphunit.cc:1240 0x11f2bcd symbol_table::finalize_compilation_unit() /repo/gcc-trunk/gcc/cgraphunit.cc:2500 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-3351-20221018124615-g35106383c09-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-3351-20221018124615-g35106383c09-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20221018 (experimental) (GCC)
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303
--- Comment #3 from Jakub Jelinek ---
One can see it in the original dump:
(void) (u0 = TARGET_EXPR , 32, 0>> ,
{u2, { 0 }} , { 0, 1 } > , 16, 0>>;, u0 * D.2388;)
where it used to be:
(void) (u0 = TARGET_EXPR , 32, 0>> ,
{u2, { 0 }} , { 0, 1 } > , 16, 0>>>;, u0 * D.2388;)
before but the removal of D.2388 TARGET_EXPR left D.2388 use in the IL without
it being initialized anywhere.
[Bug c++/90201] -Werror=useless-cast in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 85043 ***
[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043 Marek Polacek changed: What|Removed |Added CC||prokofjev.d at gmail dot com --- Comment #13 from Marek Polacek --- *** Bug 90201 has been marked as a duplicate of this bug. ***
[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org
[Bug c++/106863] ICE in write_template_arg_literal, at cp/mangle.cc:3678 since r12-4782-geca767aa51d1f696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106863
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Created attachment 53722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53722=edit
gcc13-pr106863.patch
If we can mangle void{} the same as void(), then this patch achieves that
(or we could call build_functional_cast always, but for
!processing_template_decl it will in the end just return void_node).
Otherwise, we'd need to mangle void_node somehow (how?), but void_node doesn't
always imply void{}, it is created for many other cases.
[Bug c/36113] fix C enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Joseph S. Myers --- Fixed for GCC 13. (Where unsigned long is 64-bit, GCC may choose that instead of unsigned long long for the underlying type of the enum, so you'll get a format checking warning in that case, but all the enum constants now have the enum type if any of them don't fit in int, in accordance with C2X.)
[Bug tree-optimization/106990] Missing TYPE_OVERFLOW_SANITIZED checks in match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106990 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 53723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53723=edit gcc13-pr106990.patch Untested fix.
[Bug tree-optimization/107275] [13 Regression] Recent ifcvt changes resulting in references to SSA_NAME on free list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jeffrey A. Law --- Fixed by Andre's patch on the trunk.
[Bug c/36113] fix C enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
--- Comment #7 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:3b3083a598ca3f4b6203284e01ed39ab6ff0844f
commit r13-3360-g3b3083a598ca3f4b6203284e01ed39ab6ff0844f
Author: Joseph Myers
Date: Tue Oct 18 14:07:27 2022 +
c: C2x enums wider than int [PR36113]
C2x has two enhancements to enumerations: allowing enumerations whose
values do not all fit in int (similar to an existing extension), and
allowing an underlying type to be specified (as in C++). This patch
implements the first of those enhancements.
Apart from adjusting diagnostics to reflect this being a standard
feature, there are some semantics differences from the previous
extension:
* The standard feature gives all the values of such an enum the
enumerated type (while keeping type int if that can represent all
values of the enumeration), where previously GCC only gave those
values outside the range of int the enumerated type. This change
was previously requested in PR 36113; it seems unlikely that people
are depending on the detail of the previous extension that some
enumerators had different types to others depending on whether their
values could be represented as int, and this patch makes the change
to types of enumerators unconditionally (if that causes problems in
practice we could always make it conditional on C2x mode instead).
* The types *while the enumeration is being defined*, for enumerators
that can't be represented as int, are now based more directly on the
types of the expressions used, rather than a possibly different type
with the right precision constructed using c_common_type_for_size.
Again, this change is made unconditionally.
* Where overflow (or wraparound to 0, in the case of an unsigned type)
when 1 is implicitly added to determine the value of the next
enumerator was previously an error, it now results in a wider type
with the same signedness (as the while-being-defined type of the
previous enumerator) being chosen, if available.
When a type is chosen in such an overflow case, or when a type is
chosen for the underlying integer type of the enumeration, it's
possible that (unsigned) __int128 is chosen. Although C2x allows for
such types wider than intmax_t to be considered extended integer
types, we don't have various features required to do so (integer
constant suffixes; sufficient library support would also be needed to
define the associated macros for printf/scanf conversions, and
typedef names would need to be defined). Thus, there are
also pedwarns for exceeding the range of intmax_t / uintmax_t, as
while in principle exceeding that range is OK, it's only OK in a
context where the relevant types meet the requirements for extended
integer types, which does not currently apply here.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also
manually checked diagnostics for c2x-enum-3.c with -m32 to confirm the
diagnostics in that { target { ! int128 } } test are as expected.
PR c/36113
gcc/c-family/
* c-common.cc (c_common_type_for_size): Add fallback to
widest_unsigned_literal_type_node or
widest_integer_literal_type_node for precision that may not
exactly match the precision of those types.
gcc/c/
* c-decl.cc (finish_enum): If any enumerators do not fit in int,
convert all to the type of the enumeration. pedwarn if no integer
type fits all enumerators and default to
widest_integer_literal_type_node in that case. Otherwise pedwarn
for type wider than intmax_t.
(build_enumerator): pedwarn for enumerators outside the range of
uintmax_t or intmax_t, and otherwise use pedwarn_c11 for
enumerators outside the range of int. On overflow, attempt to
find a wider type that can hold the value of the next enumerator.
Do not convert value to type determined with
c_common_type_for_size.
gcc/testsuite/
* gcc.dg/c11-enum-1.c, gcc.dg/c11-enum-2.c, gcc.dg/c11-enum-3.c,
gcc.dg/c2x-enum-1.c, gcc.dg/c2x-enum-2.c, gcc.dg/c2x-enum-3.c,
gcc.dg/c2x-enum-4.c, gcc.dg/c2x-enum-5.c: New tests.
* gcc.dg/pr30260.c: Explicitly use -std=gnu11. Update expected
diagnostics.
* gcc.dg/torture/pr25183.c: Update expected diagnostics.
[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48379 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #4 from David Crocker --- I too am getting fed up with having to add an explicit cast to double to suppress the warning whenever I pass a float to a varargs function. I have probably spent a few hours this year adding these casts. As has already been said, nothing can he done about the promotion in this context, so it's not worth warning about. Whereas in other situations, the warning is very useful to me because I work with embedded processors that have single-precision but not double-precision floating point hardware, so I want to avoid double precision maths as far as possible.
[Bug c++/105045] [modules] Can't deduce defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105045 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 CC||ppalka at gcc dot gnu.org --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0101137c7c5d612c0624f9a2fd5198b302243f85 commit r13-3362-g0101137c7c5d612c0624f9a2fd5198b302243f85 Author: Patrick Palka Date: Tue Oct 18 10:57:30 2022 -0400 c++ modules: stream non-trailing default targs [PR105045] This fixes the below testcase in which we neglect to stream the default argument for T only because the subsequent parameter U doesn't also have a default argument. PR c++/105045 gcc/cp/ChangeLog: * module.cc (trees_out::tpl_parms_fini): Don't assume default template arguments must be trailing. (trees_in::tpl_parms_fini): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/pr105045_a.C: New test. * g++.dg/modules/pr105045_b.C: New test. --- Comment #2 from Patrick Palka --- Fixed on trunk
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105045, which changed state. Bug 105045 Summary: [modules] Can't deduce defaulted template parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105045 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043
--- Comment #14 from Marek Polacek ---
I've encountered this bug with:
struct S { };
void g(S&&);
void
f (S&& arg)
{
g(S(arg)); // warning: useless cast to type 'struct S'
}
which doesn't compile without the cast, because then "arg" is an lvalue that
cannot bind to S&&.
I'd like to disable then warning when a class is cast to a non-reference type.
[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100616 Patrick Palka changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #5 from Patrick Palka --- *** Bug 105044 has been marked as a duplicate of this bug. ***
[Bug c++/105044] [modules] ICE in comptypes, at cp/typeck.cc:1531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105044 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- dup of PR100616 I think -- streaming of cNTTP arguments has been fixed on trunk by r13-2953 *** This bug has been marked as a duplicate of bug 100616 ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105044, which changed state. Bug 105044 Summary: [modules] ICE in comptypes, at cp/typeck.cc:1531 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105044 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #1 from Colin Ian King --- See: https://github.com/ColinIanKing/stress-ng/issues/235
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 --- Comment #9 from Mikael Pettersson --- I can confirm that building the latest uClibc-ng for h8300 now succeeds with gcc master @ 4374c424a60777a7658050f0aeb1dcc9af915647.
[Bug middle-end/107304] New: internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 Bug ID: 107304 Summary: internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: colin.king at intel dot com Target Milestone: --- compiling stress-ng using CLFLAGS=-march-tigerlake: git clone https://github.com/ColinIanKing/stress-ng cd stress-ng make clean CFLAGS=-march=tigerlake make -j 8 make stress-ng VERBOSE= make[1]: Entering directory '/home/cking/repos/stress-ng' CC stress-vecshuf.c during RTL pass: expand stress-vecshuf.c: In function 'stress_vecshuf_u128_4.arch_alderlake': stress-vecshuf.c:107:39: internal compiler error: in convert_move, at expr.cc:220 107 | static double TARGET_CLONES OPTIMIZE3 stress_vecshuf_ ## tag ## _ ## elements ( \ | ^~~ stress-vecshuf.c:139:1: note: in expansion of macro 'STRESS_VEC_SHUFFLE' 139 | STRESS_VEC_SHUFFLE(u128, 4) | ^~ 0x7f47b0cfb209 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f47b0cfb2bb __libc_start_main_impl ../csu/libc-start.c:389 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. make[1]: *** [Makefile:504: stress-vecshuf.o] Error 1 make[1]: Leaving directory '/home/cking/repos/stress-ng' make: *** [Makefile:488: all] Error 2 Without CFLAGS=-march=tigerlake it builds fine.
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #3 from Colin Ian King --- Created attachment 53725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53725=edit Got the issue down to a small reproducer Ran code through gcc -E, hacked out the irrelevant code, got it down to the smallest reproducer. Notes: gcc-12 -c stress-vecshuf-repro-small.c -march=tigerlake Removing "arch=alderlake" from target clones makes the issue disappear. Making the for loop to a small number of iterations (e.g. 4) makes the issue disappear too. Compiling without -march=tigerlake makes the issue disappear too.
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #40 from Segher Boessenkool --- Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no meaning. This is invalid RTL. If it ever works, or worked, that is an accident. A MODE_CC stands for a comparison (in the mathematical sense). Saying it is "1" would mean what?
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #2 from Colin Ian King --- Created attachment 53724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53724=edit preprocessed source that can be compiled to show bug This is the pre-processed output from stress-vecshuf.c, compiling it will trigger the issue. gcc-12 -c stress-vecshuf-post-cpp.c -march=tigerlake
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/106959] [13 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads), or ICE in simplify_subreg, at simplify-rtx.cc:7405 since r13-2100-g5cccc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #7 from Aldy Hernandez --- It looks like the 0.0 with the wrong type is there quite early in the pipeline. At least by einline (after SSA and CFG have been built) we have: (gdb) p debug(gs) c_92 = __builtin_copysignf128 (0.0, c_80(D)); c_92 has a type of TFtype: (gdb) p debug_tree(lhs) unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffef251500 precision:127 context > visited var def_stmt 163c_92 = __builtin_copysignf128 (0.0, c_80(D)); version:92> $12 = void Whereas 0.0 has a type of _Float128: (gdb) p gimple_call_arg (gs, 0) $13 = (tree_node *) 0x7fffef54d1a0 (gdb) p debug($13) 0.0 $14 = void (gdb) p debug_tree($13) unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffef2516f8 precision:128> constant 0.0>
[Bug tree-optimization/107302] [13 Regression] ICE in as_a, at is-a.h:242 since r13-3327-g46a8e017d048ec32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107302 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:92ef7822bfd4ea3393e0a1dd40b4abef9fce027f commit r13-3356-g92ef7822bfd4ea3393e0a1dd40b4abef9fce027f Author: Richard Biener Date: Tue Oct 18 10:01:45 2022 +0200 tree-optimization/107302 - fix vec_perm placement for recurrence vect The following fixes the VEC_PERM_EXPR placement when the latch definition is a PHI node. PR tree-optimization/107302 * tree-vect-loop.cc (vectorizable_recurrence): Fix vec_perm placement for a PHI latch def. * gcc.dg/vect/pr107302.c: New testcase.
[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106995 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I will try to find a solution for this.
[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Summary|[10/11/12/13|[10/11/12 |Regression][OpenACC][OpenMP |Regression][OpenACC][OpenMP |] ICE in decompose, at |] ICE in decompose, at |wide-int.h:984 with |wide-int.h:984 with |'#pragma omp/acc atomic |'#pragma omp/acc atomic |capture'|capture' Known to work||13.0 --- Comment #10 from Richard Biener --- I assume it's fixed on trunk.
[Bug ipa/101270] error: inlining failed in call to ‘always_inline’ ‘open.localalias’: function not inlinable with -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101270 --- Comment #2 from Fabian Vogt --- Fails with 12.2.1 the same way.
[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #6 from Aldy Hernandez --- Created attachment 53718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53718=edit preprocessed testcase
[Bug c++/107295] [13 Regression] Rejected code in libreoffice with -m32 since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107295 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 53719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53719=edit gcc13-pr107295.patch Untested fix.
[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/106963] [13 Regression] ICE in vect_gen_perm_mask_checked, at tree-vect-stmts.cc:8606 since r13-2503-gc13223b790bbc5e4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106963 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/107282] ICE on valid code template + overloaded + visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107282 --- Comment #3 from Patrick Palka --- Hmm, that commit seems unrelated. Bisection for me points to r11-2455-gc6ef9d8d3f1122 (with -g).
[Bug target/107131] [11/12/13 Regression] wrong code with -Os -fno-ipa-vrp -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/106923] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512 since r13-2518-ga262f969d6fd936f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Biener --- Honza, can you please look at this?
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #6 from Richard Biener --- Honza?
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/107275] [13 Regression] Recent ifcvt changes resulting in references to SSA_NAME on free list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275 --- Comment #4 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:aae016f99b121b55fc1bcdfc2403fd22f04fa2df commit r13-3355-gaae016f99b121b55fc1bcdfc2403fd22f04fa2df Author: Andre Vieira Date: Tue Oct 18 10:51:09 2022 +0100 ifcvt: Do not lower bitfields if we can't analyze dr's [PR107275] The ifcvt dead code elimination code was not built to deal with inline assembly, loops with such would never be if-converted in the past since we can't do data-reference analysis on them and vectorization would eventually fail. For this reason we now also do not lower bitfields if the data-reference analysis fails, as we would not end up vectorizing it. As a consequence this also fixes this PR as the dead code elimination will not run for such cases and wrongfully eliminate inline assembly statements. gcc/ChangeLog: PR tree-optimization/107275 * tree-if-conv.cc (if_convertible_loop_p_1): Move find_data_references_in_loop call from here... (if_convertible_loop_p): And move data-reference vector initialization from here... (tree_if_conversion):... to here. gcc/testsuite/ChangeLog: * gcc.dg/vect/pr107275.c: New test.
[Bug tree-optimization/99395] s116 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395 --- Comment #4 from Richard Biener --- So in the BB SLP attempt from loop vectorization (or in the BB SLP pass with -fno-predictive-commoning) we get confused during DR group building because of a duplicate access and fixup splitting the candidates at odd points. For the reduced testcase we see [local count: 1063004409]: # i_16 = PHI <_5(5), 0(2)> # ivtmp_18 = PHI _1 = i_16 + 1; _2 = a[_1]; _3 = a[i_16]; _4 = _2 * _3; a[i_16] = _4; _5 = i_16 + 2; _6 = a[_5]; _7 = a[_1]; _8 = _6 * _7; a[_1] = _8; ivtmp_15 = ivtmp_18 - 1; if (ivtmp_15 != 0) goto ; [99.00%] else goto ; [1.00%] so a[_1] is loaded twice because CSE doesn't figure that a[i_16] cannot alias it. That causes us to split the load group.
[Bug c++/107288] Double-free of temporaries created in statement following co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107288
--- Comment #2 from Richard Hodges ---
Some extra diagnostic. Reducing to this minimal program:
```
#include
#include
#include
#include
namespace asio = boost::asio;
struct foo
{
std::string s;
int i;
};
struct bar : foo
{
bar(std::string s, int i)
: foo { .s = std::move(s), .i = i }
{
}
};
asio::awaitable< void >
co_foo(foo)
{
std::printf("%s\n", __func__);
co_return;
};
asio::awaitable< void >
co_bar(foo)
{
std::printf("%s\n", __func__);
co_return;
};
asio::awaitable< void >
co_test()
{
// this works
co_await co_bar(bar("Hello, World!", 1));
// this works but this crashes
co_await co_foo({ .s = "Hello, World!", .i = 1 });
}
int
main()
{
asio::io_context ioc;
asio::co_spawn(ioc, co_test(), asio::detached);
ioc.run();
}
```
Output:
```
co_bar
co_foo
Segmentation fault (core dumped)
```
So it seems related to the interplay between designated initialisers and
coroutines.
[Bug c++/103994] Module ICE in write_var_def with global variable in global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Summary|Module ICE in |Module ICE in write_var_def
|mark_by_value, at |with global variable in
|cp/module.cc:4772 |global module fragment
--- Comment #1 from Patrick Palka ---
With trunk, it seems we now crash from write_var_def. Reduced:
$ cat pr103994.C
module;
# 0 "" 1
struct A { A(int) { } };
const A a = 0;
# 3 "" 2
export module pr103994;
export inline A f() { return a; }
$ g++ -fmodules-ts pr103994.C
pr103994.C:4:8: internal compiler error: in write_var_def, at
cp/module.cc:11649
4 | const A a = 0;
|^~
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 107021, which changed state. Bug 107021 Summary: [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/107004] [12/13 Regression] GCC12 warning in OOB access: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107004 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/107295] [13 Regression] Rejected code in libreoffice with -m32 since r13-3290-g98e341130f87984a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107295
--- Comment #4 from Jakub Jelinek ---
Ah, so that is a different issue then.
And with slightly modified testcase quite old one, which regressed with:
r8-727-g6b6ae9eb9c06b6911573bb9a13cf98b5a7c98b78
template struct VecHelper {
typedef T __attribute__((vector_size(sizeof(int V;
};
template using Vec = typename VecHelper::V;
template using V = Vec<4, T>;
using F = V;
constexpr F F0 = F() + (float) 0.0L;
The problem is that the NOP_EXPR around long double REAL_CST has TREE_CONSTANT
flag and so the CONSTRUCTOR around it and thus we just fold the CONSTRUCTOR in:
case CONSTRUCTOR:
if (TREE_CONSTANT (t) && reduced_constant_expression_p (t))
{
/* Don't re-process a constant CONSTRUCTOR, but do fold it to
VECTOR_CST if applicable. */
verify_constructor_flags (t);
if (TREE_CONSTANT (t))
return fold (t);
}
r = cxx_eval_bare_aggregate (ctx, t, lval,
non_constant_p, overflow_p);
break;
but that handles the case where it has REAL_CST elts, but doesn't handle the
case where it has NOP_EXPRs around them.
I wonder if we just shouldn't call cxx_eval_bare_aggregate always for
VECTOR_TYPE.
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-10-18 Summary|[13 Regression] ICE: in |[13 Regression] ICE: in |gimplify_var_or_parm_decl, |gimplify_var_or_parm_decl, |at gimplify.cc:3060 with|at gimplify.cc:3060 with |nested |nested |__builtin_shufflevector() |__builtin_shufflevector() ||since ||r13-2978-g43faf3e5445b5717 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #1 from Martin Liška --- Started with r13-2978-g43faf3e5445b5717.
[Bug c++/101733] simple-requirement prefixed with typename interpreted as type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101733
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-08-02 00:00:00 |2022-10-18
--- Comment #2 from Jonathan Wakely ---
template
requires requires {
typename T::type;
(typename T::type()); // (1)
T::type();// (2)
typename T::type(); // (3)
}
void f(T) { }
All compilers accept (1) and (2) but only Clang accepts (3)
[Bug c++/106863] ICE in write_template_arg_literal, at cp/mangle.cc:3678 since r12-4782-geca767aa51d1f696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106863 --- Comment #4 from Jakub Jelinek --- And it is valid, https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2351 was applied as a DR to C++11 and later.
[Bug tree-optimization/106931] [12/13 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/94032] Please provide std::string::__resize_default_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94032 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #3 from Jonathan Wakely --- In g:929abc7fe3ad4491ac412ca232e055618559f268 for GCC 21.1
[Bug tree-optimization/99395] s116 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #5 from Richard Biener ---
Fixing the CSE in the testcase by doing
double a[1024];
void foo ()
{
for (int i = 0; i < 1022; i += 2)
{
double tem = a[i+1];
a[i] = tem * a[i];
a[i+1] = a[i+2] * tem;
}
}
gets us
t.c:4:21: note: Detected interleaving load a[i_15] and a[_1]
t.c:4:21: note: Detected interleaving store a[i_15] and a[_1]
t.c:4:21: note: Detected interleaving load of size 2
t.c:4:21: note: _2 = a[i_15];
t.c:4:21: note: tem_10 = a[_1];
t.c:4:21: note: Detected single element interleaving a[_4] step 16
t.c:4:21: note: Detected interleaving store of size 2
t.c:4:21: note: a[i_15] = _3;
t.c:4:21: note: a[_1] = _6;
in the loop pass and failed dependence analysis and
with the SLP pass (no predcom):
t.c:10:1: note: Detected interleaving load a[i_15] and a[_1]
t.c:10:1: note: Detected interleaving load a[i_15] and a[_4]
t.c:10:1: note: Detected interleaving store a[i_15] and a[_1]
t.c:10:1: note: Detected interleaving load of size 3
t.c:10:1: note: _2 = a[i_15];
t.c:10:1: note: tem_10 = a[_1];
t.c:10:1: note: _5 = a[_4];
t.c:10:1: note: Detected interleaving store of size 2
t.c:10:1: note: a[i_15] = _3;
t.c:10:1: note: a[_1] = _6;
which then runs into gap vect issues for how we'd vectorize the three
element load.
The dependence analysis is done by analyzing the validity of the
vectorized load/store placement and the implied motion of the
scalar load/store statements. The missed optimization here would
be the missed alternate placement that would be correct. But I
think the way we form groups would need to be revisited first here.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a23225fb4f764dfc3e3e729c7d7238f03f282aaa
commit r13-3354-ga23225fb4f764dfc3e3e729c7d7238f03f282aaa
Author: Jakub Jelinek
Date: Tue Oct 18 11:37:13 2022 +0200
libstdc++: Partial library support for std::float{16,32,64,128}_t and
std::bfloat16_t
The following patch is partial support for std::float{16,32,64,128}_t
and std::bfloat16_t in libstdc++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html
says that , , and
need changes toom, but that isn't implemented so far.
In the only thing missing I'm aware of is
std::nextafter std::float16_t and std::bfloat16_t overloads (I think
we probably need to implement that out of line somewhere, or inline? -
might
need inline asm barriers) and std::nexttoward overloads (those are
intentional, you said there is a LWG issue about that).
Also, this patch has the glibc 2.26+ std::float128_t support for platforms
where long double isn't IEEE quad format temporarily disabled
because it depends on
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html
changes which aren't in yet.
The patch also doesn't include any testcases to cover the
changes, it isn't clear to me where to put that.
2022-10-18 Jakub Jelinek
PR c++/106652
* include/std/stdfloat: New file.
* include/std/numbers (__glibcxx_numbers): Define and use it
for __float128 explicit instantiations as well as
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* include/std/atomic (atomic<_Float16>, atomic<_Float32>,
atomic<_Float64>, atomic<_Float128>,
atomic<__gnu_cxx::__bfloat16_t>):
New explicit instantiations.
* include/std/type_traits (__is_floating_point_helper<_Float16>,
__is_floating_point_helper<_Float32>,
__is_floating_point_helper<_Float64>,
__is_floating_point_helper<_Float128>,
__is_floating_point_helper<__gnu_cxx::__bfloat16_t>): Likewise.
* include/std/limits (__glibcxx_concat3_, __glibcxx_concat3,
__glibcxx_float_n): Define.
(numeric_limits<_Float16>, numeric_limits<_Float32>,
numeric_limits<_Float64>, numeric_limits<_Float128>,
numeric_limits<__gnu_cxx::__bfloat16_t>): New explicit
instantiations.
* include/bits/std_abs.h (abs): New overloads for
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* include/bits/c++config (_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128):
Define
if long double is IEEE quad.
(__gnu_cxx::__bfloat16_t): New using.
* include/c_global/cmath (acos, asin, atan, atan2, ceil, cos, cosh,
exp, fabs, floor, fmod, frexp, ldexp, log, log10, modf, pow, sin,
sinh, sqrt, tan, tanh, fpclassify, isfinite, isinf, isnan,
isnormal,
signbit, isgreater, isgreaterequal, isless, islessequal,
islessgreater, isunordered, acosh, asinh, atanh, cbrt, copysign,
erf,
erfc, exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma,
llrint, llround, log1p, log2, logb, lrint, lround, nearbyint,
nextafter, remainder, rint, round, scalbln, scalbn, tgamma, trunc,
lerp): New overloads with _Float{16,32,64,128} or
__gnu_cxx::__bfloat16_t types.
* config/os/gnu-linux/os_defines.h (_GLIBCXX_HAVE_FLOAT128_MATH):
Prepare for definition if glibc 2.26 and later implements *f128
APIs
but comment out the actual definition for now.
* include/ext/type_traits.h (__promote<_Float16>,
__promote<_Float32>,
__promote<_Float64>, __promote<_Float128>,
__promote<__gnu_cxx::__bfloat16_t>): New specializations.
* include/Makefile.am (std_headers): Add stdfloat.
* include/Makefile.in: Regenerated.
* include/precompiled/stdc++.h: Include stdfloat.
* testsuite/18_support/headers/stdfloat/types_std.cc: New test.
* testsuite/18_support/headers/limits/synopsis_cxx23.cc: New test.
*
testsuite/26_numerics/headers/cmath/c99_classification_macros_c++23.cc:
New test.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc: New
test.
* testsuite/26_numerics/numbers/4.cc: New test.
* testsuite/29_atomics/atomic_float/requirements_cxx23.cc: New
test.
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #10 from Tobias Burnus --- First, the committed patch handles something which was wrong with *and* without BIND(C) and fixed a genuine bug. * * * (In reply to kargl from comment #9) > Please commit the patch in comment #7. character(kind=4) is not interoperable > (unless C_CHAR is CHARACTER(KIND=4) which it isn't). This is an extension and > gfortran should flag. While I concur that the example in comment 1 is not interoperable according to the Fortran 2018 standard, I think the patch of comment 7 rejects too much (cf. '(b)' below.) Still, I think something should/could be done – hence, I did not close this PR. Namely: * * * For C interoperability, I think there are two parts to this: (a.1) module m; character(kind=4) :: c; end module m (a.2) subroutine foo(x) bind(C) character(kind=4) :: x To both the following applies (F2018, 18.3.1 Interoperability of intrinsic types): "A Fortran intrinsic type with particular type parameter values is interoperable with a C type if the type and kind type parameter value are listed in the table on the same row as that C type. If the type is character, the length type parameter is interoperable if and only if its value is one." Hence, neither 'foo' nor 'c' are interoperable. (b) subroutine bar(x, y, z) bind(C) character(kind=4,len=*) :: x character(kind=4) :: y(:) character(kind=4), allocatable :: z This one is valid as F2018's "18.3.6 Interoperability of procedures and procedure interfaces" states: "A Fortran procedure interface is interoperable with a C function prototype if ... (5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and either ... • the dummy argument is a nonallocatable nonpointer variable of type CHARACTER with assumed character length and the formal parameter is a pointer to CFI_cdesc_t, • the dummy argument is allocatable, assumed-shape, assumed-rank, or a pointer without the CONTIGUOUS attribute, and the formal parameter is a pointer to CFI_cdesc_t, or ..."
[Bug tree-optimization/107302] [13 Regression] ICE in as_a, at is-a.h:242 since r13-3327-g46a8e017d048ec32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107302 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug middle-end/107262] ICE: in as_a, at machmode.h:366 with __bf16 arithmetics at -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107262 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-10-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53721=edit gcc13-pr107262.patch Untested fix. Thanks for the report.
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
So, cp_build_modify_expr calls stabilize_expr on UNARY_PLUS_EXPR of a
TARGET_EXPR.
stabilize_expr wraps it into (another) TARGET_EXPR, puts the TARGET_EXPR as an
initialization statement and returns the TARGET_EXPR_SLOT.
With the TARGET_EXPR_SLOT being used in places other than the
TARGET_EXPR_{SLOT,INITIAL} the r13-2978 change doesn't look correct, because
it replaces the outer TARGET_EXPR with the inner one, but the slot of the outer
might be used elsewhere.
Now, maybe with the nested TARGET_EXPR case we never use the inner
TARGET_EXPR's slot outside of the outer TARGET_EXPR, if that is the case,
perhaps we could still do the optimization, but keep the outer TARGET_EXPR
rather than inner, strip the inner TARGET_EXPR from outer TARGET_EXPR's
initializer and replace all occurrences of the inner slot with the outer slot?
[Bug c/107306] New: [12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107306
Bug ID: 107306
Summary: [12/13 Regression] ICE: verify_gimple failed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r12 and file gcc.target/i386/pr101636.c :
$ gcc-13-20221016 -c pr101636.c -fgimple
pr101636.c: In function 'bar':
pr101636.c:93:1: error: incorrect type of vector 'constructor' elements
93 | }
| ^
{_150, _149, _148, _147, _146, _145, _144, _143, _142, _141, _140, _139, _138,
_137, _136, _135}
_151 = {_150, _149, _148, _147, _146, _145, _144, _143, _142, _141, _140, _139,
_138, _137, _136, _135};
during IPA pass: *free_lang_data
pr101636.c:93:1: internal compiler error: verify_gimple failed
0xf31434 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.cc:5649
0xdce16e execute_function_todo
../../gcc/passes.cc:2091
0xdceb8d do_per_function
../../gcc/passes.cc:1701
0xdcebf2 execute_todo
../../gcc/passes.cc:2145
[Bug c/107305] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107305 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-10-18 --- Comment #1 from Marek Polacek --- Confirmed. Without -fgimple: 107305.c:4:1: error: ‘__GIMPLE’ only valid with ‘-fgimple’ 4 | __GIMPLE int | ^~~~ during GIMPLE pass: lower 107305.c: In function ‘foo’: 107305.c:5:1: internal compiler error: in maybe_canonicalize_mem_ref_addr, at gimple-fold.cc:5976 5 | foo (int n) | ^~~ 0xf6da98 maybe_canonicalize_mem_ref_addr /home/mpolacek/src/gcc/gcc/gimple-fold.cc:5976 0xf6e630 fold_stmt_1 /home/mpolacek/src/gcc/gcc/gimple-fold.cc:6134 0xf6f28b fold_stmt(gimple_stmt_iterator*) /home/mpolacek/src/gcc/gcc/gimple-fold.cc:6379 0x29c1e62 lower_stmt /home/mpolacek/src/gcc/gcc/gimple-low.cc:784 0x29bff00 lower_sequence /home/mpolacek/src/gcc/gcc/gimple-low.cc:228 0x29c2300 lower_gimple_bind /home/mpolacek/src/gcc/gcc/gimple-low.cc:873 0x29bfb59 lower_function_body /home/mpolacek/src/gcc/gcc/gimple-low.cc:118 0x29bfe7c execute /home/mpolacek/src/gcc/gcc/gimple-low.cc:205
