[Bug tree-optimization/36010] Loop interchange not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36010 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Hmm, the condition seems to be superfluous - we don't (in this case?) associate when moving the load/store back into the loop or when we perform the interchange? In fact the comment before the block suggests that. But yes, with -O2 -floop-interchange -ffast-math we now interchange the original testcase (and the case from bwaves). This was fixed with r8-5164-gfbdec14e80e939 which also introduced this check for associativity.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #48 from Richard Biener --- (In reply to OH from comment #47) > Will/Could this be back-ported to the 12.x or lower versions? (Wasn't clear > to me from previous comments if this would be the case). Changing the behavior mid-release is not a good idea, so no.
[Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #8 from rguenther at suse dot de ---
On Tue, 17 Oct 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
>
> --- Comment #7 from Hongtao.liu ---
> (In reply to rguent...@suse.de from comment #6)
> > On Mon, 16 Oct 2023, crazylht at gmail dot com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
> > >
> > > --- Comment #5 from Hongtao.liu ---
> > > (In reply to Richard Biener from comment #3)
> > > > for (unsigned i = 0; i != skipn - 1; i++)
> > > > begin = wi::mul (begin, wi::to_wide (step_expr));
> > > >
> > > > (gdb) p skipn
> > > > $5 = 4294967292
> > > >
> > > > niters is 4294967292 in vect_update_ivs_after_vectorizer. Maybe the
> > > > loop
> > > > should terminate when begin is zero. But I wonder why we pass in
> > > > 'niters'
> > > Here, it want to calculate begin * pow (step_expr, skipn), yes we can
> > > just skip
> > > the loop when begin is 0.
> >
> > I mean terminate it when the multiplication overflowed to zero.
> for pow (3, skipn), it will never overflowed to zero.
> To solve this problem once and for all, I'm leaning towards setting a
> threshold
> in vect_can_peel_nonlinear_iv_p for vect_step_op_mul,if step_expr is not
> exact_log2() and niter > TYPE_PRECISION (step_expr) we give up on doing
> vectorization.
Hm, yeah - that's probably best.
> >
> > As for the MASK_ thing the skip is to be interpreted negative (we
> > should either not use a 'tree' here or make it have the correct type
> > maybe). Can we even handle this here? It would need to be
> > a division, no?
> >
> > So I think we need to disable non-linear IV or masked peeling for
> > niter/aligment? But I wonder how we run into this with plain -O3.
> I think we already disabled negative niters_skip in
> vect_can_peel_nonlinear_iv_p.
>
> 416 /* Also doens't support peel for neg when niter is variable.
> 1417 ??? generate something like niter_expr & 1 ? init_expr : -init_expr?
> */
> 1418 niters_skip = LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo);
> 1419 if ((niters_skip != NULL_TREE
> 1420 && TREE_CODE (niters_skip) != INTEGER_CST)
But we end up here with niters_skip being INTEGER_CST and ..
> 1421 || (!vect_use_loop_mask_for_alignment_p (loop_vinfo)
possibly vect_use_loop_mask_for_alignment_p. Note
LOOP_VINFO_PEELING_FOR_ALIGNMENT < 0 simply means the amount of
peeling is unknown.
But I wonder how we run into this on x86 without enabling
loop masking ...
> 1422 && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0))
> 1423{
> 1424 if (dump_enabled_p ())
> 1425dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> 1426 "Peeling for alignement is not supported"
> 1427 " for nonlinear induction when niters_skip"
> 1428 " is not constant.\n");
> 1429 return false;
> 1430}
[Bug middle-end/111843] [meta-bug] wrong-code due to -fstack-reuse=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111843 Eric Gallager changed: What|Removed |Added Keywords||meta-bug CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Don't meta-bugs usually put all their other bugs in the "Depends on" field, rather than "Blocks"?
[Bug c++/111842] Unable to disable conversion warning in case of _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111842 --- Comment #10 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > (In reply to n.deshm...@samsung.com from comment #5) > > The code is part of a third party library hence adding a explicit cast is > > not possible. > > Well that third party library is NOT valid C++ code ... The whole point of > the warning (and the reason why -Wno-pedantic does not turn off the warning) > is point that out and more over point out the code should be fixed. That is not a reason that I have ever heard for not assigning a flag to a warning before. I was under the impression that the principle of "All warnings should have a flag assigned to them" held regardless of how invalid the code they warn about is, or how badly said code should be fixed. Again, see bug 44209.
[Bug target/111720] RISC-V: Ugly codegen in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #13 from JuzheZhong ---
Confirm ARM SVE has the same issue:
https://godbolt.org/z/TjcaM6xsP
#include
void fn(uint8_t * __restrict out) {
uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7,
1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9};
uint8_t m = 1;
svint8_t varr = *(svint8_t*)arr;
*(svint8_t*)out = varr;
}
ARM GCC:
fn:
adrpx1, .LANCHOR0
add x1, x1, :lo12:.LANCHOR0
sub sp, sp, #32
ptrue p7.b, all
ldp q31, q30, [x1] -> redundant stack spillings.
stp q31, q30, [sp] -> redundant stack spillings.
ld1bz31.b, p7/z, [sp]
st1bz31.b, p7, [x0]
add sp, sp, 32
ret
ARM clang:
fn: // @fn
ptrue p0.b
adrpx8, .L__const.fn.arr
add x8, x8, :lo12:.L__const.fn.arr
ld1b{ z0.b }, p0/z, [x8]
st1b{ z0.b }, p0, [x0]
ret
Hi, Richard. Could you comment this issue ?
Thanks.
[Bug c++/111846] New: ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846 Bug ID: 111846 Summary: ice in exact_div, at poly-int.h:2156 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 56130 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56130&action=edit gzipped C++ source code For the attached C++ source code, recent gcc trunk does this: $ ../results/bin/gcc -c -O3 -march=znver2 -ffast-math bug966.cc during GIMPLE pass: slp equalizer.cc: In function ‘void eq_update(void*, void*)’: equalizer.cc:147:13: internal compiler error: in exact_div, at poly-int.h:2156 0x20fe038 vectorizable_simd_clone_call(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*, gimple**, _slp_tree*, vec*) ../../trunk.year/gcc/tree-vect-stmts.cc:0 0x20d4756 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) ../../trunk.year/gcc/tree-vect-stmts.cc:12789 The bug first seems to occur sometime between g:530babc2058be5f2 and g:78dd49f387c515a6
[Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #9 from Hongtao.liu ---
> But we end up here with niters_skip being INTEGER_CST and ..
>
> > 1421 || (!vect_use_loop_mask_for_alignment_p (loop_vinfo)
>
> possibly vect_use_loop_mask_for_alignment_p. Note
> LOOP_VINFO_PEELING_FOR_ALIGNMENT < 0 simply means the amount of
> peeling is unknown.
>
> But I wonder how we run into this on x86 without enabling
> loop masking ...
>
> > 1422 && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0))
> > 1423{
> > 1424 if (dump_enabled_p ())
> > 1425dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> > 1426 "Peeling for alignement is not supported"
> > 1427 " for nonlinear induction when niters_skip"
> > 1428 " is not constant.\n");
> > 1429 return false;
> > 1430}
Can you point out where it's assigned as nagative?
I saw LOOP_VINFO_MASK_SKIP_NITERS is only assigned in
vect_prepare_for_masked_peels.
when LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) > 0
it's assigned as vf-npeel(will npeel > vf?)
else
it's assigned in get_misalign_in_elems and should be positive.
HOST_WIDE_INT elem_size
= int_cst_value (TYPE_SIZE_UNIT (TREE_TYPE (vectype)));
tree elem_size_log = build_int_cst (type, exact_log2 (elem_size));
/* Create: misalign_in_bytes = addr & (target_align - 1). */
tree int_start_addr = fold_convert (type, start_addr);
tree misalign_in_bytes = fold_build2 (BIT_AND_EXPR, type, int_start_addr,
target_align_minus_1);
/* Create: misalign_in_elems = misalign_in_bytes / element_size. */
tree misalign_in_elems = fold_build2 (RSHIFT_EXPR, type, misalign_in_bytes,
elem_size_log);
return misalign_in_elems;
void
vect_prepare_for_masked_peels (loop_vec_info loop_vinfo)
{
tree misalign_in_elems;
tree type = TREE_TYPE (LOOP_VINFO_NITERS (loop_vinfo));
gcc_assert (vect_use_loop_mask_for_alignment_p (loop_vinfo));
/* From the information recorded in LOOP_VINFO get the number of iterations
that need to be skipped via masking. */
if (LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) > 0)
{
poly_int64 misalign = (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
- LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo));
misalign_in_elems = build_int_cst (type, misalign);
}
else
{
gimple_seq seq1 = NULL, seq2 = NULL;
misalign_in_elems = get_misalign_in_elems (&seq1, loop_vinfo);
misalign_in_elems = fold_convert (type, misalign_in_elems);
misalign_in_elems = force_gimple_operand (misalign_in_elems,
&seq2, true, NULL_TREE);
gimple_seq_add_seq (&seq1, seq2);
if (seq1)
{
edge pe = loop_preheader_edge (LOOP_VINFO_LOOP (loop_vinfo));
basic_block new_bb = gsi_insert_seq_on_edge_immediate (pe, seq1);
gcc_assert (!new_bb);
}
}
if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"misalignment for fully-masked loop: %T\n",
misalign_in_elems);
LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo) = misalign_in_elems;
vect_update_inits_of_drs (loop_vinfo, misalign_in_elems, MINUS_EXPR);
}
[Bug debug/111847] New: Debug info for structure members is not generated for structure in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111847
Bug ID: 111847
Summary: Debug info for structure members is not generated for
structure in template class
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: EngyCZ at gmail dot com
Target Milestone: ---
Created attachment 56131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56131&action=edit
Sample source code
Source code attached.
No debug information for "a" member of structure variable *Str (A.Str->a)
GDB reports "No data fields":
(gdb) print &x
$1 = 0x7fffe1cf ""
(gdb) print A
$2 = {> = {Str = 0x7fffe1cf}, }
^^
[Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #10 from Richard Biener ---
(In reply to Hongtao.liu from comment #9)
> > But we end up here with niters_skip being INTEGER_CST and ..
> >
> > > 1421 || (!vect_use_loop_mask_for_alignment_p (loop_vinfo)
> >
> > possibly vect_use_loop_mask_for_alignment_p. Note
> > LOOP_VINFO_PEELING_FOR_ALIGNMENT < 0 simply means the amount of
> > peeling is unknown.
> >
> > But I wonder how we run into this on x86 without enabling
> > loop masking ...
> >
> > > 1422 && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0))
> > > 1423{
> > > 1424 if (dump_enabled_p ())
> > > 1425dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> > > 1426 "Peeling for alignement is not supported"
> > > 1427 " for nonlinear induction when niters_skip"
> > > 1428 " is not constant.\n");
> > > 1429 return false;
> > > 1430}
>
> Can you point out where it's assigned as nagative?
> I saw LOOP_VINFO_MASK_SKIP_NITERS is only assigned in
> vect_prepare_for_masked_peels.
Yes.
> when LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) > 0
> it's assigned as vf-npeel(will npeel > vf?)
npeel should be < vf
OK, so it should be positive indeed. But LOOP_VINFO_MASK_SKIP_NITERS
(when vect_use_loop_mask_for_alignment_p ()) means that the
first vector iteration only processes the first
vf - LOOP_VINFO_MASK_SKIP_NITERS scalar iterations, so a
for (i = start; i < end; ++i)
..
loop is executed as
for (i = start - LOOP_VINFO_MASK_SKIP_NITERS; i < end; ++i)
if (i >= start)
{
}
that is, the loop mask is used to mask out the first
LOOP_VINFO_MASK_SKIP_NITERS elements.
It's a bit difficult to force peeling for alignment on x86, but
usually -fno-vect-cost-model will peel a store (it will peel the
most used ref for alignment). With --param vect-partial-vector-usage=2
you should get AVX512 masked alignment peeling then I think.
[Bug debug/111847] Debug info for structure member is not generated for structure in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111847 Jiří Engelthaler changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jiří Engelthaler --- Wrong bug report
[Bug modula2/111756] Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 Gaius Mulley changed: What|Removed |Added Attachment #56122|0 |1 is obsolete|| --- Comment #4 from Gaius Mulley --- Created attachment 56132 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56132&action=edit Proposed fix v6, Make-lang.in uses -M and friends, gm2 and cc1gm2 implement -M* Here is a proposed fix and patch, the Make-lang.in now uses dependencies and gm2 cc1gm2 understands all the -M* options. Bootstrapped on x86_64 and powerpc64le with no extra regression failures. I've also seen it re-build with the BuildInline procedure introduced to M2Quads.mod (rebuild). Introduce BuildInline into M2Quads.def and P3Build.bnf. Rebuild (seeing M2Quads.mod rebuild due to dependencies).
[Bug c++/111846] ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|unknown |14.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-on-valid-code Last reconfirmed||2023-10-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Probably mine, reducing.
[Bug ada/110398] [12/13/14 regression] internal error on call with parameter of predicated subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110398 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |12.4
[Bug middle-end/110764] [12/13/14 Regression] False positive -Warray-bounds warning swapping std::thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.4
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.5
[Bug analyzer/110700] [12/13 Regression] ICE with -fanalyzer --analyzer-checker=taint on division of tainted floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110700 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.4
[Bug analyzer/110882] [13 Regression] ICE with -fanalyzer on zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110882 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug c++/51571] No named return value optimization while adding a dummy scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 Richard Biener changed: What|Removed |Added Target Milestone|14.0|---
[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/110040] rs6000 port emits dead mfvsrd instruction for simple test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040 Richard Biener changed: What|Removed |Added Target Milestone|14.0|---
[Bug tree-optimization/110043] [14 Regression] ice in size_remaining, at pointer-query.cc:875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
We run into
void access_ref::add_offset (const offset_int &min, const offset_int &max)
{
if (min <= max)
{
/* To add an ordinary range just add it to the bounds. */
offrng[0] += min;
offrng[1] += max;
with
(gdb) p offrng[0]
$20 = {> = {val = {0, 0}, len = 1},
static is_sign_extended = true, static needs_write_val_arg = false}
(gdb) p offrng[1]
$21 = {> = {val = {9223372036854775807,
140737488342928}, len = 1}, static is_sign_extended = true,
static needs_write_val_arg = false}
(gdb) p min
$22 = (const offset_int &) @0x7fffd320: {> = {
val = {0, 15546413}, len = 1}, static is_sign_extended = true,
static needs_write_val_arg = false}
(gdb) p max
$23 = (const offset_int &) @0x7fffd338: {> = {
val = {-1, 9223372036854775807}, len = 2}, static is_sign_extended = true,
static needs_write_val_arg = false}
min <= max which is supposed to use a signed compare, returns true and
then the offrng[1] += max operation overflows offrng[1] to negative.
Looks like most offset arithmetic in pointer-query should be saturating
somehow ...
[Bug rtl-optimization/110163] [14 Regression] Comparing against a constant string is inefficient on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110163 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug bootstrap/110275] [14 Regression] trunk fails to build with binutils trunk on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110275 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-17 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- still an issue?
[Bug c/111848] New: RISC-V: RVV cost model pick unexpected big LMUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111848
Bug ID: 111848
Summary: RISC-V: RVV cost model pick unexpected big LMUL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
#include
void
f3 (uint8_t *restrict a, uint8_t *restrict b,
uint8_t *restrict c, uint8_t *restrict d,
int n)
{
for (int i = 0; i < n; ++i)
{
a[i * 8] = c[i * 8] + d[i * 8];
a[i * 8 + 1] = c[i * 8] + d[i * 8 + 1];
a[i * 8 + 2] = c[i * 8 + 2] + d[i * 8 + 2];
a[i * 8 + 3] = c[i * 8 + 2] + d[i * 8 + 3];
a[i * 8 + 4] = c[i * 8 + 4] + d[i * 8 + 4];
a[i * 8 + 5] = c[i * 8 + 4] + d[i * 8 + 5];
a[i * 8 + 6] = c[i * 8 + 6] + d[i * 8 + 6];
a[i * 8 + 7] = c[i * 8 + 6] + d[i * 8 + 7];
b[i * 8] = c[i * 8 + 1] + d[i * 8];
b[i * 8 + 1] = c[i * 8 + 1] + d[i * 8 + 1];
b[i * 8 + 2] = c[i * 8 + 3] + d[i * 8 + 2];
b[i * 8 + 3] = c[i * 8 + 3] + d[i * 8 + 3];
b[i * 8 + 4] = c[i * 8 + 5] + d[i * 8 + 4];
b[i * 8 + 5] = c[i * 8 + 5] + d[i * 8 + 5];
b[i * 8 + 6] = c[i * 8 + 7] + d[i * 8 + 6];
b[i * 8 + 7] = c[i * 8 + 7] + d[i * 8 + 7];
}
}
This case pick LMUL = 8 which causes horrible vector register spillings.
After experiment, the ideal LMUL should be 2.
[Bug c/111848] RISC-V: RVV cost model pick unexpected big LMUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111848 --- Comment #1 from JuzheZhong --- Sorry, it pick LMUL = 4: f3: ble a4,zero,.L11 csrrt0,vlenb sllit1,t0,4 csrra6,vlenb sub sp,sp,t1 csrra5,vlenb sllia6,a6,3 sllia5,a5,2 add a6,a6,sp vsetvli a7,zero,e16,m8,ta,ma sllia4,a4,3 vid.v v8 addit6,a5,-1 vand.vi v8,v8,-2 neg t5,a5 vs8r.v v8,0(sp) vadd.vi v8,v8,1 vs8r.v v8,0(a6) j .L7 .L14: vsetvli a7,zero,e16,m8,ta,ma .L7: csrrt0,vlenb sllit0,t0,3 vl8re16.v v16,0(sp) add t0,t0,sp vmv.v.x v8,t6 mv t1,a4 vand.vv v24,v16,v8 mv a6,a4 vl8re16.v v16,0(t0) vand.vv v8,v16,v8 bleua4,a5,.L6 mv a6,a5 .L6: vsetvli zero,a6,e8,m4,ta,ma vle8.v v20,0(a2) vle8.v v16,0(a3) vsetvli a7,zero,e8,m4,ta,ma vrgatherei16.vv v4,v20,v24 vadd.vv v4,v16,v4 vsetvli zero,a6,e8,m4,ta,ma vse8.v v4,0(a0) vle8.v v20,0(a2) vsetvli a7,zero,e8,m4,ta,ma vrgatherei16.vv v4,v20,v8 vadd.vv v4,v4,v16 vsetvli zero,a6,e8,m4,ta,ma vse8.v v4,0(a1) Ideally LMUL should be 2: f3: ble a4,zero,.L9 csrra5,vlenb sllia5,a5,1 vsetvli a7,zero,e16,m4,ta,ma sllia4,a4,3 vid.v v12 addit6,a5,-1 vand.vi v12,v12,-2 neg t5,a5 vadd.vi v16,v12,1 j .L7 .L10: vsetvli a7,zero,e16,m4,ta,ma .L7: vmv.v.x v4,t6 mv t1,a4 vand.vv v20,v12,v4 mv a6,a4 vand.vv v4,v16,v4 bleua4,a5,.L6 mv a6,a5 .L6: vsetvli zero,a6,e8,m2,ta,ma vle8.v v10,0(a2) vle8.v v8,0(a3) vsetvli a7,zero,e8,m2,ta,ma vrgatherei16.vv v2,v10,v20 vadd.vv v2,v8,v2 vsetvli zero,a6,e8,m2,ta,ma vse8.v v2,0(a0) vle8.v v10,0(a2) vsetvli a7,zero,e8,m2,ta,ma vrgatherei16.vv v2,v10,v4 vadd.vv v2,v2,v8 vsetvli zero,a6,e8,m2,ta,ma vse8.v v2,0(a1) add a4,a4,t5 add a0,a0,a5 add a3,a3,a5 add a1,a1,a5 add a2,a2,a5 bgtut1,a5,.L10 .L9: ret
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #57 from Richard Biener --- It might be not ideal but it seems unless somebody finds the time to analyze the difference the "fix" did and thereby identifies the problem itself closing the bug is the most efficient way of dealing with it :/
[Bug tree-optimization/111799] [14 Regression] Missed Dead Code Elimination since r14-2365-g2e406f0753e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
--- Comment #4 from Theodoros Theodoridis ---
Oops, there was a bug in my reduction, here's the fixed code:
https://godbolt.org/z/shxffzs8E
void foo(void);
typedef unsigned short uint16_t;
static int b;
static int c;
static int *f = &b;
static int *ad;
static char(a)(char g, char h) { return g + h; }
static char(d)(char g, char h) { return g * h; }
static void(e)(uint16_t g) {
if (!(((g) >= 1) && ((g) <= 65459))) {
__builtin_unreachable();
}
}
int main() {
b = 0;
for (;; b = 1) {
char i = d(126 | 1, 205);
e(i);
short j;
int k = *f;
j = -21;
for (; j; j = a(j, 7)) e((j ^ k && *f) <= *f);
if (b) break;
ad = &c;
}
if (ad)
;
else
foo();
;
}
trunk -O2:
main:
movl$0, b(%rip)
movl$2, %esi
xorl%ecx, %ecx
xorl%r8d, %r8d
.L7:
movl$-21, %eax
.L2:
testl %ecx, %ecx
je .L26
leal7(%rax), %edx
movsbw %dl, %di
testb %dl, %dl
je .L6
.L5:
movl$8, %eax
cmpb$1, %dl
je .L2
movl%edi, %eax
leal7(%rax), %edx
movsbw %dl, %di
testb %dl, %dl
jne .L5
.L6:
cmpl$1, %esi
je .L27
.L12:
movl$1, %esi
movl$1, %ecx
movl$1, %r8d
jmp .L7
.L26:
testb $1, %al
je .L4
leal7(%rax), %edx
movsbw %dl, %ax
testb %dl, %dl
je .L6
.L4:
leal14(%rax), %edx
movsbw %dl, %ax
testb %dl, %dl
jne .L4
cmpl$1, %esi
jne .L12
.L27:
testb %r8b, %r8b
je .L28
movq$c, ad(%rip)
movl%ecx, b(%rip)
.L23:
xorl%eax, %eax
ret
.L28:
cmpq$0, ad(%rip)
jne .L23
pushq %rax
callfoo
xorl%eax, %eax
popq%rdx
ret
13.2 -O2:
main:
movq$c, ad(%rip)
xorl%eax, %eax
movl$1, b(%rip)
ret
the bisection remains the same: r14-2365-g2e406f0753e
[Bug tree-optimization/111846] [14 Regression] ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|c++ |tree-optimization
Target Milestone|--- |14.0
Summary|ice in exact_div, at|[14 Regression] ice in
|poly-int.h:2156 |exact_div, at
||poly-int.h:2156
--- Comment #2 from Richard Biener ---
extern "C" __attribute__((__simd__)) float powf(float, float);
float gv[0][10];
float eq_set_bands_real_adj[0];
void eq_set_bands_real() {
for (int c = 0; c < 10; c++)
for (int i = 0; i < 10; i++)
gv[c][i] = powf(0, eq_set_bands_real_adj[i]) - 1;
}
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
--- Comment #21 from CVS Commits ---
The releases/gcc-11 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:0d005deb6c8a956b4f7ccb6e70e8e7830a40fed9
commit r11-11065-g0d005deb6c8a956b4f7ccb6e70e8e7830a40fed9
Author: liuhongt
Date: Wed Jul 5 13:45:11 2023 +0800
Disparage slightly for the alternative which move DFmode between SSE_REGS
and GENERAL_REGS.
For testcase
void __cond_swap(double* __x, double* __y) {
bool __r = (*__x < *__y);
auto __tmp = __r ? *__x : *__y;
*__y = __r ? *__y : *__x;
*__x = __tmp;
}
GCC-14 with -O2 and -march=x86-64 options generates the following code:
__cond_swap(double*, double*):
movsd xmm1, QWORD PTR [rdi]
movsd xmm0, QWORD PTR [rsi]
comisd xmm0, xmm1
jbe .L2
movqrax, xmm1
movapd xmm1, xmm0
movqxmm0, rax
.L2:
movsd QWORD PTR [rsi], xmm1
movsd QWORD PTR [rdi], xmm0
ret
rax is used to save and restore DFmode value. In RA both GENERAL_REGS
and SSE_REGS cost zero since we didn't disparage the
alternative in movdf_internal pattern, according to register
allocation order, GENERAL_REGS is allocated. The patch add ? for
alternative (r,v) and (v,r) just like we did for movsf/hf/bf_internal
pattern, after that we get optimal RA.
__cond_swap:
.LFB0:
.cfi_startproc
movsd (%rdi), %xmm1
movsd (%rsi), %xmm0
comisd %xmm1, %xmm0
jbe .L2
movapd %xmm1, %xmm2
movapd %xmm0, %xmm1
movapd %xmm2, %xmm0
.L2:
movsd %xmm1, (%rsi)
movsd %xmm0, (%rdi)
ret
gcc/ChangeLog:
PR target/110170
* config/i386/i386.md (movdf_internal): Disparage slightly for
2 alternatives (r,v) and (v,r) by adding constraint modifier
'?'.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110170-3.c: New test.
(cherry picked from commit 37a231cc7594d12ba0822077018aad751a6fb94e)
[Bug tree-optimization/111846] [14 Regression] ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846
--- Comment #3 from Richard Biener ---
We are dividing 4 by 8. We get here with basic-block vectorization and
a group size of 4 but we let vectorizable_simd_clone_call choose its
own vector type (it chooses 8 lanes).
While we properly constrain with
if (!constant_multiple_p (vf * group_size,
n->simdclone->simdlen, &num_calls)
|| n->simdclone->nargs != nargs)
continue;
we seem to cache things in STMT_VINFO_SIMD_CLONE_INFO and this info gets
re-used across a group_size 8 -> 4 transition here. This is because
we have multiple SLP instances each sharing some of the calls (in the end
costs would make vectorization not profitable), vectorizing the CTORs in
[local count: 9759239]:
_14 = eq_set_bands_real_adj[0];
_15 = powf (0.0, _14);
_16 = _15 - 1.0e+0;
_21 = eq_set_bands_real_adj[1];
_22 = powf (0.0, _21);
_23 = _22 - 1.0e+0;
_28 = eq_set_bands_real_adj[2];
_29 = powf (0.0, _28);
_30 = _29 - 1.0e+0;
_35 = eq_set_bands_real_adj[3];
_36 = powf (0.0, _35);
_37 = _36 - 1.0e+0;
_42 = eq_set_bands_real_adj[4];
_43 = powf (0.0, _42);
_44 = _43 - 1.0e+0;
_49 = eq_set_bands_real_adj[5];
_50 = powf (0.0, _49);
_51 = _50 - 1.0e+0;
_56 = eq_set_bands_real_adj[6];
_57 = powf (0.0, _56);
_58 = _57 - 1.0e+0;
_63 = eq_set_bands_real_adj[7];
_64 = powf (0.0, _63);
_65 = _64 - 1.0e+0;
_70 = eq_set_bands_real_adj[8];
_71 = powf (0.0, _70);
_72 = _71 - 1.0e+0;
_77 = eq_set_bands_real_adj[9];
_78 = powf (0.0, _77);
_79 = _78 - 1.0e+0;
_19 = {_30, _37, _44, _51, _58, _65, _72, _79};
_25 = {_44, _51, _58, _65, _72, _79, _16, _23};
_26 = {_58, _65, _72, _79, _16, _23, _30, _37};
_32 = {_72, _79, _16, _23, _30, _37, _44, _51};
_33 = {_16, _23, _30, _37, _44, _51, _58, _65};
MEM [(float *)&gv] = _33;
MEM [(float *)&gv + 32B] = _32;
MEM [(float *)&gv + 64B] = _26;
MEM [(float *)&gv + 96B] = _25;
MEM [(float *)&gv + 128B] = _19;
MEM [(float *)&gv + 160B] = _33;
MEM [(float *)&gv + 192B] = _32;
MEM [(float *)&gv + 224B] = _26;
MEM [(float *)&gv + 256B] = _25;
MEM [(float *)&gv + 288B] = _19;
_82 = {_58, _65, _72, _79};
_83 = {_30, _37, _44, _51};
_84 = {_72, _79, _16, _23};
_85 = {_44, _51, _58, _65};
_86 = {_16, _23, _30, _37};
MEM [(float *)&gv + 320B] = _86;
MEM [(float *)&gv + 336B] = _85;
MEM [(float *)&gv + 352B] = _84;
MEM [(float *)&gv + 368B] = _83;
MEM [(float *)&gv + 384B] = _82;
return;
[Bug middle-end/111845] [14 regression] ICE when building pycryptodome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111845
--- Comment #6 from Jakub Jelinek ---
Same with renamed vars, so that the long variable names don't make it
unreadable:
int a, b;
unsigned int c, d, e;
void
foo (int x)
{
b += d;
c += b < d;
b += e = a < x;
c += b;
c += b < e;
}
I believe the above is equivalent to:
e = a < x;
unsigned c1;
b = __builtin_addc (b, d, e, &c1);
c = __builtin_addc (c, b, c1, &c1);
i.e. b is set to b + d + e where e is in [0, 1] range and c is set to c + b +
carry-out
from the b + d + e additions.
match_uaddc_usubc is called on the _17 = _30 + _31; addition in:
b.0_1 = b;
b.1_2 = (unsigned int) b.0_1;
d.2_3 = d;
_8 = .ADD_OVERFLOW (b.1_2, d.2_3);
_4 = REALPART_EXPR <_8>;
_14 = IMAGPART_EXPR <_8>;
_5 = _14 != 0;
_6 = (unsigned int) _5;
c.6_7 = c;
_31 = _6 + c.6_7;
a.7_9 = a;
_10 = a.7_9 < x_19(D);
_11 = (unsigned int) _10;
e = _11;
_29 = .ADD_OVERFLOW (_4, _11);
_12 = REALPART_EXPR <_29>;
_28 = IMAGPART_EXPR <_29>;
_13 = (int) _12;
b = _13;
_15 = _28 != 0;
_16 = (unsigned int) _15;
_30 = _12 + _16;
_17 = _30 + _31;
c = _17;
return;
and changes it:
@@ -12,14 +12,14 @@ a.7_9 = a;
_10 = a.7_9 < x_19(D);
_11 = (unsigned int) _10;
e = _11;
+_27 = .UADDC (b.1_2, d.2_3, _11);
_29 = .ADD_OVERFLOW (_4, _11);
-_12 = REALPART_EXPR <_29>;
-_28 = IMAGPART_EXPR <_29>;
+_12 = REALPART_EXPR <_27>;
_13 = (int) _12;
b = _13;
-_15 = _28 != 0;
-_16 = (unsigned int) _15;
_30 = _12 + _16;
-_17 = _30 + _31;
+_26 = IMAGPART_EXPR <_27>;
+_25 = .UADDC (c.6_7, _12, _26);
+_17 = REALPART_EXPR <_25>;
c = _17;
return;
That again looks correct to me, except that the dead _30 = _12 + _16 statement
should have been removed as well but wasn't. The bb contains still other dead
statements
but the _30 = _12 + _16; is the only problematic one, as it refers to released
SSA_NAME. After a fast DCE I think the bb would turn into:
b.0_1 = b;
b.1_2 = (unsigned int) b.0_1;
d.2_3 = d;
c.6_7 = c;
a.7_9 = a;
_10 = a.7_9 < x_19(D);
_11 = (unsigned int) _10;
e = _11;
_27 = .UADDC (b.1_2, d.2_3, _11);
_12 = REALPART_EXPR <_27>;
_13 = (int) _12;
b = _13;
_26 = IMAGPART_EXPR <_27>;
_25 = .UADDC (c.6_7, _12, _26);
_17 = REALPART_EXPR <_25>;
c = _17;
return;
[Bug testsuite/110445] [14 Regression] FAIL: gcc.dg/vect/slp-46.c with AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110445 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-17 --- Comment #1 from Richard Biener --- Confirmed now.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/110733] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4259 (unable to generate reloads for: {*one_cmplv16qi2}) with -O -fno-omit-frame-pointer -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110733 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-17 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- This seems to be fixed, at least I can't reproduce on current trunk.
[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-17 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed.
[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110817 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #22 from Richard Biener --- Patch was approved I think?
[Bug target/110733] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4259 (unable to generate reloads for: {*one_cmplv16qi2}) with -O -fno-omit-frame-pointer -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110733 --- Comment #2 from Zdenek Sojka --- (In reply to Richard Biener from comment #1) > This seems to be fixed, at least I can't reproduce on current trunk. Same here. Works fine with g4efe9085d08 (20231011)
[Bug other/110831] [14 regression] gcc.dg/stack-check-3.c ICEs after r14-2822-g499b8079a6419b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110831 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Biener --- So is this ICE fixed now?
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 110838, which changed state. Bug 110838 Summary: [14 Regression] wrong code on x365-3.5, -O3, sign extraction https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/110852] [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-17 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- Confirmed. #1 0x01575f8c in get_predictor_value (predictor=PRED_UNCONDITIONAL, probability=9000) at /space/rguenther/src/gcc/gcc/predict.cc:2695 2695 gcc_assert (probability == -1);
[Bug tree-optimization/110852] [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/110986] [14 Regression] aarch64 has support for conditional not (and vectorized conditional not ) after r14-3110-g7fb65f10285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Priority|P3 |P1
[Bug tree-optimization/111000] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r14-2944-g3d48c11ad08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111000 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Priority|P3 |P1 --- Comment #8 from Richard Biener --- Honza - this shows up frequently.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Richard Biener changed: What|Removed |Added Last reconfirmed|2023-08-20 00:00:00 |2023-10-17 Priority|P3 |P1 --- Comment #4 from Richard Biener --- Re-confirmed.
[Bug tree-optimization/111846] [14 Regression] ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:323209cd73bf1d81d91637677db5883afc8ae5f6 commit r14-4682-g323209cd73bf1d81d91637677db5883afc8ae5f6 Author: Richard Biener Date: Tue Oct 17 13:42:59 2023 +0200 tree-optimization/111846 - put simd-clone-info into SLP tree The following avoids bogously re-using the simd-clone-info we currently hang off stmt_info from two different SLP contexts where a different number of lanes should have chosen a different best simdclone. PR tree-optimization/111846 * tree-vectorizer.h (_slp_tree::simd_clone_info): Add. (SLP_TREE_SIMD_CLONE_INFO): New. * tree-vect-slp.cc (_slp_tree::_slp_tree): Initialize SLP_TREE_SIMD_CLONE_INFO. (_slp_tree::~_slp_tree): Release it. * tree-vect-stmts.cc (vectorizable_simd_clone_call): Use SLP_TREE_SIMD_CLONE_INFO or STMT_VINFO_SIMD_CLONE_INFO dependent on if we're doing SLP. * gcc.dg/vect/pr111846.c: New testcase.
[Bug tree-optimization/111846] [14 Regression] ice in exact_div, at poly-int.h:2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111846 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/111259] [14 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1934 during riscv64 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111259 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed I assume.
[Bug target/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 Richard Biener changed: What|Removed |Added Component|middle-end |target Priority|P3 |P1 Keywords||needs-bisection
[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111262 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Richard Biener --- Neither the reduced nor the unreduced testcase reproduce the issue for me on a x86_64 host.
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-17 Priority|P3 |P1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. We should at least understand what's going on.
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|2023-09-07 00:00:00 |2023-10-17
--- Comment #9 from Richard Biener ---
Re-confirmed.
during GIMPLE pass: slp
t.c: In function 'f':
t.c:3:6: internal compiler error: in to_constant, at poly-int.h:588
3 | void f(unsigned long *expected, svuint64_t values) {
| ^
0xe915f8 poly_int<2u, unsigned long>::to_constant() const
/space/rguenther/src/gcc/gcc/poly-int.h:588
0x1aedf84 vectorizable_slp_permutation_1
/space/rguenther/src/gcc/gcc/tree-vect-slp.cc:8766
0x1aeee54 vectorizable_slp_permutation
/space/rguenther/src/gcc/gcc/tree-vect-slp.cc:8931
0x1ae4321 vect_slp_analyze_node_operations_1
/space/rguenther/src/gcc/gcc/tree-vect-slp.cc:6049
the comment is outdated, we check
unsigned olanes = ncopies * SLP_TREE_LANES (node);
gcc_assert (repeating_p || multiple_p (olanes, nunits));
but then we have to adjust the following to poly arith somehow:
if (repeating_p)
vperm.quick_push ({{p.first, 0}, p.second + active_lane[p.first]});
else
{
/* We checked above that the vectors are constant-length. */
unsigned vnunits = TYPE_VECTOR_SUBPARTS (vtype).to_constant ();
unsigned vi = (active_lane[p.first] + p.second) / vnunits;
unsigned vl = (active_lane[p.first] + p.second) % vnunits;
vperm.quick_push ({{p.first, vi}, vl});
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
--- Comment #10 from Richard Biener ---
Btw, we have
(gdb) p debug (node)
t.c:3:6: note: node 0x3f341d0 (max_nunits=1, refcnt=1) vector(2) long unsigned
int
t.c:3:6: note: op: VEC_PERM_EXPR
t.c:3:6: note: stmt 0 _1 = BIT_FIELD_REF ;
t.c:3:6: note: stmt 1 _4 = BIT_FIELD_REF ;
t.c:3:6: note: lane permutation { 0[0] 0[1] }
t.c:3:6: note: children 0x3f34260
$1 = void
(gdb) p vtype
$2 =
it looks like "compatibility" somehow requires/allows us to V_C_E the
permuted argument to a fixed length vector? Otherwise vect_build_slp_tree_1
of course could check the BIT_FIELD_REF args are fixed length.
[Bug tree-optimization/111328] [14 Regression] ICE: verify_flow_info failed since r14-3459-g0c78240fd7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111328 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-10-17 --- Comment #1 from Richard Biener --- I can not reproduce this issue with current trunk.
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed|2023-09-08 00:00:00 |2023-10-17
[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed|2023-09-13 00:00:00 |2023-10-17 --- Comment #3 from Richard Biener --- Re-confirmed.
[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/111476] [14 regression] ICE when building Ruby 3.1.4 since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111476 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Richard Biener --- I can't reproduce anymore?
[Bug target/111486] [14 Regression] ICE: in require, at machmode.h:313 with -O2 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111486 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Biener --- I assume fixed.
[Bug tree-optimization/111514] [14 Regression] ICE: in lower_bound, at value-range.h:1078 since r14-3644-g1aceceb1e2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111514 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed I think.
[Bug tree-optimization/111520] [14 Regression] ICE: verify_flow_info failed (error: probability of edge 3->8 not initialized) with -O -fsignaling-nans -fharden-compares -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||aoliva at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-10-17 --- Comment #1 from Richard Biener --- Confirmed. Alex, that's from -fharden-compares where new edges do not properly initialize the profile info.
[Bug tree-optimization/111542] [11/12/13/14 Regression] (a==0)&(b==0) into `(a|b) == 0` optimization sometimes gets in the way of other optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111542 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Last reconfirmed|2023-09-24 00:00:00 |2023-10-17 --- Comment #4 from Richard Biener --- Re-confirmed.
[Bug tree-optimization/111671] [14 Regression] ICE in get_default_value, at tree-ssa-ccp.cc:312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111671 Richard Biener changed: What|Removed |Added Status|NEW |WAITING Keywords||needs-bisection --- Comment #2 from Richard Biener --- Seems to be fixed, possibly by the _BitInt<> changes.
[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111702 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-17 Ever confirmed|0 |1 Priority|P3 |P1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/111727] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111727 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P1 --- Comment #3 from Richard Biener --- t.c:5:10: optimized: loop split so maybe a duplicate of the other splitting issues
[Bug tree-optimization/111476] [14 regression] ICE when building Ruby 3.1.4 since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111476 --- Comment #7 from Sam James --- I think slyfox's fix in 043a6fcbc27f8721301eb2f72a7839f54f393003 (PR111559) sorted this, maybe? I can't reproduce it anymore, anyway. Feel free to close as appropriate and I'll reopen if it returns?
[Bug tree-optimization/111734] [14 Regression] wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-omit-frame-pointer -fno-toplevel-reorder -fno-tree-fre'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P1 --- Comment #4 from Richard Biener --- -fno-ipa-modref fixes it. Fails with -O3 -fno-inline -fno-toplevel-reorder -fno-tree-fre --- a-t.c.146t.pre 2023-10-17 15:07:52.544953598 +0200 +++ a-t.c.146t.pre.bad 2023-10-17 15:07:45.788953643 +0200 @@ -25,7 +25,6 @@ int _4; [local count: 1073741824]: - i = &e; g.constprop (&i); i.2_3 = i; _4 = *i.2_3; I think this is a duplicate of the modref / IPA-CP issue (failing to remember the PR number) which IIRC has a patch under review.
[Bug modula2/111756] Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 --- Comment #5 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:ef6696af08a888b53e0e21b17c0a1f87ffdfc3c6 commit r14-4683-gef6696af08a888b53e0e21b17c0a1f87ffdfc3c6 Author: Gaius Mulley Date: Tue Oct 17 14:11:24 2023 +0100 PR modula2/111756: Re-building all-gcc after source changes fails to link When having modula-2 enabled in a development tree and there are any changes that trigger rebuilds in m2/ doing a 'make all-gcc' in the build directory might fail due to lack of dependency tracking. This patch introduces build dependencies into gcc/m2/Make-lang.in using -M* options. The patch also introduces all -M* options to cc1gm2 and gm2. gcc/m2/ChangeLog: PR modula2/111756 * Make-lang.in (CM2DEP): New define conditionally set if ($(CXXDEPMODE),depmode=gcc3). (GM2_1): Use $(CM2DEP). (m2/gm2-gcc/%.o): Ensure $(@D)/$(DEPDIR) is created. Add $(CM2DEP) to the $(COMPILER) command and use $(POSTCOMPILE). (m2/gm2-gcc/m2configure.o): Ditto. (m2/gm2-lang.o): Ditto. (m2/m2pp.o): Ditto. (m2/gm2-gcc/rtegraph.o): Ditto. (m2/mc-boot/$(SRC_PREFIX)%.o): Ditto. (m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto. (m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto. (m2/mc-boot/main.o): Ditto. (mcflex.o): Ditto. (m2/gm2-libs-boot/M2RTS.o): Ditto. (m2/gm2-libs-boot/%.o): Ditto. (m2/gm2-libs-boot/%.o): Ditto. (m2/gm2-libs-boot/RTcodummy.o): Ditto. (m2/gm2-libs-boot/RTintdummy.o): Ditto. (m2/gm2-libs-boot/wrapc.o): Ditto. (m2/gm2-libs-boot/UnixArgs.o): Ditto. (m2/gm2-libs-boot/choosetemp.o): Ditto. (m2/gm2-libs-boot/errno.o): Ditto. (m2/gm2-libs-boot/dtoa.o): Ditto. (m2/gm2-libs-boot/ldtoa.o): Ditto. (m2/gm2-libs-boot/termios.o): Ditto. (m2/gm2-libs-boot/SysExceptions.o): Ditto. (m2/gm2-libs-boot/SysStorage.o): Ditto. (m2/gm2-compiler-boot/M2GCCDeclare.o): Ditto. (m2/gm2-compiler-boot/M2Error.o): Ditto. (m2/gm2-compiler-boot/%.o): Ditto. (m2/gm2-compiler-boot/%.o): Ditto. (m2/gm2-compiler-boot/m2flex.o): Ditto. (m2/gm2-compiler/%.o): Ditto. (m2/gm2-compiler/m2flex.o): Ditto. (m2/gm2-libs-iso/%.o): Ditto. (m2/gm2-libs/%.o): Ditto. (m2/gm2-libs/%.o): Ditto. (m2/gm2-libs/choosetemp.o): Ditto. (m2/boot-bin/mklink$(exeext)): Ditto. (m2/pge-boot/%.o): Ditto. (m2/pge-boot/%.o): Ditto. (m2/gm2-compiler/%.o): Ensure $(@D)/$(DEPDIR) is created and use $(POSTCOMPILE). (m2/gm2-compiler/%.o): Ditto. (m2/gm2-libs-iso/%.o): Ditto. (m2/gm2-libs/%.o): Ditto. * README: Purge out of date info. * gm2-compiler/M2Comp.mod (MakeSaveTempsFileNameExt): Import. (OnExitDelete): Import. (GetModuleDefImportStatementList): Import. (GetModuleModImportStatementList): Import. (GetImportModule): Import. (IsImportStatement): Import. (IsImport): Import. (GetImportStatementList): Import. (File): Import. (Close): Import. (EOF): Import. (IsNoError): Import. (WriteLine): Import. (WriteChar): Import. (FlushOutErr): Import. (WriteS): Import. (OpenToRead): Import. (OpenToWrite): Import. (ReadS): Import. (WriteS): Import. (GetM): Import. (GetMM): Import. (GetDepTarget): Import. (GetMF): Import. (GetMP): Import. (GetObj): Import. (GetMD): Import. (GetMMD): Import. (GenerateDefDependency): New procedure. (GenerateDependenciesFromImport): New procedure. (GenerateDependenciesFromList): New procedure. (GenerateDependencies): New procedure. (Compile): Re-write. (compile): Re-format. (CreateFileStem): New procedure function. (DoPass0): Re-write. (IsLibrary): New procedure function. (IsUnique): New procedure function. (Append): New procedure. (MergeDep): New procedure. (GetRuleTarget): New procedure function. (ReadDepContents): New procedure function. (WriteDep): New procedure. (WritePhonyDep): New procedure. (WriteDepContents): New procedure. (CreateDepFilename): New procedure function. (Pass0CheckDef): New procedure function. (
[Bug target/111745] [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Richard Biener --- .
[Bug target/111753] [14 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*movsf_internal} with -O2 -mavx512bw -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-17 Status|UNCONFIRMED |NEW Priority|P3 |P1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug modula2/111756] Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 --- Comment #6 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug ipa/111789] [14 Regression] runtime Segmentation fault with '-O3 -fno-inline -fno-toplevel-reorder'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111789 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Priority|P3 |P1 --- Comment #5 from Richard Biener --- Another case of the modref/IPA-CP issue? -fno-ipa-modref fixes it.
[Bug tree-optimization/111792] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111792 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug modula2/111756] Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 --- Comment #7 from Gaius Mulley --- Will close once it has been applied to the gcc-13.
[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111262 David Binderman changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #6 from David Binderman --- (In reply to Richard Biener from comment #5) > Neither the reduced nor the unreduced testcase reproduce the issue for me on > a x86_64 host. Agreed. The problem seems to have gone away sometime before date 20230918.
[Bug tree-optimization/111476] [14 regression] ICE when building Ruby 3.1.4 since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111476 Sam James changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug middle-end/111845] [14 regression] ICE when building pycryptodome since r14-1837-g43a3252c42af12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111845 Sam James changed: What|Removed |Added Summary|[14 regression] ICE when|[14 regression] ICE when |building pycryptodome |building pycryptodome since ||r14-1837-g43a3252c42af12 --- Comment #7 from Sam James --- Bisect indicates: 43a3252c42af12ad90082e4088ea58eecd0bf582 is the first bad commit commit 43a3252c42af12ad90082e4088ea58eecd0bf582 Author: Jakub Jelinek Date: Thu Jun 15 09:12:40 2023 +0200 middle-end, i386: Pattern recognize add/subtract with carry [PR79173]
[Bug tree-optimization/111838] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111838 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- This one also started with r14-2852-gf5fb9ff2396fd4
[Bug ada/50502] GNAT fails to compile a modification of B37101A ACATS test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50502 --- Comment #3 from simon at pushface dot org --- The sample compiles without error with GCC 13.1.0 and 14.0.0 20231008. Close as fixed?
[Bug target/111849] New: GCC replaces volatile struct assignments with memcpy calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849 Bug ID: 111849 Summary: GCC replaces volatile struct assignments with memcpy calls Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- On at least some targets where GCC compiles struct assignments to memcpy calls, this pattern is also used when the struct objects involved are volatile-qualified. This is invalid; the memcpy function has no contract to work on volatile objects, and making it compatible with volatile objects would impose extreme implementation constraints that would limit its performance. For example, memcpy may copy the same byte more than once to avoid branches, may use special store instructions with particular cache semantics or data transfer sizes that aren't compatible with various volatile objects like memory-mapped registers, etc. I don't think the C standard is very clear on what is supposed to happen for volatile struct assignments, but they should at least be done in a way that's known to be compatible with any memory-mapped interfaces supported on the target architecture, and the safe behavior is probably implementing them as member-by-member assignment with some fixup for padding. I found this while looking at ways to suppress generation of external calls to memcpy when compiling very restrictive TUs that aren't allowed to make any external calls, and being surprised that "just add volatile" was not one of the ways. I'm filing this as target component because I think the transformation is taking place at the target backend layer on affected targets rather than earlier, but I'm not certain. This should be reviewed and possibly reclassified if that's wrong.
[Bug tree-optimization/111727] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111727 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Started with r14-2944-g3d48c11ad082de (for both testcases)
[Bug tree-optimization/111792] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-3414-g0cfc9c953d0221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111792 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||amacleod at redhat dot com, ||ppalka at gcc dot gnu.org Summary|[14 Regression] wrong code |[14 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu ||since ||r14-3414-g0cfc9c953d0221 --- Comment #2 from Patrick Palka --- Started with r14-3414-g0cfc9c953d0221
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110243 --- Comment #6 from Richard Biener --- Goes away with my fix for PR110243, so I think it's related or even the same.
[Bug middle-end/111845] [14 regression] ICE when building pycryptodome since r14-1837-g43a3252c42af12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111845 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 56133 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56133&action=edit gcc14-pr111845.patch Untested fix.
[Bug ada/55119] Ada.Directories only handles files under 2GB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55119 --- Comment #2 from simon at pushface dot org --- I think this is OBE: fixed 2014-08-01, r213412, by making attr->file_length __int64. The comment in adaint.c is still wrong! Just tested on macOS with a 5GB download.
[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-3875-g9e11ceef165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243 --- Comment #8 from Richard Biener --- See https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621989.html for the prototype patch. I still think it might be too aggressive, an alternative I didn't yet implement is turning everything in split_offset to unsigned arith as IVOPTs does elsewhere anyway.
[Bug libstdc++/111726] lgamma usage in std::poisson_distribution could cause a Data race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111726 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > We should use the non-standard but thread-safe lgamma_r if available. And if not available, we can use std::log(std::abs(std::tgamma(x))).
[Bug c++/111840] =delete("can have a reason")?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111840
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Last reconfirmed||2023-10-17
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
We also allow:
int f2() = delete[""];
int f3() = delete{""};
int f3() = delete"";
And this compiles without error!
int f() = delete[{'a'"";
int i = f();
[Bug c++/111842] Unable to disable conversion warning in case of _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111842 Jonathan Wakely changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- But this is not a warning of the kind controlled by -Wall etc. This is a diagnostic that is *required* by the C++ standard. It's implemented in GCC as a pedwarn, which is a warning unless -pedantic-errors is used, then it's an error. So it *is* linked to a diagnostic option, as the title of PR 44209 says it should be. There is no option to disable the warning, because the code is invalid. On the other hand, we do allow disabling narrowing diagnostics, which are also required by the standard. -Wno-narrowing can be used to disable those. But narrowing cases were not errors in C++98 and the introduction of the C++11 rules caused massive compatibility problems for old code. There is no such concern for _Float16 because that type has never been used in existing C++ code. We could link this one to -Wnarrowing too, as converting to a floating-point type of lesser rank is a kind of narrowing. I don't see any great need to do that though. There's no compatability concern here, why not just write the code correctly in the first place?
[Bug c++/111842] Unable to disable conversion warning in case of _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111842 --- Comment #12 from Jonathan Wakely --- (In reply to n.deshm...@samsung.com from comment #5) > The warning is valid but I wish to suppress it like the other > conversion warning using -Wno flag. Why? Why not just write the code correctly? It's new code, not legacy code that needs to be maintained. It can't be legacy code, because it would not have compiled before GCC 13.
[Bug c++/111840] =delete("can have a reason")?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111840
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||mpolacek at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #2 from Marek Polacek ---
cp_parser_simple_declaration fails to give an error in:
/* Anything else is an error. */
else
{
/* If we have already issued an error message we don't need
to issue another one. */
if ((decl != error_mark_node
&& DECL_INITIAL (decl) != error_mark_node)
|| cp_parser_uncommitted_to_tentative_parse_p (parser))
cp_parser_error (parser, "expected %<,%> or %<;%>");
/* Skip tokens until we reach the end of the statement. */
cp_parser_skip_to_end_of_statement (parser);
/* If the next token is now a `;', consume it. */
if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON))
cp_lexer_consume_token (parser->lexer);
goto done;
[Bug libstdc++/111726] lgamma usage in std::poisson_distribution could cause a Data race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111726 --- Comment #5 from Jonathan Wakely --- I think the abs is not needed for some of the lgamma calls, as the argument is guaranteed to be non-negative. Unfortunately, that's not the case for all of them. lgamma_r, lgammaf_r and lgammal_r are present in glibc, musl, newlib, Solaris, FreeBSD, NetBSD at least. Not present in AIX or mingw-w64. Not present in darwin unless you compile with _REENTRANT, which makes it unusable for libstdc++ (we need it to be declared by unconditionally).
[Bug libstdc++/111726] lgamma usage in std::poisson_distribution could cause a Data race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111726 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > lgamma_r, lgammaf_r and lgammal_r are present in glibc, musl, newlib, > Solaris, FreeBSD, NetBSD at least. And OpenBSD has lgamma_r and lgammaf_r (but not lgammal_r).
[Bug middle-end/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand with ?: and constants and different types since r14-2667-gceae1400cf24f329393e96dd9720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 Andrew Pinski changed: What|Removed |Added Component|target |middle-end --- Comment #9 from Andrew Pinski --- The issue is inside emit_conditional_move where we are trying to use the same register for constants which are of 2 different types (modes).
