[Bug tree-optimization/106025] [13 Regression] Incorrect optimization at -O2 leads to infinite test execution time since r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106025 Martin Liška changed: What|Removed |Added Summary|Incorrect optimization at |[13 Regression] Incorrect |-O2 leads to infinite test |optimization at -O2 leads |execution time |to infinite test execution ||time since ||r13-469-g9a53101caadae1b5 Last reconfirmed||2022-06-20 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r13-469-g9a53101caadae1b5.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #5 from Martin Liška ---
(In reply to Andrew Pinski from comment #4)
> Here is a testcase which shows this was latent but fails in GCC 7+ (so it is
> still a regression):
> int a, b, c, *d;
> int main() {
> int e = 0, f = 0;
> int *dd = d;
> for (; f < 1; f++)
> if (c < 0)
> e = *dd;
> if (a) {
> a = b ? 0 : a;
> e && (b = a);
> }
> return 0;
> }
This one started with r9-6299-gd7a700e0a701e516.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
--- Comment #6 from Andrew Pinski ---
(In reply to Martin Liška from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > Here is a testcase which shows this was latent but fails in GCC 7+ (so it is
> > still a regression):
> > int a, b, c, *d;
> > int main() {
> > int e = 0, f = 0;
> > int *dd = d;
> > for (; f < 1; f++)
> > if (c < 0)
> > e = *dd;
> > if (a) {
> > a = b ? 0 : a;
> > e && (b = a);
> > }
> > return 0;
> > }
>
> This one started with r9-6299-gd7a700e0a701e516.
I guess I need to make another testcase since that would have just changed the
gimple level.
[Bug go/106033] New: [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033 Bug ID: 106033 Summary: [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: marxin at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Created attachment 53167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53167&action=edit Build log Fails with: libtool: compile: /home/marxin/Programming/gcc/objdir/./gcc/gccgo -B/home/marxin/Programming/gcc/objdir/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=sort ../../../libgo/go/sort/search.go ../../../libgo/go/sort/slice.go ../../../libgo/go/sort/slice_go113.go ../../../libgo/go/sort/sort.go ../../../libgo/go/sort/zfuncversion.go -o sort.o >/dev/null 2>&1 ../../../libgo/go/syscall/libcall_linux.go:220:25: error: reference to undefined name ‘_libgo_loff_t_type’ 220 | lroff = _libgo_loff_t_type(*roff) | ^ ../../../libgo/go/syscall/libcall_linux.go:226:25: error: reference to undefined name ‘_libgo_loff_t_type’ 226 | lwoff = _libgo_loff_t_type(*woff) | ^ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ 217 | var lroff _libgo_loff_t_type | ^ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’ ../../../libgo/go/syscall/libcall_linux.go:217:19: error: use of undefined type ‘_libgo_loff_t_type’
[Bug tree-optimization/106019] Surprising SLP failure on trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-06-20 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/106024] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Note clang rejects it with:
clang++ pr106033.C -c -std=c++2a
pr106033.C:6:27: error: expected ')'
}.operator()(args...)...
^
pr106033.C:6:22: note: to match this '('
}.operator()(args...)...
^
pr106033.C:6:6: error: missing 'template' keyword prior to dependent template
name 'operator()'
}.operator()(args...)...
^
pr106033.C:8:4: note: in instantiation of function template specialization
'foo()::(anonymous class)::operator()<1, 2, 3>' requested here
}.operator()<1, 2, 3>();
^
2 errors generated.
[Bug tree-optimization/106027] [11/12/13 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106027 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-06-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|ICE: 'verify_gimple' failed |[11/12/13 Regression] ICE: |(error: mismatching |'verify_gimple' failed |comparison operand types) |(error: mismatching ||comparison operand types) ||since ||r11-2450-g10231958fcfb13bc --- Comment #1 from Martin Liška --- Started with r11-2450-g10231958fcfb13bc.
[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 Priority|P3 |P2
[Bug middle-end/105998] [10/11/12 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics since r9-1971-g315aa691f486bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug sanitizer/105729] False positive UBsan "reference binding to null pointer of type" when evaluating array indexing which throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105729 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Jakub Jelinek --- Fixed (Honza, hope you don't mind the backports I've done, did that so that it is on time for 10.4).
[Bug middle-end/105951] [12 Regression] ICE in emit_store_flag, at expmed.cc:6027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 12.2 too.
[Bug c++/105871] ICE: in wide_int_to_tree_1, at tree.cc:1777 with __builtin_shufflevector() in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 12.2 and 13+. GCC 11 doesn't have __builtin_shufflevector support.
[Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Richard Biener changed: What|Removed |Added Keywords||needs-reduction Blocks||24639 --- Comment #3 from Richard Biener --- # VUSE <.MEM_699> _109 = MEM[(struct loadcmd *)_106 + -56B].mapend; my only suspicion is that we somehow isolate (and not optimize as unreachable) the nloadcmds < 1 case in the preceeding case. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |11.4
[Bug middle-end/106010] Miss vectorization for complex type copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Target||x86_64-*-* Last reconfirmed||2022-06-20 Component|tree-optimization |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We RTL expand ;; _5 = MEM[(complex double *)q_9(D) + ivtmp.12_14 * 1]; (insn 9 8 10 (set (reg:DF 82 [ _5 ]) (mem:DF (plus:DI (reg/v/f:DI 86 [ q ]) (reg:DI 84 [ ivtmp.12 ])) [1 MEM[(complex double *)q_9(D) + ivtmp.12_14 * 1]+0 S8 A64])) "t.c":5:15 -1 (nil)) (insn 10 9 0 (set (reg:DF 83 [ _5+8 ]) (mem:DF (plus:DI (plus:DI (reg/v/f:DI 86 [ q ]) (reg:DI 84 [ ivtmp.12 ])) (const_int 8 [0x8])) [1 MEM[(complex double *)q_9(D) + ivtmp.12_14 * 1]+8 S8 A64])) "t.c":5:15 -1 (nil)) ;; MEM[(complex double *)p_10(D) + ivtmp.12_14 * 1] = _5; (insn 11 10 12 (set (mem:DF (plus:DI (reg/v/f:DI 85 [ p ]) (reg:DI 84 [ ivtmp.12 ])) [1 MEM[(complex double *)p_10(D) + ivtmp.12_14 * 1]+0 S8 A64]) (reg:DF 82 [ _5 ])) "t.c":5:12 -1 (nil)) (insn 12 11 0 (set (mem:DF (plus:DI (plus:DI (reg/v/f:DI 85 [ p ]) (reg:DI 84 [ ivtmp.12 ])) (const_int 8 [0x8])) [1 MEM[(complex double *)p_10(D) + ivtmp.12_14 * 1]+8 S8 A64]) (reg:DF 83 [ _5+8 ])) "t.c":5:12 -1 (nil)) likely assigning (concat:CD ...) to the pseudos instead of using xmm regs. So for the copy case that's a target issue IMHO. One could argue that without move patterns for complex we should eventually lower memory accesses like we lower arithmetic. Note as soon as we do for (int i = 0; i != 10; i++) p[i] = q[i] + 1.; we do get the memory accesses lowered and the code vectorized. Extra complications with _Complex arguments where we do _not_ want to lower the loads (without further thoughts). foo (p[i]); for foo (p[i] + 1.); we get _6 = IMAGPART_EXPR <*_3>; _4 = REALPART_EXPR <*_3>; _5 = _4 + 1.0e+0; _7 = COMPLEX_EXPR <_5, _6>; bar (_7); which is also similar as to what we expand foo (p[i]) to.
[Bug target/106012] rsqrtps and rcpps instructions generated even if -fno-reciprocal-math specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Component|tree-optimization |target --- Comment #4 from Richard Biener --- (In reply to vincenzo Innocente from comment #3) > Thanks for the suggestion. > > -fno-reciprocal-math does indeed inhibit scalar reciprocal instructions. > > NOT in vectorized loop though. > > see > > https://godbolt.org/z/9eMb4Tjee For that you need -mno-recip as well ... (here it's the target expanding the division). Maybe the target should take -fno-reciprocal-math as enabling -mno-recip.
[Bug target/106012] rsqrtps and rcpps instructions generated even if -fno-reciprocal-math specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012 --- Comment #5 from Richard Biener --- (In reply to Uroš Bizjak from comment #1) > recip pass is converting to .RSQRT, target is just expanding what it gets. But it queries the target for support for RSQRT, but yeah, we lack to ask for "implicit" vs. "explicit" (via xmm intrinsics), so the target cannot possibly disable RSQRT expanders I guess.
[Bug c/106018] Feature Request: Add function attribute fn_enter, and fn_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106018 --- Comment #1 from Richard Biener --- it's going to be "interesting" if the arguments or return types need construction (C++).
[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 --- Comment #6 from Martin Liška --- Note I see the same error for inkscape package.
[Bug c++/90670] const& template parameter in a header trips -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90670 Alexey Rusakov changed: What|Removed |Added CC||Kitsune-Ral at users dot sf.net --- Comment #1 from Alexey Rusakov --- Reproduced with GCC 12.1.1 on Fedora 36.
[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 --- Comment #17 from hubicka at kam dot mff.cuni.cz --- > Fixed (Honza, hope you don't mind the backports I've done, did that so that it > is on time for 10.4). Thanks. I don't mind: I was planning to do them this week anyway and also extra VOLATILE check shoud not be very risky.
[Bug tree-optimization/106019] Surprising SLP failure on trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. Creating dr for *_3 analyze_innermost: success. base_address: p_12(D) + (sizetype) i_11(D) * 8 offset from base address: 0 constant offset from base address: 0 step: 0 base alignment: 8 base misalignment: 0 offset alignment: 128 step alignment: 128 base_object: *_3 vs. Creating dr for *_8 analyze_innermost: success. base_address: p_12(D) + (sizetype) i_11(D) * 8 offset from base address: 0 constant offset from base address: 8 step: 0 base alignment: 8 base misalignment: 0 offset alignment: 128 step alignment: 128 base_object: *_8 the base_object are different which makes dependence analysis fail. I suppose we could look at the case of equal base_address here - the loop based dependence analysis might be not the optimal thing to check. Richard, any opinions how we should deal with this API wise? This is vect_slp_analyze_node_dependences
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.2
Ever confirmed|0 |1
Last reconfirmed||2022-06-20
Status|UNCONFIRMED |NEW
--- Comment #3 from Richard Biener ---
We already put the const_vector into the constant pool at RTL expansion time,
possibly because the move patterns do not allow vector constants fitting into
{SI,DI}mode?
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 --- Comment #4 from Richard Biener --- (In reply to H.J. Lu from comment #1) > SLP thinks that it needs 4 stores to store 4 bytes of integer constant. > But it takes only 1 4-byte store. Yes, SLP looks at the GIMPLE IL, if you disable store-merging you'll get 4 stores. SLP doesn't anticipate any optimizations that follow it.
[Bug tree-optimization/106025] [13 Regression] Incorrect optimization at -O2 leads to infinite test execution time since r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106025 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I will have a look next week.
[Bug tree-optimization/106027] [11/12/13 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106027 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |11.4 Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/106027] [11/12/13 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106027
--- Comment #3 from Richard Biener ---
So the issue seems to be that
#4 0x00f82be3 in fold_binary_loc (loc=2147483656,
code=TRUTH_ANDIF_EXPR, type=,
op0=, op1=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:12044
/* A < X && A + 1 > Y ==> A < X && A >= Y. Normally A + 1 > Y
means A >= Y && A != MAX, but in this case we know that
A < X <= MAX. */
if (!TREE_SIDE_EFFECTS (arg0)
&& !TREE_SIDE_EFFECTS (arg1))
{
tem = fold_to_nonsharp_ineq_using_bound (loc, arg0, arg1);
if (tem && !operand_equal_p (tem, arg0, 0))
return fold_build2_loc (loc, code, type, tem, arg1);
tem = fold_to_nonsharp_ineq_using_bound (loc, arg1, arg0);
if (tem && !operand_equal_p (tem, arg1, 0))
return fold_build2_loc (loc, code, type, arg0, tem);
builds unsigned type TRUTH_ANDIF_EXPR with signed type arg0/tem (op0/op1
are conversions to unsigned type). The offending revision just chokes
on the invalid input.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/106030] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030
--- Comment #2 from Jakub Jelinek ---
Deobfuscated:
int a, b, c;
char
foo (int x, int y)
{
return x * y;
}
void
bar (void)
{
char d = (foo <= b) * a;
c = foo (2 != bar, d);
}
[Bug middle-end/106030] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-06-20 Component|target |middle-end
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
--- Comment #5 from Hongtao.liu ---
(In reply to Richard Biener from comment #3)
> We already put the const_vector into the constant pool at RTL expansion time,
> possibly because the move patterns do not allow vector constants fitting into
> {SI,DI}mode?
Good idea, it maybe better to support it in the move patterns.
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 --- Comment #9 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:86882d9feb6a534325d7162216696266898e36d0 commit r13-1173-g86882d9feb6a534325d7162216696266898e36d0 Author: Kewen Lin Date: Mon Jun 20 07:44:21 2022 -0500 vect: Respect slp decision when applying suggested uf [PR105940] This follows Richi's suggestion in PR105940, it aims to avoid inconsistent slp decision between when the suggested unroll factor is worked out and when the suggested unroll factor is applied. If the previous slp decision is true when the suggested unroll factor is worked out, when we are applying unroll factor we don't need to start over with slp off if the analysis with slp on fails. On the other hand, if the previous slp decision is false when the suggested unroll factor is worked out, when we are applying unroll factor we can skip the slp handlings. Function vect_is_simple_reduction saves reduction chains for subsequent slp analyses, we have to disable this early otherwise there is an ICE in vectorizable_reduction for below: if (REDUC_GROUP_FIRST_ELEMENT (stmt_info)) gcc_assert (slp_node && REDUC_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info); PR tree-optimization/105940 gcc/ChangeLog: * tree-vect-loop.cc (vect_analyze_loop_2): Add new parameter slp_done_for_suggested_uf and adjust with it accordingly. (vect_analyze_loop_1): Add new variable slp_done_for_suggested_uf, pass it down to vect_analyze_loop_2 for the initial analysis and applying suggested unroll factor. (vect_is_simple_reduction): Add parameter slp and adjust with it. (vect_analyze_scalar_cycles_1): Add parameter slp and pass down. (vect_analyze_scalar_cycles): Likewise.
[Bug middle-end/106030] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 53168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53168&action=edit gcc13-pr106030.patch Untested fix. But it is unclear when it started...
[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 --- Comment #7 from Martin Liška --- And I reduced to the pretty same code snippet as Marek did.
[Bug tree-optimization/106027] [11/12/13 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106027 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:713f2fd923442b1be620a44240ddf786ae0ab476 commit r13-1174-g713f2fd923442b1be620a44240ddf786ae0ab476 Author: Richard Biener Date: Mon Jun 20 13:40:50 2022 +0200 middle-end/106027 - fix types in needle folding The fold_to_nonsharp_ineq_using_bound folding ends up creating invalid typed IL which confuses later foldings. The following fixes that. 2022-06-20 Richard Biener PR middle-end/106027 * fold-const.cc (fold_to_nonsharp_ineq_using_bound): Use the type of the prevailing comparison for the new comparison type. (fold_binary_loc): Use proper types for the A < X && A + 1 > Y to A < X && A >= Y folding. * gcc.dg/pr106027.c: New testcase.
[Bug middle-end/106027] [11/12 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106027 Richard Biener changed: What|Removed |Added Component|tree-optimization |middle-end Known to fail|13.0| Known to work||13.0 Priority|P3 |P2 Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: |'verify_gimple' failed |'verify_gimple' failed |(error: mismatching |(error: mismatching |comparison operand types) |comparison operand types) |since |since |r11-2450-g10231958fcfb13bc |r11-2450-g10231958fcfb13bc --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 --- Comment #6 from H.J. Lu --- Created attachment 53169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53169&action=edit A patch This patch multiplies the vector store cost by the number of scalar elements in a word to properly compare scalar store cost against vector store cost.
[Bug middle-end/106030] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 --- Comment #4 from Alex Coplan --- Started with r13-673-gd863ba23fb16122bb0547b0c678173be0d98f43c : commit d863ba23fb16122bb0547b0c678173be0d98f43c Author: Roger Sayle Date: Thu May 19 17:54:38 2022 +0100 PR middle-end/98865: Expand X*Y as X&-Y when Y is [0,1].
[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Summary|ice in emit_move_insn, at |[13 Regression] ice in |expr.cc:4026|emit_move_insn, at ||expr.cc:4026 Target Milestone|--- |13.0
[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 --- Comment #5 from Jakub Jelinek --- Still it is latent on the release branches.
[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 --- Comment #6 from David Binderman --- Around 22,000 executions of csmith per 24 hours and feeding the results to trunk gcc are proving their value in flushing out bugs in gcc.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
--- Comment #7 from Jakub Jelinek ---
This one seems to be very old:
__attribute__((noipa, noinline, noclone)) int
foo (int x, int *y)
{
int a = 0;
if (x < 0)
a = *y;
return a;
}
int
main ()
{
int a = 42;
if (foo (0, 0) != 0 || foo (1, 0) != 0)
__builtin_abort ();
if (foo (-1, &a) != 42 || foo (-42, &a) != 42)
__builtin_abort ();
return 0;
}
I guess checking may_trap_p or may_trap_or_fault_p in noce_try_sign_mask would
fix this, but we probably should check other noce_* functions how they handle
possibly faulting memory.
[Bug target/105960] [12/13 Regression] Crash in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:fe9765c0b97e6b4ce2cd226631d329fc05ba2aa5 commit r13-1180-gfe9765c0b97e6b4ce2cd226631d329fc05ba2aa5 Author: H.J. Lu Date: Tue Jun 14 08:20:16 2022 -0700 i386: Disallow sibcall for calling ifunc functions with PIC register Disallow siball when calling ifunc functions with PIC register so that PIC register can be restored. gcc/ PR target/105960 * config/i386/i386.cc (ix86_function_ok_for_sibcall): Return false if PIC register is used when calling ifunc functions. gcc/testsuite/ PR target/105960 * gcc.target/i386/pr105960.c: New test.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Started likely with r0-57085
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Jakub Jelinek --- Created attachment 53170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53170&action=edit gcc13-pr106032.patch Untested fix.
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 --- Comment #7 from H.J. Lu --- Created attachment 53171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53171&action=edit The v2 patch Handle vector store.
[Bug tree-optimization/106019] Surprising SLP failure on trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from rsandifo at gcc dot gnu.org --- Created attachment 53172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53172&action=edit Candidate patch Huh, yeah, surprising this has been present so long. Running aff_combination_expand on off2 before the query in (from dr_may_alias_p): aff_tree off1, off2; poly_widest_int size1, size2; get_inner_reference_aff (DR_REF (a), &off1, &size1); get_inner_reference_aff (DR_REF (b), &off2, &size2); aff_combination_scale (&off1, -1); aff_combination_add (&off2, &off1); if (aff_comb_cannot_overlap_p (&off2, size1, size2)) return false; seems to fix it, but I guess that then adds the burden of maintaining the cache. Since we've already done similar SSA_NAME expansion for DR_BASE_ADDRESS/DR_OFFSET, perhaps we should just try to use that instead? The attached patch does that and fixes the testcase. But maybe there are cases that aff_combination_expand would handle and this patch wouldn't -- not sure.
[Bug tree-optimization/105835] [13 Regression] Dead Code Elimination Regression at -O1 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105835 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Roger Sayle --- This should now be fixed on mainline.
[Bug c++/106034] New: internal compiler error: in type_node, at cp/module.cc:8736 using --with-long-double-format=ieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106034 Bug ID: 106034 Summary: internal compiler error: in type_node, at cp/module.cc:8736 using --with-long-double-format=ieee Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-c++ RUNTESTFLAGS="modules.exp=binding-1_a.H" FAIL: g++.dg/modules/binding-1_a.H -std=c++17 (internal compiler error: in type_node, at cp/module.cc:8736) FAIL: g++.dg/modules/binding-1_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/binding-1_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/binding-1_a.H.gcm) FAIL: g++.dg/modules/binding-1_a.H -std=c++2a (internal compiler error: in type_node, at cp/module.cc:8736) FAIL: g++.dg/modules/binding-1_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/binding-1_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/binding-1_a.H.gcm) FAIL: g++.dg/modules/binding-1_a.H -std=c++2b (internal compiler error: in type_node, at cp/module.cc:8736) FAIL: g++.dg/modules/binding-1_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/binding-1_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/binding-1_a.H.gcm) This is an issue specifically with compilers configured with --with-long-double-format=ieee. It also shows up in gcc 10, 11, and 12 though at a different line #. I am only seeing it on a system where the distro (Fedora 36) tools were also built with --with-long-double-format=ieee. My trunk compiler was configured was with --enable-languages=c,fortran,c++ --with-cpu=power9 --enable-bootstrap --disable-multilib --with-long-double-format=ieee Note: bootstrap part doesn't matter as a non-bootstrap compiler also ICEs the same way. The distro compiler was gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC) and was configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-targets=powerpcle-linux --disable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/obj-ppc64le-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt --with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8 --with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8 --build=ppc64le-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ieee-bootstrap/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-ieee-bootstrap/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-ieee-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-ieee-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodule-header -S -o binding-1_a.s^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: internal compiler error: in type_node, at cp/module.cc:8736^M 0x104fe15f trees_out::type_node(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:8736^M 0x104f94cb trees_out::tree_node(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:9064^M 0x104fd597 trees_out::type_node(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:8730^M 0x104f94cb trees_out::tree_node(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:9064^M 0x104fade3 trees_out::core_vals(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:6009^M 0x104fcd5b trees_out::tree_node_vals(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:7076^M 0x104fcd5b trees_out::fn_parms_init(tree_node*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:9996^M 0x104f666b trees_out::decl_value(tree_node*, depset*)^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/cp/module.cc:7640^M
[Bug fortran/69200] ICE on subsequent block statements with module imports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69200 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Status|NEW |WAITING --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #3) > This seems to work on trunk. > > % gfcx -o z q1.f90 q.f90 > % ./z > testProc > testProc > > This is still broken on branch-8. > This is still broken on branch-7. This is still fixed. If someone else can confirm that the example code compiles with gfortran 10, 11, and trunk, then this can likely be closed.
[Bug fortran/106035] New: F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Bug ID: 106035 Summary: F2018 allows an IMPORT statement within the BLOCK construct. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- % cat a.f90 program bug implicit none integer i i = 42 block import none ! <-- This is valid Fortran 2018 integer j j = 12 print *, j end block print *, i end program bug % gfortran -c a.f90 a.f90:6:13: 6 | import none | 1 Error: IMPORT statement at (1) only permitted in an INTERFACE body
[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106033 --- Comment #1 from Ian Lance Taylor --- Created attachment 53173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53173&action=edit Potential patch I haven't been able to recreate the problem, but does this patch fix it? Thanks.
[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:ddc9b963ab9f267e8cc54be1fa6fcca2e8b0eb84 commit r12-8498-gddc9b963ab9f267e8cc54be1fa6fcca2e8b0eb84 Author: Uros Bizjak Date: Fri Jun 17 17:01:31 2022 +0200 i386: Fix assert in ix86_function_arg [PR105970] The mode of pointer argument should equal ptr_mode, not Pmode. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105970 * config/i386/i386.cc (ix86_function_arg): Assert that the mode of pointer argumet is equal to ptr_mode, not Pmode. gcc/testsuite/ChangeLog: PR target/105970 * gcc.target/i386/pr105970.c: New test. (cherry picked from commit 1f8278bfcfc7f7157bf2b405471e67dd5097636b)
[Bug c++/106034] internal compiler error: in type_node, at cp/module.cc:8736 using --with-long-double-format=ieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106034 --- Comment #1 from seurer at gcc dot gnu.org --- There are some more errors further along in the test case that appear related: spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ieee-bootstrap/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-ieee-bootstrap/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_c.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-ieee-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-ieee-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-ieee-bootstrap/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts -S -o binding-1_c.s^M In module imported at /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_c.C:6:1:^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: error: failed to read compiled module: No such file or directory^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: note: compiled module file is 'gcm.cache/./home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H.gcm'^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: note: imports must be built before being imported^M /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: fatal error: returning to the gate for a mechanical issue^M compilation terminated.^M compiler exited with status 1 FAIL: g++.dg/modules/binding-1_c.C -std=c++2a (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: error: failed to read compiled module: No such file or directory /home/seurer/gcc/git/gcc-ieee-bootstrap/gcc/testsuite/g++.dg/modules/binding-1_a.H: fatal error: returning to the gate for a mechanical issue compilation terminated.
[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 Segher Boessenkool changed: What|Removed |Added Component|target |middle-end --- Comment #10 from Segher Boessenkool --- No, this is *not* a target issue. Let's try middle-end, then.
[Bug target/105209] internal compiler error: in store_data_bypass_p_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:f8fc8a6ff7a6996fb7f12338c45d1c3450b7a397 commit r12-8499-gf8fc8a6ff7a6996fb7f12338c45d1c3450b7a397 Author: Uros Bizjak Date: Fri Jun 17 17:19:44 2022 +0200 alpha: Introduce target specific store_data_bypass_p function [PR105209] This patch introduces alpha-specific version of store_data_bypass_p that ignores TRAP_IF that would result in assertion failure (and internal compiler error) in the generic store_data_bypass_p function. While at it, also remove ev4_ist_c reservation, store_data_bypass_p can handle the patterns with multiple sets since some time ago. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105209 * config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New. * config/alpha/alpha.cc (alpha_store_data_bypass_p): New function. (alpha_store_data_bypass_p_1): Ditto. * config/alpha/ev4.md: Use alpha_store_data_bypass_p instead of generic store_data_bypass_p. (ev4_ist_c): Remove insn reservation. gcc/testsuite/ChangeLog: PR target/105209 * gcc.target/alpha/pr105209.c: New test. (cherry picked from commit cc378e655740e93743e7f43e14faaff707aef6c1)
[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105954 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-June/057939.html
[Bug c++/106029] gcc doesn't report full stack trace for static_assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106029 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-06-20 --- Comment #1 from Jonathan Wakely --- IIRC the problem is that std::optional's copy ctor is defaulted, and in such cases GCC doesn't show where a defaulted ctor is first needed. It just shows the location as the location of the class itself. There might already be a bug report about this.
[Bug c++/106029] gcc doesn't report full stack trace for static_assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106029 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80858 --- Comment #2 from Jonathan Wakely --- PR 80858 is the one I was thinking of
[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:84fe5ace4734cb0eeb342114e744455a7178b0e2 commit r11-10082-g84fe5ace4734cb0eeb342114e744455a7178b0e2 Author: Uros Bizjak Date: Fri Jun 17 17:01:31 2022 +0200 i386: Fix assert in ix86_function_arg [PR105970] The mode of pointer argument should equal ptr_mode, not Pmode. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105970 * config/i386/i386.c (ix86_function_arg): Assert that the mode of pointer argumet is equal to ptr_mode, not Pmode. gcc/testsuite/ChangeLog: PR target/105970 * gcc.target/i386/pr105970.c: New test. (cherry picked from commit 1f8278bfcfc7f7157bf2b405471e67dd5097636b)
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 --- Comment #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Sebastian Huber : https://gcc.gnu.org/g:58465d673bb21fc234f642166ec0cf9e621787c3 commit r10-10859-g58465d673bb21fc234f642166ec0cf9e621787c3 Author: Segher Boessenkool Date: Fri Mar 11 21:15:18 2022 + rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829) Fixes: 77eccbf39ed5 rs6000.h has #define PROCESSOR_POWERPC PROCESSOR_PPC604 #define PROCESSOR_POWERPC64 PROCESSOR_RS64A which means that if you use things like -mcpu=powerpc -mvsx it will no longer work after my latest .machine patch. This causes GCC build errors in some cases, not a good idea (even if the errors are actually pre-existing: using -mvsx with a machine that does not have VSX cannot work properly). 2022-03-11 Segher Boessenkool PR target/104829 * config/rs6000/rs6000.c (rs6000_machine_from_flags): Don't output "ppc" and "ppc64" based on rs6000_cpu. (cherry picked from commit 80fcc4b6afee72443bef551064826b3b4b6785e6)
[Bug c/3885] Incorrect "invalid suffix on integer constant" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Pavel M changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #15 from Pavel M --- Please add to "Duplicates" list: - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33547 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45184
[Bug preprocessor/33547] invalid suffix "+0x23" on integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33547 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 3885. *** This bug has been marked as a duplicate of bug 3885 ***
[Bug c/3885] Incorrect "invalid suffix on integer constant" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Andrew Pinski changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #16 from Andrew Pinski --- *** Bug 33547 has been marked as a duplicate of this bug. ***
[Bug c++/45184] integer lexem error-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45184 --- Comment #2 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 3885 ***
[Bug c/3885] Incorrect "invalid suffix on integer constant" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Andrew Pinski changed: What|Removed |Added CC||alt...@arts-union.ru --- Comment #17 from Andrew Pinski --- *** Bug 45184 has been marked as a duplicate of this bug. ***
[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:570a6067ff6928fe76bb13cece38346d9a966a13 commit r10-10860-g570a6067ff6928fe76bb13cece38346d9a966a13 Author: Uros Bizjak Date: Fri Jun 17 17:01:31 2022 +0200 i386: Fix assert in ix86_function_arg [PR105970] The mode of pointer argument should equal ptr_mode, not Pmode. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105970 * config/i386/i386.c (ix86_function_arg): Assert that the mode of pointer argumet is equal to ptr_mode, not Pmode. gcc/testsuite/ChangeLog: PR target/105970 * gcc.target/i386/pr105970.c: New test. (cherry picked from commit 1f8278bfcfc7f7157bf2b405471e67dd5097636b)
[Bug target/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.4 Component|c |target Resolution|--- |FIXED --- Comment #7 from Uroš Bizjak --- Fixed for gcc-10.4+
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Sebastian Huber : https://gcc.gnu.org/g:d87e0e297b1cba73a0c055d2a3e9267d288f435a commit r11-10084-gd87e0e297b1cba73a0c055d2a3e9267d288f435a Author: Segher Boessenkool Date: Fri Mar 11 21:15:18 2022 + rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829) Fixes: 77eccbf39ed5 rs6000.h has #define PROCESSOR_POWERPC PROCESSOR_PPC604 #define PROCESSOR_POWERPC64 PROCESSOR_RS64A which means that if you use things like -mcpu=powerpc -mvsx it will no longer work after my latest .machine patch. This causes GCC build errors in some cases, not a good idea (even if the errors are actually pre-existing: using -mvsx with a machine that does not have VSX cannot work properly). 2022-03-11 Segher Boessenkool PR target/104829 * config/rs6000/rs6000.c (rs6000_machine_from_flags): Don't output "ppc" and "ppc64" based on rs6000_cpu. (cherry picked from commit 80fcc4b6afee72443bef551064826b3b4b6785e6)
[Bug target/105209] internal compiler error: in store_data_bypass_p_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:380829dfd9d8a602322a7771f94616056ebbde21 commit r11-10085-g380829dfd9d8a602322a7771f94616056ebbde21 Author: Uros Bizjak Date: Fri Jun 17 17:19:44 2022 +0200 alpha: Introduce target specific store_data_bypass_p function [PR105209] This patch introduces alpha-specific version of store_data_bypass_p that ignores TRAP_IF that would result in assertion failure (and internal compiler error) in the generic store_data_bypass_p function. While at it, also remove ev4_ist_c reservation, store_data_bypass_p can handle the patterns with multiple sets since some time ago. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105209 * config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New. * config/alpha/alpha.c (alpha_store_data_bypass_p): New function. (alpha_store_data_bypass_p_1): Ditto. * config/alpha/ev4.md: Use alpha_store_data_bypass_p instead of generic store_data_bypass_p. (ev4_ist_c): Remove insn reservation. gcc/testsuite/ChangeLog: PR target/105209 * gcc.target/alpha/pr105209.c: New test. (cherry picked from commit cc378e655740e93743e7f43e14faaff707aef6c1)
[Bug target/105209] internal compiler error: in store_data_bypass_p_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:94cf9bfb4d269fa5a4e3eeda45f4eafe392bfd58 commit r10-10861-g94cf9bfb4d269fa5a4e3eeda45f4eafe392bfd58 Author: Uros Bizjak Date: Fri Jun 17 17:19:44 2022 +0200 alpha: Introduce target specific store_data_bypass_p function [PR105209] This patch introduces alpha-specific version of store_data_bypass_p that ignores TRAP_IF that would result in assertion failure (and internal compiler error) in the generic store_data_bypass_p function. While at it, also remove ev4_ist_c reservation, store_data_bypass_p can handle the patterns with multiple sets since some time ago. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105209 * config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New. * config/alpha/alpha.c (alpha_store_data_bypass_p): New function. (alpha_store_data_bypass_p_1): Ditto. * config/alpha/ev4.md: Use alpha_store_data_bypass_p instead of generic store_data_bypass_p. (ev4_ist_c): Remove insn reservation. gcc/testsuite/ChangeLog: PR target/105209 * gcc.target/alpha/pr105209.c: New test. (cherry picked from commit cc378e655740e93743e7f43e14faaff707aef6c1)
[Bug target/105209] internal compiler error: in store_data_bypass_p_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Resolution|--- |FIXED Target Milestone|--- |10.4 --- Comment #7 from Uroš Bizjak --- Fixed for gcc-10.4+
[Bug c++/105908] [12/13 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105908 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/105964] [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105964 Patrick Palka changed: What|Removed |Added Known to work||11.3.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||12.1.0, 13.0 CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2022-06-20 --- Comment #2 from Patrick Palka --- Started with r12-1270-ga1b3484a8e6c53.
[Bug gcov-profile/106036] New: Missing stdint.h include in libgcc/libgcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106036 Bug ID: 106036 Summary: Missing stdint.h include in libgcc/libgcov.h Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: kacper.slominski72 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- The libgcc/libgcov.h header (and users of it) do not include stdint.h before using int64_t and uint64_t (via typedefs in gcc/gcov-io.h). Looking a bit deeper, gcc/tsystem.h includes a bunch of libc headers but omits stdint.h, which, on glibc, gets inadvertently brought in by stdlib.h and sys/types.h, but POSIX does not specify that it needs to.
[Bug ada/106037] New: ICE with Aggregate aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037 Bug ID: 106037 Summary: ICE with Aggregate aspect Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jesper.quorning at gmail dot com Target Milestone: --- Created attachment 53174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53174&action=edit Source from Description This causes ICE with 12.1.0: procedure Container_Aggregates is type Array_Type is array (1 .. 10) of Integer with Aggregate => (Empty => Empty_Array); Empty_Array : constant Array_Type := [1..10 => 123]; begin null; end Container_Aggregates; ICE: % gnatmake -gnat2022 container_aggregates.adb gcc -c -gnat2022 container_aggregates.adb +===GNAT BUG DETECTED==+ | 12.1.0 (x86_64-apple-darwin15) Program_Error sem_type.adb:837 explicit raise| | Error detected at container_aggregates.adb:7:43 | | Compiling container_aggregates.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+
[Bug c++/106034] internal compiler error: in type_node, at cp/module.cc:8736 using --with-long-double-format=ieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106034 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 98645. *** This bug has been marked as a duplicate of bug 98645 ***
[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645 Andrew Pinski changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 106034 has been marked as a duplicate of this bug. ***
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 Andrew Pinski changed: What|Removed |Added Summary|ICE on missing template |[11/12/13 Regression] ICE |keyword in template method |on missing template keyword |call in pack expansion |in template method call in ||pack expansion Target Milestone|--- |11.4 Known to work||10.3.0 Known to fail||11.1.0
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Status|UNCONFIRMED |NEW Summary|ICE on missing template |[11/12/13 Regression] ICE |keyword in template method |on missing template keyword |call in pack expansion |in template method call in ||pack expansion Last reconfirmed||2022-06-20 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed, a regression from 10.x.
[Bug target/106038] New: x86_64 vectorization of ALU ops using xmm registers prematurely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106038 Bug ID: 106038 Summary: x86_64 vectorization of ALU ops using xmm registers prematurely Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: goldstein.w.n at gmail dot com Target Milestone: --- See: https://godbolt.org/z/YxWEn6Y65 Basically in all cases where the total amount of memory touched is <= 8 bytes (word size) the vectorization pass is choosing to inefficiently use xmm registers to vectorize the unrolled loops. GPRs (as GCC <= 9.5 was doing) is faster / less code size. Related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106038 --- Comment #1 from Andrew Pinski --- Created attachment 53175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53175&action=edit Testcase -O3 -march=icelake-client Next time attach the testcase and not link to godbolt without a testcase.
[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106038
--- Comment #2 from Noah Goldstein ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 53175 [details]
> Testcase -O3 -march=icelake-client
>
> Next time attach the testcase and not link to godbolt without a testcase.
Sorry.
I tried playing around in i386.cc to see if I could modify the `stmt_cost` for
the `BIT_{AND|IOR|XOR}_EXPR` cases but that didn't seem to have any effect. Do
you know where I might go to fix this?
[Bug c++/105999] Wrong requires result inside lambda in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105999 --- Comment #1 from Andrew Pinski --- clang prints x also
[Bug c++/105999] Wrong requires result inside lambda in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105999 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-06-21 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > clang prints x also So does MSVC. I suspect this might be defect in the standard; or maybe not as all compilers I tried agree.
[Bug c++/105999] Wrong requires result inside lambda in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105999 --- Comment #3 from Egor Pugin --- See ms response https://developercommunity.visualstudio.com/t/C-Wrong-requires-result-inside-lambd/10073268#T-N10075675
[Bug c/106039] New: Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 Bug ID: 106039 Summary: Inconsistent error reporting for printf() when format string is a macro Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- Created attachment 53176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53176&action=edit Preprocessed output The problem is inconsistent error (warning) reporting from GCC (home-built versions 8.2.0, 9.3.0, 10.3.0, 11.2.0, 12.1.0 tested on RHEL 7.4) with respect to the location of the problem. (The test case is reduced from 5600 lines and 43 headers to 26 lines with two headers. The code is thoroughly anonymized.) There is no doubt that the errors reported are correct on a 64-bit system; the problem is in the way that the location of the error is reported. The errors reported by GCC 12.1.0 (errors because of -Werror) are shown below. Other versions produce essentially the same output, though the error formatting in 8.2.0 is somewhat different. The first error correctly lists the line causing the problem (line 18) as expected and desired. The other errors do not list the line causing the problem properly. The problem is surprisingly sensitive to the format string defined by the macro and the arguments provided to the printf() call. Some of the variations which 'fix' the error reporting are mentioned in the comments in the source. Reordering the printf() statements doesn't alter which printf() statements have the inconsistent error reporting. If the format string is placed directly in the printf() statement, the line is reported correctly. Neither the optimization level (-O) nor the debugging options (-g) seem to alter the behaviour. Using -Wall enables the relevant option; using -Werror ensures that rerunning 'make' attempts to rebuild the object file. The standard specified does not seem to alter the behaviour (in either -std=cXX or -std=gnuXX formats). Adding the -save-temps option to the compilation command line (to generate the .i file as requested in the 'Reporting Bugs' page) completely alters the error messages generated, giving the correct line numbers but odd-ball highlighting of what's wrong. $ gcc -std=c99 -Werror -Wall -c gcc-bug.c gcc-bug.c: In function ‘print_lock’: gcc-bug.c:4:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long int’ [-Werror=format=] 4 | #define PRT_BR_HDR"%-16x\n" | ^ gcc-bug.c:18:12: note: in expansion of macro ‘PRT_BR_HDR’ 18 | printf(PRT_BR_HDR, (intptr_t) val1); |^~ gcc-bug.c:4:28: note: format string is defined here 4 | #define PRT_BR_HDR"%-16x\n" |^ || |unsigned int |%-16lx gcc-bug.c:5:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:23: note: in definition of macro ‘PRT_BR_LN1’ 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:34: note: format string is defined here 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ | | | unsigned int | %-16lx gcc-bug.c:5:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long int’ [-Werror=format=] 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:23: note: in definition of macro ‘PRT_BR_LN1’ 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:40: note: format string is defined here 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" |^ || |unsigned int |%-16lx gcc-bug.c:6:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long int’ [-Werror=format=] 6 | #define PRT_BR_LN2"%-12s %-8s %-16x %-16x %-18s %-18s\n" | ^~ gcc-bug.c:6:23: note: in definition of macro ‘PRT_BR_LN2’ 6 | #define PRT_BR_LN2"%-12s %-8s %-16x
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 --- Comment #1 from Jonathan Leffler --- Created attachment 53177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53177&action=edit Close to minimal source (4 format strings; 4 printf statements; some comments) Close to minimal source code. It has 4 format strings and 4 printf statements where 1 of each would be minimal. It has some comments about changes that 'fix' the error reporting.
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 --- Comment #2 from Jonathan Leffler --- Created attachment 53178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53178&action=edit Output from gcc -v when compiling the test case
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039
--- Comment #3 from Andrew Pinski ---
I don't see an issue with the diagnostic here really.
For the single line case (without the format as a macro):
printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t) val1,
(intptr_t) val1, "ABC", "DEF");
We get:
:22:23: warning: format '%x' expects argument of type 'unsigned int',
but argument 3 has type 'long int' [-Wformat=]
22 | printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t) val1,
(intptr_t) val1, "ABC", "DEF");
| ^ ~~~
| | |
| unsigned int long int
| %-16lx
:22:29: warning: format '%x' expects argument of type 'unsigned int',
but argument 4 has type 'long int' [-Wformat=]
22 | printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t) val1,
(intptr_t) val1, "ABC", "DEF");
| ^
~~~
| | |
| unsigned int
long int
| %-16lx
are you asking to point out where the arguments were for the macro case?
[Bug c++/106040] New: gcc reports error in aggregate when member has explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040
Bug ID: 106040
Summary: gcc reports error in aggregate when member has
explicit constructor
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
gcc fails to compile the following example, as it seems to be treating .i{0} as
an implicit operation rather than an explicit construction. Both clang and MSVC
accept the example.
struct foo {
explicit foo(int) {}
};
struct bar {
foo i;
};
bar x {
.i{0} // <-- error:
};
error: :11:1: error: converting to 'foo' from initializer list would
use explicit constructor 'foo::foo(int)'
live: https://godbolt.org/z/hhvnGaK6c
[Bug c++/106040] gcc reports error in aggregate when member has explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 11.1.0, 12.1.0, ||8.1.0, 9.1.0 Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- Confirmed. Not a regression
[Bug c++/106040] gcc reports error in aggregate when member has explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-21
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106038
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3 from Hongtao.liu ---
vectorizer saw 2 scalar loads + 2 bit_ops + 2 scalar stores vs 1 unaligned_load
+ 1 bit_op + 1 unaligned_store, only scale cost of bit_op doesn't help.
In rtl level, we have
205(note 3 14 4 2 NOTE_INSN_DELETED)
206(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
207(insn 7 4 8 2 (set (reg:V2QI 87 [ vect__20.19 ])
208(mem:V2QI (reg:DI 91) [0 MEM
[(const uint8_t *)b_11(D)]+0 S2 A8])) "test.c":31:1 1414 {*movv2qi_internal}
209 (expr_list:REG_DEAD (reg:DI 91)
210(nil)))
211(insn 8 7 9 2 (set (reg:V2QI 88 [ vect__18.16 ])
212(mem:V2QI (reg/v/f:DI 85 [ a ]) [0 MEM
[(uint8_t *)a_10(D)]+0 S2 A8])) "test.c":31:1 1414 {*movv2qi_internal}
213 (expr_list:REG_EQUIV (mem:V2QI (reg/v/f:DI 85 [ a ]) [0 MEM [(uint8_t *)a_10(D)]+0 S2 A8])
214(nil)))
215(insn 9 8 10 2 (parallel [
216(set (reg:V2QI 89 [ vect__21.20 ])
217(xor:V2QI (reg:V2QI 87 [ vect__20.19 ])
218(reg:V2QI 88 [ vect__18.16 ])))
219(clobber (reg:CC 17 flags))
220]) "test.c":31:1 1627 {xorv2qi3}
221 (expr_list:REG_DEAD (reg:V2QI 88 [ vect__18.16 ])
222(expr_list:REG_DEAD (reg:V2QI 87 [ vect__20.19 ])
223(expr_list:REG_UNUSED (reg:CC 17 flags)
224(expr_list:REG_EQUIV (mem:V2QI (reg/v/f:DI 85 [ a ]) [0 MEM
[(uint8_t *)a_10(D)]+0 S2 A8])
225(nil))
226(insn 10 9 0 2 (set (mem:V2QI (reg/v/f:DI 85 [ a ]) [0 MEM [(uint8_t *)a_10(D)]+0 S2 A8])
227(reg:V2QI 89 [ vect__21.20 ])) "test.c":31:1 1414
{*movv2qi_internal}
228 (expr_list:REG_DEAD (reg:V2QI 89 [ vect__21.20 ])
if RA can allocate 87/88/89 into GPRs, it would same as non-vectorized version.
[Bug tree-optimization/105990] Dead code elimination failed at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2022-06-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- I think the first and second cases are different issues. In the first case (even if we remove the struct), we can't figure out that b does not change from 0. Because we only have a trivial pass which detects read-onlyness. That is it only checks if b was read-only and not if b could have been written to if b was read-only. The second case I didn't analyzed.
[Bug ipa/105978] ICE: nodes with unreleased memory found since r9-4254-g12485662c00914ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105978 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- >-fdisable-ipa-inline This is a valid bug report. The -fdisable-* options are only for debugging and I suspect disabling the IPA inliner here is missing the free of the clone as this is what exactly the check is doing: /* Double check that all inline clones are gone and that all function bodies have been released from memory. */ Since you disable the code which will free the clones you get what you asked for.
