[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #7 from rdapp at linux dot ibm.com --- This diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc index 8cc173519ab..e9ea90631a2 100644 --- a/gcc/config/arc/arc.cc +++ b/gcc/config/arc/arc.cc @@ -2254,6 +2254,8 @@ gen_compare_reg (rtx comparison, machine_mode omode) cmode = GET_MODE (x); + if (GET_MODE_CLASS (cmode) == MODE_CC) +return comparison; if (cmode == VOIDmode) cmode = GET_MODE (y); gcc_assert (cmode == SImode || cmode == SFmode || cmode == DFmode); should be better and fixes the test case for me. Btw Segher is very much not in favor of this approach/patch and argues that reusing the comparison is the wrong thing to do as a "cc comparison" is not a comparison but rather the result of a comparison (PR104335).
[Bug target/104525] New: timeout on signed overflow at O0 fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525
Bug ID: 104525
Summary: timeout on signed overflow at O0 fwrapv
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
When checking the case in PR104521, a timeout occurs on the case at ppc64le.
The timeout also occurs with -O0 -fwrapv (without -fwrapv, the signed overflow
which would be a UB). This issue seems to exist for a long time (gcc6).
> cat small.c
char a, b, c;
int main() {
unsigned char d = 1;
while (1) {
if (c >= a) {
for (c = 0; c != -4; c -= 3) {
while (!d)
b = 0;
continue;
}
}
d = ~a;
if (!d)
continue;
return 0;
}
}
> gcc -fwrapv -O0 small.c ; timeout -s 9 5 ./a.out
Killed
[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d commit r12-7222-g3f10e0d50b5e3b3f64bc9a1a29177518d5f4468d Author: Richard Biener Date: Fri Feb 11 11:08:57 2022 +0100 middle-end/104497 - gimplification of vector indexing The following attempts to address gimplification of ... = VIEW_CONVERT_EXPR((i & 1) != 0 ? inv : src)[i]; which is problematic since gimplifying the base object ? inv : src produces a register temporary but GIMPLE does not really support a register as a base for an ARRAY_REF (even though that's not strictly validated it seems as can be seen at -O0). Interestingly the C++ frontend avoids this issue by emitting the following GENERIC instead: ... = (i & 1) != 0 ? VIEW_CONVERT_EXPR(inv)[i] : VIEW_CONVERT_EXPR(src)[i]; The proposed patch below fixes things up when using an rvalue as the base is OK by emitting a copy from a register base to a non-register one. The ?: as lvalue extension seems to be gone for C, C++ again unwraps the COND_EXPR in that case. 2022-02-11 Richard Biener PR middle-end/104497 * gimplify.cc (gimplify_compound_lval): Make sure the base is a non-register if needed and possible. * c-c++-common/torture/pr104497.c: New testcase.
[Bug c++/104503] [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104503 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c/104505] ICE: SIGSEGV in c_pretty_printer::postfix_expression() on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104505 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug target/104525] timeout on signed overflow at O0 fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525 --- Comment #1 from Jiu Fu Guo --- with "-fsigned-char", the case run ok. When 'char' is treated as 'unsigned': "c != -4" would not be true is any value of 'c'. So, this PR would be invalid.
[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104506 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/104525] timeout on signed overflow at O0 fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Yes on PowerPC (and ARM and aarch64), plain char is unsigned by default.
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/104497] [11 Regression] Invalid gimple produced for (A?vect:vect)[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497 Richard Biener changed: What|Removed |Added Summary|[11/12 Regression] Invalid |[11 Regression] Invalid |gimple produced for |gimple produced for |(A?vect:vect)[i]|(A?vect:vect)[i] Known to work||12.0 --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug target/104511] [10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with __builtin_convertvector() at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104511
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-02-14
Target Milestone|--- |10.4
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
vector lowering produces
_5 = BIT_FIELD_REF ;
_6 = (_Decimal32) _5;
_7 = BIT_FIELD_REF ;
_8 = (_Decimal32) _7;
_9 = BIT_FIELD_REF ;
_10 = (_Decimal32) _9;
_11 = BIT_FIELD_REF ;
_12 = (_Decimal32) _11;
d_2 = {_6, _8, _10, _12};
where the BIT_FIELD_REFs extract _Float64. Then forwprop matches the
CTOR as VEC_PACK_TRUNC_EXPR from vector(2) _Float64 to vetor(4) _Decimal32.
_13 = BIT_FIELD_REF ;
_14 = BIT_FIELD_REF ;
d_2 = VEC_PACK_TRUNC_EXPR <_13, _14>;
I'm not sure if decimal FP vectors are a thing on powerpc64le and what their
ABI are. Maybe the testcase should be rejected.
Clearly the forwprop code is wrong here, since the vec_pack_trunc optab
has just a single mode there's no way to convert between DFP and FP.
I'll fix that, not sure if that will fix everything.
[Bug target/104489] nvptx, sm_53: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104489 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to Roger Sayle from comment #3) > Patch proposed: > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html which is the machine-independent part. The associated nvptx patch (also by Roger) is at https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590250.html
[Bug tree-optimization/104515] [11/12 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104515
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-02-14
Ever confirmed|0 |1
Priority|P3 |P2
Component|rtl-optimization|tree-optimization
Summary|trivially-destructible |[11/12 Regression]
|destructors interfere with |trivially-destructible
|loop optimization - maybe |destructors interfere with
|related to lifetime-dse.|loop optimization - maybe
||related to lifetime-dse.
CC||jakub at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |11.3
--- Comment #1 from Richard Biener ---
Confirmed. The issue is that store motion of v_7(D)->end cannot be performed
on
[local count: 955630225]:
# i_13 = PHI
_1 = v_7(D)->end;
_2 = _1 + 18446744073709551612;
v_7(D)->end = _2;
MEM[(T *)_1 + -4B] ={v} {CLOBBER}; // <- inserted by -flifetime-dse
i_10 = i_13 + 1;
if (n_6(D) > i_10)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510901]:
goto ; [100.00%]
With GCC 10 we didn't have this particular CLOBBER and at least in GCC 10 the
first testcase was properly optimized.
Note there's a dependence on the value of v_7(D)->end for the clobber so
the clobber itself cannot be moved out of the loop. So the only option
here would be to drop it if it enables store-motion.
We remove all *ssaname_N ={v} {CLOBBER} stmts during the fold-all-builtins
pass but that's very late, in particular _after_ the last CDDCE. I suspect
that instead of
NEXT_PASS (pass_dse);
NEXT_PASS (pass_cd_dce, true /* update_address_taken_p */);
/* After late CD DCE we rewrite no longer addressed locals into SSA
form if possible. */
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_phiopt, false /* early_p */);
NEXT_PASS (pass_fold_builtins);
we might consider doing FAB (or the CLOBBER removal part) after the last
DSE (or simply direct that last DSE pass do that, with some pass specific
flag). Note that's still too late since we need store-motion here.
Doing the *ssaname_N ={v} {CLOBBER} clobber removal after the _first_
DSE after IPA inlining would be another option. Likewise of course
removing it as part of SM as said above.
I can see how easy it is to do from store-motion.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- I will have a look.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
So the issue is that native_interpret_real produces something that's not
printable. For MODE_COMPOSITE_P types we have code that verifies
back-and-forth
conversion - when we enable that we get until RTL which happens to generate
(insn # 0 0 2 (set (reg:XF 8 st)
(mem/u/c:XF (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [ S16 A128]))
"t.c":9:6# {*movxf_internal}
(expr_list:REG_EQUIV (const_double:XF
with "invalid" XFmode real again. Here DSE1 does
(note 3 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
-(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
-(insn 5 2 6 2 (set (reg:V8HI 51 xmm15)
-(mem/u/c:V8HI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]))
"t.c":8:15 1694 {movv8hi_internal}
- (expr_list:REG_EQUAL (const_vector:V8HI [
-(const_int 512 [0x200])
-(const_int 0 [0]) repeated x3
-(const_int 16384 [0x4000])
-(const_int 0 [0]) repeated x3
-])
-(nil)))
-(insn 6 5 7 2 (set (mem/c:V8HI (plus:DI (reg/f:DI 19 frame)
-(const_int -16 [0xfff0])) [2 S16 A128])
-(reg:V8HI 51 xmm15)) "t.c":8:15 1694 {movv8hi_internal}
- (expr_list:REG_DEAD (reg:V8HI 51 xmm15)
-(nil)))
-(insn 7 6 8 2 (set (reg:XF 86 [ t1 ])
-(mem/c:XF (symbol_ref:DI ("t1") [flags 0x2] ) [1 t1+0 S16 A128])) "t.c":9:6 140 {*movxf_internal}
- (nil))
to
+(note 2 3 13 2 NOTE_INSN_FUNCTION_BEG)
+(insn 13 2 7 2 (set (reg:XF 88)
+(mem/u/c:XF (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S16 A128]))
"t.c":8:15 140 {*movxf_internal}
+ (expr_list:REG_EQUAL (const_double:XF
so the issue needs to be mitigated in multiple places. Even if we sanitize
the FP value we'd need to fix the DSE side which invokes
native_decode_rtx which seems to also lack the COMPOSITE_MODE handling.
But I do wonder whether real_from_target needs fixing to handle invalid
input gracefully which is ultimatively decode_ieee_extended?
Any opinions here?
[Bug tree-optimization/104526] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526
Bug ID: 104526
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs. 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c #138750
void foo(void);
static int a, b = 1, *c = &b;
int main() {
for (; a; a--) {
int d = 2 >> (1 / *c);
if (!d)
foo();
}
}
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 can not eliminate foo
but gcc-11.2.0 -O3 can.
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 -S -o /dev/stdout
case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movla(%rip), %eax
testl %eax, %eax
je .L12
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
xorl%ebx, %ebx
.L2:
movlb(%rip), %ecx
leal1(%rcx), %eax
cmpl$2, %eax
movl$2, %eax
cmova %ebx, %ecx
sarl%cl, %eax
testl %eax, %eax
je .L3
movl$0, a(%rip)
.L10:
xorl%eax, %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L3:
.cfi_restore_state
callfoo
subl$1, a(%rip)
jne .L2
jmp .L10
.L12:
.cfi_def_cfa_offset 8
.cfi_restore 3
xorl%eax, %eax
ret
-- END OUTPUT -
gcc-11.2.0 -O3 -S -o /dev/stdout case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movla(%rip), %eax
testl %eax, %eax
je .L2
movl$0, a(%rip)
.L2:
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
- Build information -
- 58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk)
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220213 (experimental) (GCC)
- releases/gcc-11.2.0
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
[Bug analyzer/104524] [12 Regression] ICE in get_or_create_cast, at analyzer/region-model-manager.cc:499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104524 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0
[Bug c++/104527] New: [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527
Bug ID: 104527
Summary: [11/12 Regression] ICE: tree check: accessed elt 1 of
'tree_vec' with 0 elts in hash, at
cp/constraint.cc:2486
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: ppalka at gcc dot gnu.org
Target Milestone: ---
gcc 12.0.1 20220213 snapshot (g:58aeb75d4097010ad9bb72b964265b18ab284f93) ICEs
when compiling the following testcase, reduced from
test/SemaTemplate/instantiate-requires-expr.cpp from the clang 13.0.0 test
suite, w/ -std=c++20 (or -fconcepts):
template
constexpr bool is_same_v = false;
namespace expr_requirement {
template
concept C1 = is_same_v;
template
struct b {
template
requires (requires { { 0 } -> C1; }, false)
struct r {};
};
using bri = b::r;
}
% g++-12.0.1 -fconcepts -c s6aywpah.cpp
s6aywpah.cpp: In substitution of 'template template requires
(requires{{0} -> decltype(auto) [requires expr_requirement::C1<,
typename T::a>];}, false) struct expr_requirement::b::r [with U = short int;
T = int]':
s6aywpah.cpp:15:30: required from here
s6aywpah.cpp:11:32: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
11 | requires (requires { { 0 } -> C1; }, false)
| ~~^~~~
0x8768fa tree_vec_elt_check_failed(int, int, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree.cc:8889
0x9a55e3 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree.h:3666
0x9a55e3 sat_hasher::hash(sat_entry*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2486
0x9a13a3 hash_table::find_slot(sat_entry*
const&, insert_option)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/hash-table.h:435
0x9a13a3 satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2580
0x9a442e satisfy_atom
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2897
0x9a442e satisfy_constraint_r
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:3006
0x9a4d14 satisfy_normalized_constraints
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:3031
0x9a2bc8 satisfy_nondeclaration_constraints
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:3113
0x9a2bc8 constraint_satisfaction_value
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:3268
0x9a4dd4 constraints_satisfied_p(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:3300
0xb20299 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/pt.cc:30234
0x9a3610 type_deducible_p
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2010
0x9a3610 tsubst_compound_requirement
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2075
0x9a3610 tsubst_requirement
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2155
0x9a3610 tsubst_requires_expr
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2278
0x9a4d7b tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/constraint.cc:2297
0xb27141 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/pt.cc:21288
0xb3e921 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/pt.cc:19413
0xb3fc67 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/cp/pt.cc:19391
[Bug c/104505] ICE: SIGSEGV in c_pretty_printer::postfix_expression() on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104505 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f7e26913187ce0ed35e340c4fd14104bbcd1932e commit r12-7223-gf7e26913187ce0ed35e340c4fd14104bbcd1932e Author: Richard Biener Date: Mon Feb 14 09:29:20 2022 +0100 c/104505 - ICE with internal function call in diagnostic expression The following handles internal function calls similar to how the C++ frontend does, avoiding ICEing on those. 2022-02-14 Richard Biener PR c/104505 gcc/c-family/ * c-pretty-print.cc (c_pretty_printer::postfix_expression): Handle internal function calls. gcc/testsuite/ * c-c++-common/pr104505.c: New testcase.
[Bug target/104511] [10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with __builtin_convertvector() at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104511
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f320197c8b495324dc6997a99d53e7f45ecf5840
commit r12-7224-gf320197c8b495324dc6997a99d53e7f45ecf5840
Author: Richard Biener
Date: Mon Feb 14 10:09:10 2022 +0100
tree-optimization/104511 - avoid FP to DFP conversion for VEC_PACK_TRUNC
This avoids forwprop from matching DFP <-> FP vector conversions
using VEC_[UN]PACK{_TRUNC,_LO,_HI}. Maybe DFP vectors shouldn't be
a thing, but they appearantly are. Re-using CONVERT/NOP_EXPR for
DFP <-> FP conversions was probably a mistake.
2022-02-14 Richard Biener
PR tree-optimization/104511
* tree-ssa-forwprop.cc (simplify_vector_constructor): Avoid
touching DFP <-> FP conversions.
* gcc.dg/pr104511.c: New testcase.
[Bug target/104511] [10/11 Regression] ICE: in emit_move_insn, at expr.cc:4010 with __builtin_convertvector() at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104511 Richard Biener changed: What|Removed |Added Known to work||12.0 Priority|P3 |P2 Summary|[10/11/12 Regression] ICE: |[10/11 Regression] ICE: in |in emit_move_insn, at |emit_move_insn, at |expr.cc:4010 with |expr.cc:4010 with |__builtin_convertvector() |__builtin_convertvector() |at -O |at -O
[Bug c/104505] ICE: SIGSEGV in c_pretty_printer::postfix_expression() on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104505 Richard Biener changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed but generally latent.
[Bug target/104525] timeout on signed overflow at O0 fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- And on -fsigned-char targets, -fwrapv isn't needed, there isn't signed integer overflow, because c -= 3 promotes to int, so it is actually c = (signed char) ((int) c - 3)
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #5 from Uroš Bizjak ---
(In reply to Richard Biener from comment #4)
> But I do wonder whether real_from_target needs fixing to handle invalid
> input gracefully which is ultimatively decode_ieee_extended?
long double foo (void)
{
union { int i[4]; long double ld; } __tmp
= { .i = { 0x1, 0, 0x4000, 0 } };
return __tmp.ld;
}
This will fail compilation (-O -dP), without -dP (which avoids printing), the
constant in the memory is wrong:
.LC0:
.long 1
.long 0
.long 0 <--- here should be 16384
.long 0
[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104506 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||sayle at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Confirmed it is r12-3278-g823685221de98
[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Yeah, I confirm it doesn't ICE starting with r12-4769-g9927ecbb42d5be48fa933adc26f8601fab5007ca and ICE started with r11-1449-gae2ebf011fec926e003645c33c07a03619ea216a which has been backported to 10 in r10-8315-g1bab254fd30c2b94a675b9057349fc80946375b1
[Bug tree-optimization/104528] New: [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Bug ID: 104528 Summary: [12 Regression] ICE: Segmentation fault (in gimple_bb) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Created attachment 52435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52435&action=edit Testcase gfortran 12.0.1 20220213 snapshot (g:58aeb75d4097010ad9bb72b964265b18ab284f93) ICEs when compiling the attached testcase w/ -O2 -fpeel-loops -ftree-loop-vectorize -fno-tree-scev-cprop --param iv-max-considered-uses=2: % gfortran-12.0.1 -O2 -fpeel-loops -ftree-loop-vectorize -fno-tree-scev-cprop --param iv-max-considered-uses=2 -c atm8wqik.f during GIMPLE pass: ivopts atm8wqik.f:1:37: 1 | REAL FUNCTION FOO(M, N, A, W) | ^ internal compiler error: Segmentation fault 0xf5175f crash_signal /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/toplev.cc:322 0x1e3964d gimple_bb /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/gimple.h:1871 0x1e3964d loop_containing_stmt /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-ssa-loop.h:76 0x1e3964d chrec_contains_symbols_defined_in_loop /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1009 0x1e39714 chrec_contains_symbols_defined_in_loop /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1026 0x1e397f4 chrec_contains_symbols_defined_in_loop(tree_node const*, unsigned int) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1039 0x10390e9 compute_overall_effect_of_inner_loop(loop*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:473 0x103963e follow_ssa_edge_inner_loop_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1114 0x103963e follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1183 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #6 from Richard Biener ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Richard Biener from comment #4)
> > But I do wonder whether real_from_target needs fixing to handle invalid
> > input gracefully which is ultimatively decode_ieee_extended?
>
> long double foo (void)
> {
> union { int i[4]; long double ld; } __tmp
> = { .i = { 0x1, 0, 0x4000, 0 } };
> return __tmp.ld;
> }
>
> This will fail compilation (-O -dP), without -dP (which avoids printing),
> the constant in the memory is wrong:
>
> .LC0:
> .long 1
> .long 0
> .long 0 <--- here should be 16384
> .long 0
That's because encode_ieee_extended detects this (.uexp == 2) as denormal
and does
case rvc_normal:
{
int exp = REAL_EXP (r);
/* Recall that IEEE numbers are interpreted as 1.F x 2**exp,
whereas the intermediate representation is 0.F x 2**exp.
Which means we're off by one.
Except for Motorola, which consider exp=0 and explicit
integer bit set to continue to be normalized. In theory
this discrepancy has been taken care of by the difference
in fmt->emin in round_for_format. */
if (denormal)
exp = 0;
we do call round_for_format in advance but that does nothing here.
One question would be if native_interpret_real needs to call round_for_format
as well if that's the entity that's supposed to fixup "invalid" FP
encodings.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3
[Bug c++/104514] add feature to create a pointer to a fixed address as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104514 --- Comment #4 from Jonathan Wakely --- Yes, but this one asks for a new feature, not just "please make this kluge work again".
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-02-14 --- Comment #1 from Richard Biener --- Usually a sign of using a stale SCEV cache entry.
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 --- Comment #2 from Richard Biener --- At the start of IVOPTs we have (gdb) p debug_tree (cfun->x_current_loops->larray->m_vecdata[4]->nb_iterations) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7670ce70 precision:32 min max > arg:0 nothrow def_stmt version:36 in-free-list> arg:1 arg:0 visited def_stmt pretmp_90 = ii; version:90>>> $12 = void so that mentions a released SSA name. It's released during DSE which fails to reset niter info since we now prune dead SSA names there.
[Bug debug/104517] '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104517 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-02-14 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Created attachment 52436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52436&action=edit gcc12-pr104517.patch Untested fix.
[Bug libstdc++/103891] clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:164a761a9f4798dc69ecab80097807636dc17d61 commit r12-7227-g164a761a9f4798dc69ecab80097807636dc17d61 Author: Jonathan Wakely Date: Mon Feb 14 12:46:10 2022 + libstdc++: Use __cpp_concepts instead of custom macro [PR103891] With the new value of __cpp_concepts required by P2493, we can test whether the compiler supports conditionally trivial special members. This allows us to remove the workaround that disables fully-constexpr std::variant for Clang. Now it should work for non-GCC compilers (such as future releases of Clang) that support conditionally trivial destructors and define the new value of __cpp_concepts. libstdc++-v3/ChangeLog: PR libstdc++/103891 * include/bits/c++config (_GLIBCXX_HAVE_COND_TRIVIAL_SPECIAL_MEMBERS): Remove. * include/std/variant: Check feature test macros instead. * include/std/version: Likewise.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #7 from Jakub Jelinek ---
The MODE_COMPOSITE_P handling can be surely enabled for other modes too, I have
guarded it just because it slows compile time down a little bit and for usual
IEEE754 modes it should be always true, shouldn't it?
If i386/m68k XFmode is a problem too, we'd need some predicate how to find out
it is also problematic (the problem is the unnormals and other weird
representations in it, basically that not all bit patterns are valid).
native_decode_rtx has the same MODE_COMPOSITE_P handling:
rtx ret = native_decode_rtx (outermode, buffer, 0);
if (ret && MODE_COMPOSITE_P (outermode))
{
auto_vec buffer2 (buffer_bytes);
if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
return NULL_RTX;
for (unsigned int i = 0; i < buffer_bytes; ++i)
if (buffer[i] != buffer2[i])
return NULL_RTX;
}
so again, it could be enabled for all scalar floating modes or composite and
the XF-ish modes.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
Hmm, for
b.2_2 = (unsigned char) b_lsm.6_13;
_3 = b.2_2 + 3;
_4 = (char) _3;
we analyze the evolution of _4 to {-4, +, 3}_1 (we're using an existing
upper bound for niter of 2). Eventually the bound we derive for this exit
causes us to disregard the other exit.
That upper bound of niter is from the main loop exit test at CD-DCE time.
Specifically multiple_of_p computes 249 % 3 is 0 and 0 % 3 is 0. It passes
wrong 'type', which doesn't end up mattering because the code seems
to look for mismatched type & type top/bottom(!?)
case INTEGER_CST:
if (TREE_CODE (bottom) != INTEGER_CST
|| integer_zerop (bottom)
|| (TYPE_UNSIGNED (type)
&& (tree_int_cst_sgn (top) < 0
|| tree_int_cst_sgn (bottom) < 0)))
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
but then, we do
if (!niter->control.no_overflow
&& (integer_onep (s)
|| (multiple_of_p (niter_type, fold_convert (niter_type, iv->base),
s,
false)
&& multiple_of_p (niter_type, fold_convert (niter_type, final),
s,
false
so look for the multiple in unsigned arithmetic but then assume overflow
does not happen in signed arithmetic. That means the changes to
number_of_iterations_ne were wrong. Note the simplistic fix for
PR100499 regressed some testcases.
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..cdf34d81d90 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14211,8 +14211,8 @@ multiple_of_p (tree type, const_tree top, const_tree
bottom, bool nowrap)
if (TREE_CODE (bottom) != INTEGER_CST
|| integer_zerop (bottom)
|| (TYPE_UNSIGNED (type)
- && (tree_int_cst_sgn (top) < 0
- || tree_int_cst_sgn (bottom) < 0)))
+ && (tree_int_cst_sign_bit (top)
+ || tree_int_cst_sign_bit (bottom
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..b8a628ea829 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -1051,9 +1051,9 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
+ || (multiple_of_p (niter_type, fold_convert (niter_type, iv->base),
s,
false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
+ && multiple_of_p (niter_type, fold_convert (niter_type, final),
s,
false
{
tree t, cond, relaxed_cond = boolean_false_node;
fixes this PR but I need to understand what multiple_of_p is doing here ...
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0a1a3afb5fb36e2d10ad92bf788e16d837451571 commit r12-7228-g0a1a3afb5fb36e2d10ad92bf788e16d837451571 Author: Richard Biener Date: Mon Feb 14 13:37:54 2022 +0100 tree-optimization/104528 - free niter estimates after DSE When DSE removes a trivially dead def we have to reset niter information on loops since that might refer to it. The patch also adds verification to make sure this does not happen. 2022-02-14 Richard Biener PR tree-optimization/104528 * tree-ssa.h (find_released_ssa_name): Declare. * tree-ssa.cc (find_released_ssa_name): Export. * cfgloop.cc (verify_loop_structure): Look for released SSA names in loops nb_iterations. * tree-ssa-dse.cc (pass_dse::execute): Release number of iteration estimates. * gfortran.dg/pr104528.f: New testcase.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r12-6924-gc2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #8 from Martin Jambor ---
I am about to thest the following patch. In longer-run, it would be better to
never generate lattice values outside of the value_range but there is an
ordering problem, we need the complete VR info before we can use it. I plan to
rearrange IPA-CP into making multiple passes over the lattice dependency graph
and this should quite naturally be solved by doing this kind of
resursive-value-generation only in second and later passes.
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 453e9c93cc3..cbbb8bbc80a 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -6154,8 +6154,16 @@ decide_whether_version_node (struct cgraph_node *node)
{
ipcp_value *val;
for (val = lat->values; val; val = val->next)
- ret |= decide_about_value (node, i, -1, val, &avals,
- &self_gen_clones);
+ {
+ if (!plats->m_value_range.bottom_p ()
+ && !plats->m_value_range.m_vr.contains_p (val->value))
+ {
+ gcc_checking_assert (val->self_recursion_generated_p ());
+ continue;
+ }
+ ret |= decide_about_value (node, i, -1, val, &avals,
+&self_gen_clones);
+ }
}
if (!plats->aggs_bottom)
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 --- Comment #8 from Richard Biener --- So my question is whether something should normalize those numbers and why decode_ieee_extended happily initializes an invalid number (its documentation of course might suggest it only expects valid encoded numbers). But yes, enabling this re-interpretation checking unconditionally sounds like the way to go.
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
Priority|P3 |P1
Last reconfirmed||2022-02-14
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Jakub Jelinek ---
Seems like something EVRP should optimize.
The pre- r12-6924 IL was:
c.0_1 = c;
_2 = *c.0_1;
# RANGE [-1, 1]
_3 = 1 / _2;
# RANGE [1, 2] NONZERO 3
d_11 = 2 >> _3;
and evrp properly figured out those ranges, that 1 / int is [-1, 1] and
that 2 >> [-1, 1] is [1, 2].
But since r12-6924 the IL is:
c.0_1 = c;
_2 = *c.0_1;
_11 = (unsigned int) _2;
_12 = _11 + 1;
_13 = _12 <= 2;
_3 = _12 <= 2 ? _2 : 0;
# RANGE [0, 2] NONZERO 3
d_14 = 2 >> _3;
and the range for d_14 is too broad (includes 0) and no ranges are recorded for
the other SSA_NAMEs.
Now, __1 and _12 are of course VARYING, and because _13 is _Bool, it is also
VARYING.
The important missing part is that we don't realize that _12 <= 2 ? _2 : 0
implies [-1, 1] range. The _2 + 1U <= 2U is a standard pattern how ranges are
encoded. Now if I rewrite the testcase by hand to:
void foo(void);
static int a, b = 1, *c = &b;
int main() {
for (; a; a--) {
int e;
int ct = *c;
if (ct + 1U <= 2U)
e = ct;
else
e = 0;
int d = 2 >> e;
if (!d)
foo();
}
}
which is equivalent to doing the 1 / int PR95424 optimization by hand, but
instead of having it in a COND_EXPR do it in separate bbs, i.e.:
c.0_1 = c;
ct_12 = *c.0_1;
ct.1_2 = (unsigned int) ct_12;
_3 = ct.1_2 + 1;
if (_3 <= 2)
goto ; [INV]
else
goto ; [INV]
:
:
# RANGE [-1, 1]
# e_7 = PHI
# RANGE [1, 2] NONZERO 3
d_15 = 2 >> e_7;
then evrp handles it just fine.
So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, so
that it essentially does what we do for the PHI cases? I.e. from the COND_EXPR
condition, compute "assertion" if condition is true or if condition is false,
and use that on the COND_EXPR's second and third argument.
So for the
_3 = _12 <= 2 ? _2 : 0;
comparison, for second argument the condition must be true which implies that
_2 must be there [-1, 1], while for the third argument the condition must be
false, but the argument is constant 0, so range is [0, 0], then just union
those 2 ranges.
As this is a P1 regression, if we can fix it, would be nice to get it into GCC
12.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
--- Comment #6 from Richard Biener ---
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..9d9939642f6 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14208,11 +14208,7 @@ multiple_of_p (tree type, const_tree top, const_tree
bo
ttom, bool nowrap)
&& multiple_of_p (type, TREE_OPERAND (top, 2), bottom, nowrap));
case INTEGER_CST:
- if (TREE_CODE (bottom) != INTEGER_CST
- || integer_zerop (bottom)
- || (TYPE_UNSIGNED (type)
- && (tree_int_cst_sgn (top) < 0
- || tree_int_cst_sgn (bottom) < 0)))
+ if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
of course makes most sense there. I'm evaluating what
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..2305e1d53f6 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -986,6 +986,7 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
bool exit_must_be_taken, bounds *bnds)
{
tree niter_type = unsigned_type_for (type);
+ tree stype = signed_type_for (niter_type);
tree s, c, d, bits, assumption, tmp, bound;
mpz_t max;
@@ -1051,10 +1052,8 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
- false
+ || multiple_of_p (stype, fold_convert (stype, c),
+ fold_convert (stype, iv->step
{
tree t, cond, relaxed_cond = boolean_false_node;
will yield since we are interpreting iv->step as signed. Pointers are
what makes this all a bit awkward since for those iv->base is a pointer
but iv->step is (unsigned) sizetype to be interpreted as signed.
Anyway, I do appreciate the extended test coverage we are getting from
the auto-generation of valid code people!
[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103790 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:680ee9c333280df74e06e1bc9f3be218424f94b3 commit r11-9567-g680ee9c333280df74e06e1bc9f3be218424f94b3 Author: Andre Vehreschild Date: Mon Feb 14 16:12:14 2022 +0100 Prevent malicious descriptor stacking for scalar components [V2, backport]. gcc/fortran/ChangeLog: PR fortran/103790 Backported from master. * trans-array.c (structure_alloc_comps): Prevent descriptor stacking for non-array data; do not broadcast caf-tokens. * trans-intrinsic.c (conv_co_collective): Prevent generation of unused descriptor. gcc/testsuite/ChangeLog: PR fortran/103790 * gfortran.dg/coarray_collectives_18.f90: New test.
[Bug fortran/103970] Multi-image co_broadcast of derived type with allocatable components fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103970 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andre Vehreschild --- Review was ok'ed and patch committed more than two weeks ago. Backport to gcc-11 committed as 680ee9c3332.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
--- Comment #7 from Richard Biener ---
Btw, to me it seems that since we are resolving condition 1) statically we know
that the difference of iv->base and final is positive with infinite
precision and fits the unsigned niter_type. To avoid going to the unsigned
type we can then indeed check multiple_of_p on each component, but we need
to use the original signedness here (or rather always signed?).
Using unsigned arithmetic for the
niter->niter = fold_build2 (EXACT_DIV_EXPR, niter_type, c, s);
in the end is consistent with the conditions we checked. So to preserve the
gist of Bins change I included it should probably read
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..3ddc3a5c3a6 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -986,6 +986,7 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
bool exit_must_be_taken, bounds *bnds)
{
tree niter_type = unsigned_type_for (type);
+ tree stype = signed_type_for (niter_type);
tree s, c, d, bits, assumption, tmp, bound;
mpz_t max;
@@ -1051,10 +1052,10 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
- false
+ || (multiple_of_p (stype, fold_convert (stype, iv->base),
+fold_convert (stype, iv->step))
+ && multiple_of_p (stype, fold_convert (stype, final),
+ fold_convert (stype, iv->step)
{
tree t, cond, relaxed_cond = boolean_false_node;
[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment #5 from Tamar Christina ---
(In reply to Marc Glisse from comment #4)
> I don't believe there is a "new/delete" issue.
I wonder.. , looking at
#include
#include
#include
struct param {
uint32_t k;
std::vector src;
std::vector ref0;
};
size_t foo() {
param test[] = {
{48, {255, 0, 0, 0, 0, 0}
}};
return sizeof(test);
}
I had expected the answer to simply be
mov w0, #56
ret
since the new and delete can be elided.
...but GCC generates some pretty bad code here...
https://godbolt.org/z/EPoYYohPa
In this case nothing of the structure is used at all yet we keep all the
construction code.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 --- Comment #9 from Jakub Jelinek --- Created attachment 52437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52437&action=edit gcc12-pr104522.patch Patch I'll test tonight.
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:ae57aae60d1be821feccb3160f8fdd5987ecba79 commit r11-9568-gae57aae60d1be821feccb3160f8fdd5987ecba79 Author: Andre Vehreschild Date: Mon Feb 14 16:47:16 2022 +0100 fortran: Fix deref of optional in gen. code. [PR100337, backport] gcc/fortran/ChangeLog: PR fortran/100337 Backport from master. * trans-intrinsic.c (conv_co_collective): Check stat for null ptr before dereferrencing. gcc/testsuite/ChangeLog: PR fortran/100337 * gfortran.dg/coarray_collectives_17.f90: New test.
[Bug target/104529] New: [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Bug ID: 104529
Summary: [missed optimization] inefficient codegen around
new/delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*
Consider the following example
#include
#include
#include
struct param {
uint32_t k;
std::vector src;
std::vector ref0;
};
size_t foo() {
param test[] = {
{48, {255, 0, 0, 0, 0, 0}
}};
return sizeof(test);
}
where the entire thing should have been elided, but that is already reported in
#94294.
Instead this code also shows that we are generating quite inefficient code
(even at -Ofast)
on AArch64 we generate:
foo():
stp x29, x30, [sp, -32]!
mov w1, 255 <-- 1
mov x0, 6
mov x29, sp
str w1, [sp, 24] <-- 1
strhwzr, [sp, 28] <-- 2
bl operator new(unsigned long)
ldrhw3, [sp, 28] <-- 2
mov x1, 6
ldr w4, [sp, 24] <-- 1
str w4, [x0]
strhw3, [x0, 4]
bl operator delete(void*, unsigned long)
mov x0, 56
ldp x29, x30, [sp], 32
ret
There's no reason to spill and rematerialize a constant when the constant is
representable in a single move.
It's also unclear to me why it things the 255 and 0 need to be before the call
to new. But even if it did need it, it's better to re-create the constants
rather than materializing them again.
However x86 gets this right, which is why I've opened this as a target bug:
foo():
sub rsp, 8
mov edi, 6
calloperator new(unsigned long)
mov esi, 6
mov DWORD PTR [rax], 255
mov rdi, rax
xor eax, eax
mov WORD PTR [rdi+4], ax
calloperator delete(void*, unsigned long)
mov eax, 56
add rsp, 8
ret
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andre Vehreschild --- Backported to gcc-11. Closing as fixed now.
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:02a981a8e512934a990d1427d14e8e884409fade commit r12-7230-g02a981a8e512934a990d1427d14e8e884409fade Author: Jakub Jelinek Date: Mon Feb 14 16:56:15 2022 +0100 c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513] return in ctors on targetm.cxx.cdtor_returns_this () target like arm is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits RETURN_EXPR with the this. Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this () a return is emitted similarly. potential_constant_expression_1 was rejecting these gotos and so we incorrectly rejected these testcases, but actual cxx_eval* is apparently handling these just fine. I was a little bit worried that for the destruction of bases we wouldn't evaluate something we should, but as the testcase shows, that is evaluated through try ... finally and there is nothing after the cdtor_label. For arm there is RETURN_EXPR this; but we don't really care about the return value from ctors and dtors during the constexpr evaluation. I must say I don't see much the point of cdtor_labels at all, I'd think that with try ... finally around it for non-arm we could just RETURN_EXPR instead of the GOTO_EXPR and the try/finally gimplification would DTRT, and we could just add the right return value for the arm case. 2022-02-14 Jakub Jelinek PR c++/104513 * constexpr.cc (potential_constant_expression_1) : Don't punt if returns (target). * g++.dg/cpp1y/constexpr-104513.C: New test. * g++.dg/cpp2a/constexpr-dtor12.C: New test.
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- If we just want to avoid the warning in cases like that (there is nothing wrong in the testcases themselves, the warning just warns about an implementation detail that a normally uninitialized variable will be really uninitialized even despite the -ftrivial-auto-var-init= option), then maybe_warn_switch_unreachable already has: if (gimple_code (stmt) == GIMPLE_GOTO && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) /* Don't warn for compiler-generated gotos. These occur in Duff's devices, for example. */; and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also avoid warnings on: 1) call to .DEFERRED_INIT 2) call to __builtin_clear_padding if the second argument is present and non-zero 3) I guess we would need not to warn on a gimple assign store right after the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs anything else?
[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423 --- Comment #5 from Tom de Vries --- Created attachment 52438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52438&action=edit Tentative patch (GOMP_TARGET_ENV_ITER) A more generic solution using env var GOMP_TARGET_ENV_ITER, which allows us to specify: GOMP_TARGET_ENV_ITER="GOMP_NVPTX_JIT _ -O0".
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-14 --- Comment #1 from Jakub Jelinek --- ICEs since r11-7454-ge52f8ec25c0e58ebd083e8370e2fbc8af4120d87
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r5-4736-g1e51d0a29dbfebe6c0df58739562644c1a50f3c3
[Bug tree-optimization/104530] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530
Bug ID: 104530
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs. 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
Dead Code Elimination Regression at -O3 (trunk vs.
a7fede6704dd207fb32b97bc30f945acc7b953c5) 138751
---
cat case.c #138751
void foo(void);
static int a, *b = &a, c, d = 1;
int main() {
c = 0 == b;
a = *b;
if (c % d)
for (; d; --d)
foo();
b = 0;
}
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 can not eliminate foo
but gcc-11.2.0 -O3 can.
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 -S -o /dev/stdout
case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
testq %rax, %rax
movl(%rax), %edx
sete%al
movzbl %al, %eax
movl%edx, a(%rip)
cltd
idivl d(%rip)
testl %edx, %edx
je .L9
pushq %rax
.cfi_def_cfa_offset 16
.p2align 4,,10
.p2align 3
.L3:
callfoo
subl$1, d(%rip)
jne .L3
xorl%ecx, %ecx
xorl%eax, %eax
movq%rcx, b(%rip)
popq%rsi
.cfi_def_cfa_offset 8
ret
.L9:
xorl%edx, %edx
xorl%eax, %eax
movq%rdx, b(%rip)
ret
-- END OUTPUT -
gcc-11.2.0 -O3 -S -o /dev/stdout case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
movq$0, b(%rip)
movl(%rax), %eax
movl%eax, a(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c6bb1db76b3ac127aff7dacf391fc1798a94bb7d
- Build information -
- 58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk)
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/compiler_cache/gcc-58aeb75d4097010ad9bb72b964265b18ab284f93
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220213 (experimental) (GCC)
- releases/gcc-11.2.0
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 (GCC)
[Bug tree-optimization/104530] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r12-7128-gc6bb1db76b3ac127aff7dacf391fc1798a94bb7d The comparison is done before dereferencing pointer, but unlike the PR104288 case there is no call that could fail to return in between. I think PR104288 has been fixed on the 11 branch too, so the question is if this still works there.
[Bug c++/104507] [10/11/12 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[10/11 Regression] internal |[10/11/12 Regression]
|compiler error: unexpected |internal compiler error:
|expression ‘(int)(__ret)’ |unexpected expression
|of kind cast_expr |‘(int)(__ret)’ of kind
||cast_expr
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-14
Known to fail||12.0
--- Comment #6 from Patrick Palka ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Daniel Nelson from comment #2)
> > Had a few moments to do some testing/bisecting, and found the commit that
> > fixed this in mainline.
>
> I kinda of see how that might help here but not really. I wonder if there is
> another testcase which might shows the issue on the trunk still.
trunk crashes on this version:
#define ERR_MAX -20
#define s_errmsg(r) \
_k_errmsg[(((int)r) <= 0 && r) ? -(r) : -ERR_MAX]
extern const char *_k_errmsg[];
template
inline int DoFoo() {
int __ret = 0;
const char *n = s_errmsg(__ret);
return __ret;
}
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > If we just want to avoid the warning in cases like that (there is nothing > wrong in the testcases themselves, the warning just warns about an > implementation detail that a normally uninitialized variable will be really > uninitialized even despite the -ftrivial-auto-var-init= option), then > maybe_warn_switch_unreachable > already has: > if (gimple_code (stmt) == GIMPLE_GOTO > && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL > && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) > /* Don't warn for compiler-generated gotos. These occur >in Duff's devices, for example. */; > and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also > avoid warnings on: > 1) call to .DEFERRED_INIT > 2) call to __builtin_clear_padding if the second argument is present and > non-zero > 3) I guess we would need not to warn on a gimple assign store right after > the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs > anything else? Yes, I think the above 3 should include all the cases.
[Bug libstdc++/100806] deadlock in std::counting_semaphore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Rodgers --- I believe this has been fully resolved.
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3d50dede07de0923f0f320d385162e546445e640 commit r12-7231-g3d50dede07de0923f0f320d385162e546445e640 Author: Jonathan Wakely Date: Mon Feb 14 16:46:55 2022 + libstdc++: Fix stream extraction of IEEE128 long double [PR100912] The std::__convert_from_v helper that formats double and long double values into a char buffer was not being duplicated for the two long double ABIs. This resulted in an ODR violation inside the library, where some callers needed it to use snprintf to format __ibm128 values and other callers needed it to use __snprintfieee128 to format __ieee128 values. The linker discarded one of the definitions, leaving one set of callers using the wrong code. This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace when long double is __ieee128, so that there are two different definitions of the function. The std::money_put::__do_put overload for __ibm128 values needs a different fix, because that is defined when long double is __ieee128 and so would call the one in the inline namespace. That can be fixed by just inlining the code directly into the function and using an asm alias to call the right version of snprintf for the __ibm128 format. The code to do that can be simpler than __convert_from_v because if we're defining the ALT128_COMPAT symbols we know that we have a recent glibc and so we can assume that uselocale and snprintf are supported. libstdc++-v3/ChangeLog: PR libstdc++/100912 * config/locale/gnu/c_locale.h (__convert_from_v): Use inline namespace for IEEE128 long double mode. * config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol version and export __gnu_cxx_ieee128::__convert_from_v. * include/bits/locale_facets_nonio.tcc (money_put::__do_put): Make __ibm128 overload use snprintf directly * testsuite/util/testsuite_abi.cc: Add new symbol version. Remove stable IEEE128/LDBL versions.
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #13 from Jonathan Wakely --- Fixed on trunk now. As this adds new symbol versions I don't plan to backport it to gcc-11. Trunk should be used for anybody who needs IEEE128 support.
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Aleksei Latyshev changed: What|Removed |Added CC||alex_700_95 at mail dot ru --- Comment #6 from Aleksei Latyshev --- Let me add a simplified reproducer for this bug: https://godbolt.org/z/3ec1dW8YE
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 86892. *** This bug has been marked as a duplicate of bug 86892 ***
[Bug rtl-optimization/86892] RTL CSE commoning trivial constants across call and/or too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 104529 has been marked as a duplicate of this bug. ***
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 52439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52439&action=edit gcc12-pr104510.patch Untested fix. Callers don't expect shorten_compare to ever fail, even when it returns NULL it still should convert arguments at least to the original *restype_ptr.
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #8 from Jeffrey A. Law --- So the updated patch fixes the arc build regressions. I haven't looked at the thread with Segher, but I will as soon as I can. Mostly just wanted to let you know that the updated patch does indeed get the port building again.
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Component|tree-optimization |ipa --- Comment #9 from Martin Jambor --- The patch had to be tweaked a bit but I have proposed the following one on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590371.html
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #5 from Martin Jambor --- I have changed the patch a bit and re-submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590341.html
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #2 from Tamar Christina ---
I don't quite see how this is a CSE problem,
There's only one of each constant and none of them are needed before the call.
unlike in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892
You don't need the values of your array until you allocate memory for said
array.
x86 has the following sequence in GIMPLE
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
which is optimal, you create the object, store the values, and remove it.
AArch64 however has this
MEM [(unsigned char *)&D.24688] = 255;
MEM [(unsigned char *)&D.24688 + 4B] = 0;
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})&D.24688];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
which is where the issue comes from. So this has nothing to do with CSE as far
as I can tell. The GIMPLE is just suboptimal.
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Tamar Christina changed:
What|Removed |Added
Summary|[missed optimization] |[12 Regression] inefficient
|inefficient codegen around |codegen around new/delete
|new/delete |
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #3 from Tamar Christina ---
I'm re-opening because I don't think it has anything to do with #94294
This is a GCC 12 regression.
In GCC 11 we generated in the mid-end
[local count: 536870913]:
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
return 56;
and in GCC 12 we now generate
[local count: 536870913]:
MEM [(unsigned char *)&D.24688] = { 255, 0, 0, 0 };
MEM [(unsigned char *)&D.24688 + 4B] = { 0, 0 };
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})&D.24688];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
return 56;
See https://godbolt.org/z/KKfhxTxnd
Forcing it to keep the stores before the call to new.
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Andrew Pinski --- (In reply to Tamar Christina from comment #3) > I'm re-opening because I don't think it has anything to do with #94294 > > This is a GCC 12 regression. > > In GCC 11 we generated in the mid-end > ... > and in GCC 12 we now generate > ... > > See https://godbolt.org/z/KKfhxTxnd > > Forcing it to keep the stores before the call to new. Hmm, I should have looked into the code before marking it as a dup.
[Bug c/104531] New: ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531
Bug ID: 104531
Summary: ICE in prepare_cmp_insn, at optabs.cc:4547
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20210905 and 20210919 :
$ cat z1.c
void f (_Complex int y, int x)
{
#pragma omp atomic compare update seq_cst
x = x > y ? y : x;
}
$ gcc-12-20220213 -c z1.c -fopenmp
during RTL pass: expand
z1.c: In function 'f':
z1.c:3:11: internal compiler error: in prepare_cmp_insn, at optabs.cc:4547
3 | #pragma omp atomic compare update seq_cst
| ^~~
0xafd677 prepare_cmp_insn
../../gcc/optabs.cc:4547
0xafd711 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
../../gcc/optabs.cc:4692
0x839688 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
../../gcc/dojump.cc:1220
0x8df4a5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:9745
0x7c4ea2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3967
0x7c4ea2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4028
0x7c9bd7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6069
0x7cc67e execute
../../gcc/cfgexpand.cc:6795
[Bug c/104532] New: ICE in lvalue_p, at c/c-typeck.cc:4987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104532
Bug ID: 104532
Summary: ICE in lvalue_p, at c/c-typeck.cc:4987
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211205 and 20211212 :
$ cat z1.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors)
}
$ cat z2.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors[])
}
$ gcc-12-20220213 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:3:11: internal compiler error: Segmentation fault
3 | #pragma omp target enter data map (to: x->vectors)
| ^~~
0xc1c3cf crash_signal
../../gcc/toplev.cc:322
0x6c1a46 lvalue_p(tree_node const*)
../../gcc/c/c-typeck.cc:4987
0x6ca5a8 build_component_ref(unsigned int, tree_node*, tree_node*, unsigned
int)
../../gcc/c/c-typeck.cc:2470
0x6f742e c_parser_omp_variable_list
../../gcc/c/c-parser.cc:13161
0x6f81dc c_parser_omp_clause_map
../../gcc/c/c-parser.cc:16260
0x700262 c_parser_omp_all_clauses
../../gcc/c/c-parser.cc:17057
0x70d6ae c_parser_omp_target_enter_data
../../gcc/c/c-parser.cc:20904
0x70d6ae c_parser_omp_target
../../gcc/c/c-parser.cc:21195
0x6e7a44 c_parser_pragma
../../gcc/c/c-parser.cc:12499
0x7054a6 c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:5767
0x705873 c_parser_compound_statement
../../gcc/c/c-parser.cc:5609
0x707128 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2544
0x70e85f c_parser_external_declaration
../../gcc/c/c-parser.cc:1779
0x70f18b c_parser_translation_unit
../../gcc/c/c-parser.cc:1652
0x70f18b c_parse_file()
../../gcc/c/c-parser.cc:23348
0x760792 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1238
[Bug middle-end/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Summary|ICE in prepare_cmp_insn, at |[12 Regression] ICE in |optabs.cc:4547 |prepare_cmp_insn, at ||optabs.cc:4547 Keywords||ice-on-valid-code Target Milestone|--- |12.0 Component|c |middle-end
[Bug c++/104533] New: [12 Regression] ICE in update_vtable_references, at ipa-visibility.cc:383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104533
Bug ID: 104533
Summary: [12 Regression] ICE in update_vtable_references, at
ipa-visibility.cc:383
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 2024 and 20211121 :
$ cat z1.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("avx")))
B::~B() = default;
$ cat z2.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("sse","avx")))
B::~B() = default;
$ g++-12-20220213 -c z1.cc -fPIC -Ofast
during IPA pass: visibility
z1.cc:5:18: internal compiler error: Segmentation fault
5 | B::~B() = default;
| ^
0xda1fdf crash_signal
../../gcc/toplev.cc:322
0x19be64f update_vtable_references
../../gcc/ipa-visibility.cc:383
0x1029952 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11070
0x1029b9c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11157
0x19bf549 function_and_variable_visibility
../../gcc/ipa-visibility.cc:868
[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Component|middle-end |c Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #1 from Andrew Pinski --- I think this might be invalid code. The C++ front-end does: : In function 'void f(__complex__ int, int)': :3:11: error: invalid operands of types 'int' and '__complex__ int' to binary '' 3 | #pragma omp atomic compare update seq_cst | ^~~ :3:11: note: in evaluation of '(int, __complex__ int)' Without -fopenmp we get: : In function 'f': :4:9: error: invalid operands to binary > (have 'int' and 'complex int') 4 | x = x > y ? y : x; | ^
[Bug c++/104534] New: write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534
Bug ID: 104534
Summary: write-strings does not follow C++ standard
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johnsen.david at siemens dot com
Target Milestone: ---
The bug is present in all versions of GCC from 6 to 11 and on GCC trunk.
example file ws.cpp:
#include
void f(char*) { std::cout << "This compiler is broken" << std::endl; }
void f(bool) { std::cout << "This compiler is correct" << std::endl; }
int main() {
f("This is supposed to work");
return 0;
}
This program is a valid C++ and the standard is very clear on what the result
should be.
As far as I know, there is no way to make GCC generate this result.
compiled with: c++ ws.cpp
Depending on the command line options, the program can:
* compile (and run incorrectly, -Wnowrite-strings),
* compile with a warning (still run incorrectly, -Wwrite-strings),
* or not compile at all (-Werror -Wwrite-strings).
The only outcome that I can't get is the correct one:
* The program compiles without errors and runs correctly.
Other compilers, such as clang++ and Visual Studio C++, follow the standard.
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:19b517dff37b8e25f6babf8883483be73cad8fb3 commit r12-7232-g19b517dff37b8e25f6babf8883483be73cad8fb3 Author: Harald Anlauf Date: Thu Feb 10 21:22:48 2022 +0100 Fortran: improve error recovery on bad array section gcc/fortran/ChangeLog: PR fortran/104211 * expr.cc (find_array_section): Replace assertion by error recovery when encountering bad array constructor. gcc/testsuite/ChangeLog: PR fortran/104211 * gfortran.dg/pr104211.f90: New test.
[Bug c++/104534] write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 95596. *** This bug has been marked as a duplicate of bug 95596 ***
[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596 Andrew Pinski changed: What|Removed |Added CC||johnsen.david at siemens dot com --- Comment #7 from Andrew Pinski --- *** Bug 104534 has been marked as a duplicate of this bug. ***
[Bug fortran/104535] New: don't use fmod?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104535 Bug ID: 104535 Summary: don't use fmod? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fx at gnu dot org Target Milestone: --- I was reminded by comments on the report I made about poor fmod performance on x86 that I should have commented on the original observation. I'd looked at one of the Polyhedron benchmarks which suffers badly from a simple random number routine that calls DMOD. That gets compiled to fmod, which is only inlined, albeit poorly on x86, with the relevant component(s) of -ffast-math. It seems to me that MOD should compile to the arithmetical expression in the standard, which doesn't have the complication of having to treat errors. (When I defined DMOD as a statement function for it in that routine, I got performance much closer to ifort. I should have kept the profiles I compared, but could regenerate them. Is there a good reason not to do that (and maybe similarly with other intrinsics I haven't checked)? I could probably have a go at implementing it if appropriate, though I don't know my way around now.
[Bug c++/104523] G++ crash when compiling a simple module that includes pybind11/stl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104523
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Last reconfirmed|2022-02-13 00:00:00 |2022-02-14
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Confirmed, reduced testcase:
# 1 "mysource.cc"
module ;
# 1 "myheader.h" 1
template
class t {
template friend class tt;
};
t to_wstring() { }
# 4 "mysource.cc" 2
export module mymodule;
Or maybe that is a regression from before
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #3 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #2) > and evrp properly figured out those ranges, that 1 / int is [-1, 1] and > that 2 >> [-1, 1] is [1, 2]. > But since r12-6924 the IL is: > c.0_1 = c; > _2 = *c.0_1; > _11 = (unsigned int) _2; > _12 = _11 + 1; > _13 = _12 <= 2; > _3 = _12 <= 2 ? _2 : 0; > So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, > so that it essentially does what we do for the PHI cases? I.e. from the > COND_EXPR condition, compute "assertion" if condition is true or if > condition is false, and use that on the COND_EXPR's second and third > argument. > So for the > _3 = _12 <= 2 ? _2 : 0; > comparison, for second argument the condition must be true which implies that > _2 must be there [-1, 1], while for the third argument the condition must be > false, but the argument is constant 0, so range is [0, 0], then just union > those 2 ranges. > > As this is a P1 regression, if we can fix it, would be nice to get it into > GCC 12. I'm having a look. The bits are all there. Most of gori is stmt oriented, but I may be able to invoke the components such that we evaluate the 2nd and 3rd arguemnts as if they were on true/false edges to improve the results..
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #12 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:16b65b08484237cc2845c4f5c4f15efe3a43a32c commit r12-7233-g16b65b08484237cc2845c4f5c4f15efe3a43a32c Author: Michael Meissner Date: Mon Feb 14 17:42:14 2022 -0500 Use correct names for __ibm128 if long double is IEEE 128-bit. If you are on a PowerPC system where the default long double is IEEE 128-bit (either through the compiler option -mabi=ieeelongdouble or via the configure option --with-long-double-format=ieee), GCC used the wrong names for some of the conversion functions for the __ibm128 type. Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit, instead of TFmode when long double is IBM 128-bit. This patch adds the missing conversions to prevent the 'if' name from being used. In particular, before the patch, the conversions used were: IFmode to DImode signed:__fixifdi instead of __fixtfdi IFmode to DImode unsigned __fixunsiftiinstead of __fixunstfti DImode to IFmode signed:__floatdiif instead of __floatditf DImode to IFmode unsigned: __floatundiif instead of __floatunditf 2022-02-14 Michael Meissner gcc/ PR target/104253 * config/rs6000/rs6000.cc (init_float128_ibm): Update the conversion functions used to convert IFmode types. gcc/testsuite/ PR target/104253 * gcc.target/powerpc/pr104253.c: New test.
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:7a1b179b08bc802280ca90ed4c6c8d8b25503e66 commit r12-7234-g7a1b179b08bc802280ca90ed4c6c8d8b25503e66 Author: Martin Sebor Date: Mon Feb 14 15:40:25 2022 -0700 Update -Warray-bounds documentation [PR104355]. Resolves: PR middle-end/104355 - Misleading and outdated -Warray-bounds documentation gcc/ChangeLog: PR middle-end/104355 * doc/invoke.texi (-Warray-bounds): Update documentation.
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #9 from qinzhao at gcc dot gnu.org --- having a patch in my local tree, under testing.
[Bug bootstrap/104536] New: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Bug ID: 104536 Summary: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mckelvey at maskull dot com Target Milestone: --- Created attachment 52440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52440&action=edit Log of entire build Building on Cygwin with gcc-11-20220212 and Windows 10. ./configure --enable-languages=c,c++ --enable-threads=posix --disable-multilib $ uname CYGWIN_NT-10.0 make[3]: Entering directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' /home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/xg++ -B/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/ -B/usr/local/x86_64-pc-cygwin/bin/ -nostdinc++ -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include -I/home/McKelvey/gcc-12-20220213/libstdc++-v3/libsupc++ -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace \ ../.././gcc/config/i386/host-cygwin.cc ../.././gcc/config/i386/host-cygwin.cc: In function ‘void* cygwin_gt_pch_get_address(size_t, int)’: ../.././gcc/config/i386/host-cygwin.cc:57:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 57 | fatal_error (input_location, "can%'t get position in PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:64:37: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 64 | fatal_error (input_location, "can%'t extend PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:75:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 75 | fatal_error (input_location, "can%'t set position in PCH file: %m"); | ^~ cc1plus: all warnings being treated as errors make[3]: *** [../.././gcc/config/i386/x-cygwin:3: host-cygwin.o] Error 1 make[3]: Leaving directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' make[2]: *** [Makefile:5003: all-stage2-gcc] Error 2 make[2]: Leaving directory '/home/McKelvey/gcc-12-20220213' make[1]: *** [Makefile:24127: stage2-bubble] Error 2 make[1]: Leaving directory '/home/McKelvey/gcc-12-20220213' make: *** [Makefile:1072: all] Error 2
[Bug bootstrap/104536] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 --- Comment #1 from James McKelvey --- Created attachment 52441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52441&action=edit Config log
[Bug other/104536] [12 Regression] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Andrew Pinski changed: What|Removed |Added Component|bootstrap |other Host||*-*-cygwin Summary|gcc-12-20220213 Fails to|[12 Regression] |build on Cygwin:|gcc-12-20220213 Fails to |contraction ‘can%'t’ in |build on Cygwin: |format |contraction ‘can%'t’ in ||format Target Milestone|--- |12.0 Keywords||build, diagnostic
[Bug target/99197] Built-ins for packing/unpacking __ibm128 not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Michael Meissner ---
These functions have been documented since June 2018. The file extend.texi
contains:
The @code{__builtin_unpack_ibm128} function takes a @code{__ibm128}
argument and a compile time constant of 0 or 1. If the constant is 0,
the first @code{double} within the @code{__ibm128} is returned,
otherwise the second @code{double} is returned.
The @code{__builtin_pack_ibm128} function takes two @code{double}
arguments and returns a @code{__ibm128} value that combines the two
arguments.
[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #5 from Martin Sebor ---
Setting aside the question of warning about inequality expressions involving
invalid pointers, it seems that if the annotation 'candidates ={v}
{CLOBBER(eol)};' is to be interpreted as one would intuitively expect -- as
ending the variable's lifetime -- then GCC moving its use past that point
should be considered a bug in that transformation.
[Bug c++/104537] New: ICE when generic-lambda as function parameter fails to be converted to pointer to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104537
Bug ID: 104537
Summary: ICE when generic-lambda as function parameter fails to
be converted to pointer to function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this invalid conversion for this generic-lambda to pointer to function
which is defined by "decltype(+[](T&& t )->T{return t+1;}".
This ICE happens when original accepted parameter type changed from "T" to
"T&&".
See compiler explorer (https://www.godbolt.org/z/fde1bc3zE)
I suspect this is some related issue with another unconfirmed case PR104358.
template
auto foo(T&& t, decltype(+[](T&& t )->T{return t+1;}) lam){
return lam(t);
}
void test(){
foo(5, [](int t){return t+1;});
}
:8:21: error: invalid user-defined conversion from
'test()::' to 'int (*)(int&&)' [-fpermissive]
8 | foo(5, [](int t){return t+1;});
| ^~
...
internal compiler error: error reporting routines re-entered.
0x2174365 warning_at(unsigned int, int, char const*, ...)
...
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #14 from Jarrod Smith --- I've been following this and experiencing the issue in gcc 10.2. I still see "" for all variables when debugging C++20 coroutines with gcc 11.2. Is there a workaround (e.g. using a certain branch of gcc) in order to inspect coroutine variables with gdb the meantime?
