[Bug target/116054] RISCV: RV32: prologue/epilogue degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116054 --- Comment #4 from Alexey --- The issue because of change is https://github.com/gcc-mirror/gcc/commit/d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd But after I reverted it the result size for the real application grew a bit :)
[Bug rtl-optimization/116066] ext-dce + uncommitted LoongArch patch breaks libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116066 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Xi Ruoyao --- Indeed, it works for me. So a dup. *** This bug has been marked as a duplicate of bug 116039 ***
[Bug rtl-optimization/116039] [15 Regression] rv64gc miscompile at -O3 with -fno-strict-aliasing since r15-1901-g98914f9eba5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116039 --- Comment #5 from Xi Ruoyao --- *** Bug 116066 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/116096] [15 Regression] during RTL pass: cprop_hardreg ICE: in extract_insn, at recog.cc:2848 (unrecognizable insn ashift:TI?) with -O2 -flive-range-shrinkage -fno-peephole2 -mst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116096 --- Comment #3 from Hongtao Liu --- > > (define_insn "ashl3_doubleword" >[(set (match_operand:DWI 0 "register_operand" "=&r,&r") > - (ashift:DWI (match_operand:DWI 1 "reg_or_pm1_operand" "0n,r") > + (ashift:DWI (match_operand:DWI 1 "reg_or_pm1_operand" "0BC,r") > (match_operand:QI 2 "nonmemory_operand" "c,c"))) > (clobber (reg:CC FLAGS_REG))] >"" The patch is incomplete, it should also support integer 1 since pm1_operand means 1 or -1.
[Bug c++/115746] [C++26] P2963R3 - Ordering of constraints involving fold expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115746 Jakub Jelinek changed: What|Removed |Added Attachment #58759|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 58763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58763&action=edit gcc15-pr115746-wip.patch Updated patch which handles satisfy_atom by modifying (a copy of) args instead of the old way, plus removes the pack tree from in between FOLD_CONSTR and the actual constraint. Sadly, this fixed only diagnostic3.C, but not the rest: FAIL: g++.dg/cpp26/fold-constr3.C -std=c++26 (internal compiler error: in dependent_type_p, at cp/pt.cc:28060) FAIL: g++.dg/cpp26/fold-constr3.C -std=c++26 (test for errors, line 10) FAIL: g++.dg/cpp26/fold-constr3.C -std=c++26 (test for errors, line 14) FAIL: g++.dg/cpp26/fold-constr3.C -std=c++26 (test for excess errors) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 13) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 19) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 20) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 21) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 23) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 28) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 29) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 30) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 32) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 37) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 38) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 39) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 41) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 47) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 51) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 56) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 60) FAIL: g++.dg/cpp26/fold-constr5.C -std=c++26 (test for errors, line 65) FAIL: g++.dg/cpp26/fold-constr6.C -std=c++26 (test for errors, line 20)
[Bug target/116103] New: [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116103
Bug ID: 116103
Summary: [15 Regression] GCN vs. "Internal-fn: Only allow modes
describe types for internal fn[PR115961]"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, pan2.li at intel dot com
Target Milestone: ---
Target: GCN
With recent commit r15-2241-g905973410957891fec8a3e42eeefa4618780e0ce
"Internal-fn: Only allow modes describe types for internal fn[PR115961]", we've
got a few regressions for '--target=amdgcn-amdhsa' (tested '-march=gfx908').
>From a quick glance, I can't tell if this is worse or just different code
generation. (Andrew?)
PASS: gcc.dg/tree-ssa/loop-bound-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
PASS: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump-not ivopts "bounded by
255"
[-PASS:-]{+FAIL:+} gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump-not ivopts
"zero if "
Note that 'scan-tree-dump ivopts "bounded by 254"' already did FAIL before, but
the FAIL of 'scan-tree-dump-not ivopts "zero if "' is new:
--- G/loop-bound-2.c.188t.ivopts2024-07-26 09:34:22.838958365 +0200
+++ B/loop-bound-2.c.188t.ivopts2024-07-26 09:47:10.822525365 +0200
@@ -5,15 +5,22 @@
;; Loop 1
;; header 3, latch 6
;; depth 1, outer 0, finite_p
-;; niter scev_not_known
+;; niter (unsigned short) bnd.8_23 + 63 > 63 ? ((unsigned short) bnd.8_23
+ 65535) / 64 : 0
;; upper_bound 3
;; likely_upper_bound 3
;; iterations by profile: 3.00 (unreliable) entry count:105119324
(estimated locally, freq 0.8900)
;; nodes: 3 6
Processing loop 1 at
source-gcc/gcc/testsuite/gcc.dg/tree-ssa/loop-bound-2.c:14
- single exit 3 -> 8, exit condition if (next_mask_38 != { 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0 })
+ single exit 3 -> 8, exit condition if (ivtmp_35 > 64)
+Analyzing # of iterations of loop 1
+ exit condition 64 < [(unsigned short) bnd.8_23, + , 65472]
+ bounds on difference of bases: -64 ... 65471
+ result:
+zero if (unsigned short) bnd.8_23 + 63 <= 63
+# of iterations ((unsigned short) bnd.8_23 + 65535) / 64, bounded by
1023
+ number of iterations ((unsigned short) bnd.8_23 + 65535) / 64; zero if
(unsigned short) bnd.8_23 + 63 <= 63
[...]
And then, a number of regressions of 'scan-assembler-times
\\tv_cmp_gt_i32\\tvcc, [...]' and 'scan-assembler-times \\tv_cmpx_gt_i32\\tvcc,
[...]':
@@ -125843,7 +125901,7 @@ PASS: gcc.target/gcn/cond_smax_1.c
scan-assembler-not \\ts_cmpk_lg_u32\\tvcc_lo,
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-not
\\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-not
\\tv_writelane_b32\\tv[0-9]+, vcc_??, 0
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-not smaxv64si3/0
[-PASS:-]{+FAIL:+} gcc.target/gcn/cond_smax_1.c scan-assembler-times
\\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-times
\\tv_cmp_gt_i64\\tvcc, v[[0-9]+:[0-9]+], v[[0-9]+:[0-9]+] 10
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-times
\\tv_cmp_ne_u64\\ts\\[[0-9]+:[0-9]+\\], v\\[[0-9]+:[0-9]+\\], -1 10
PASS: gcc.target/gcn/cond_smax_1.c scan-assembler-times smaxv64si3_exec 30
@@ -125854,7 +125912,7 @@ PASS: gcc.target/gcn/cond_smin_1.c
scan-assembler-not \\ts_cmpk_lg_u32\\tvcc_lo,
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-not
\\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-not
\\tv_writelane_b32\\tv[0-9]+, vcc_??, 0
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-not sminv64si3/0
[-PASS:-]{+FAIL:+} gcc.target/gcn/cond_smin_1.c scan-assembler-times
\\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-times
\\tv_cmp_lt_i64\\tvcc, v[[0-9]+:[0-9]+], v[[0-9]+:[0-9]+] 10
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-times
\\tv_cmp_ne_u64\\ts\\[[0-9]+:[0-9]+\\], v\\[[0-9]+:[0-9]+\\], -1 10
PASS: gcc.target/gcn/cond_smin_1.c scan-assembler-times sminv64si3_exec 30
@@ -125864,7 +125922,7 @@ PASS: gcc.target/gcn/cond_umax_1.c (test for
excess errors)
PASS: gcc.target/gcn/cond_umax_1.c scan-assembler-not
\\ts_cmpk_lg_u32\\tvcc_lo, 0
PASS: gcc.target/gcn/cond_umax_1.c scan-assembler-not
\\tv_writelane_b32\\tv[0-9]+, vcc_??, 0
PASS: gcc.target/gcn/cond_umax_1.c scan-assembler-not umaxv64si3/0
[-PASS:-]{+FAIL:+} gcc.t
[Bug fortran/79685] [12/13/14/15 Regression] ICE on valid code in gfc_match_structur_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79685 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #16 from Paul Thomas --- Created attachment 58764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58764&action=edit Fix for this PR Lot's of checking needed now: (i) To understand why this fix is necessary here; and (ii) To see what else, if anything, that the patch fixes. Paul
[Bug target/116104] New: [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116104 Bug ID: 116104 Summary: [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce" Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build, ice-checking Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, law at gcc dot gnu.org Target Milestone: --- Target: GCN As of recent PR116037 commit r15-2275-g679086172b84be18c55fdbb9cda7e97806e7c083 "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce", '--target=amdgcn-amdhsa' ICEs during build of GCC target libraries. I can't tell if this is an issue in 'RTL pass: ext_dce' or in the GCN back end. (This isn't fixed by subsequent the commit r15-2321-g34fb0feca71f763b2fbe832548749666d34a4a76 "[PR rtl-optimization/116039] Fix life computation for promoted subregs".) during RTL pass: ext_dce [...]/source-gcc/libgcc/libgcc2.c: In function ‘__negti2’: [...]/source-gcc/libgcc/libgcc2.c:71:1: internal compiler error: RTL check: expected code 'const_int', have 'const_vector' in carry_backpropagate, at ext-dce.cc:497 71 | } | ^ 0x20f9815 internal_error(char const*, ...) [...]/source-gcc/gcc/diagnostic-global-context.cc:491 0x86460a rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) [...]/source-gcc/gcc/rtl.cc:770 0xa52e15 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:497 0x1dfbb46 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:659 0x1dfbb46 ext_dce_process_uses [...]/source-gcc/gcc/ext-dce.cc:679 0x1dfc825 ext_dce_process_bb [...]/source-gcc/gcc/ext-dce.cc:836 0x1dfc825 ext_dce_rd_transfer_n [...]/source-gcc/gcc/ext-dce.cc:978 0xcb6f5e df_worklist_propagate_backward [...]/source-gcc/gcc/df-core.cc:970 0xcb6f5e df_worklist_dataflow_doublequeue [...]/source-gcc/gcc/df-core.cc:1054 0xcb6f5e df_worklist_dataflow(dataflow*, bitmap_head*, int*, int) [...]/source-gcc/gcc/df-core.cc:1132 0x1dfcd67 ext_dce_execute() [...]/source-gcc/gcc/ext-dce.cc:1007 0x1dfd0fc execute [...]/source-gcc/gcc/ext-dce.cc:1047 during RTL pass: ext_dce [...]/source-gcc/libgcc/libgcc2.c: In function ‘__popcountti2’: [...]/source-gcc/libgcc/libgcc2.c:870:1: internal compiler error: RTL check: expected code 'const_int', have 'const_vector' in carry_backpropagate, at ext-dce.cc:505 870 | } | ^ 0x20f9815 internal_error(char const*, ...) [...]/source-gcc/gcc/diagnostic-global-context.cc:491 0x86460a rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) [...]/source-gcc/gcc/rtl.cc:770 0xa52d63 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:505 0x1dfbb46 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:659 [...] during RTL pass: ext_dce [...]/source-gcc/libgcc/libgcc2.c: In function ‘__udivti3’: [...]/source-gcc/libgcc/libgcc2.c:1301:1: internal compiler error: RTL check: expected code 'const_int', have 'const_vector' in carry_backpropagate, at ext-dce.cc:497 1301 | } | ^ 0x20f9815 internal_error(char const*, ...) [...]/source-gcc/gcc/diagnostic-global-context.cc:491 0x86460a rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) [...]/source-gcc/gcc/rtl.cc:770 0xa52e15 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:497 0x1dfbb46 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:659 [...] during RTL pass: ext_dce [...]/source-gcc/libgcc/libgcc2.c: In function ‘__udivmodti4’: [...]/source-gcc/libgcc/libgcc2.c:1205:1: internal compiler error: RTL check: expected code 'const_int', have 'const_vector' in carry_backpropagate, at ext-dce.cc:497 1205 | } | ^ 0x20f9815 internal_error(char const*, ...) [...]/source-gcc/gcc/diagnostic-global-context.cc:491 0x86460a rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) [...]/source-gcc/gcc/rtl.cc:770 0xa52e15 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:497 0x1dfbb46 carry_backpropagate(unsigned long, rtx_code, rtx_def*) [...]/source-gcc/gcc/ext-dce.cc:659 [...] duri
[Bug c++/115403] [15 Regression] highway build from git fails with 'target specific option mismatch' (templates) since r15-902-geff00046409a72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403 --- Comment #7 from Sergei Trofimovich --- The change fixed highway build for me as well. Thank you!
[Bug ipa/116055] [14/15 Regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after "Fix modref's iteraction with store merging"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116055 --- Comment #5 from Thomas Schwinge --- (In reply to Jan Hubicka from comment #4) > * ipa-modref.cc (analyze_function): Do not ICE when flags regress. > Does it help? Yes, confirming this does resolve the issue for GCN.
[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116104 Sam James changed: What|Removed |Added Last reconfirmed||2024-07-26 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c/116105] New: ESP32 error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116105
Bug ID: 116105
Summary: ESP32 error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: charantiruvuri99 at gmail dot com
Target Milestone: ---
Created attachment 58765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58765&action=edit
I am making MPPT based solar charge controller using ESP32. I got this error
when I tried to compile the project in Arduino IDE where I need to operate the
LCD parameters using buttons. The output mus
C:\Users\chara\OneDrive\Documents\Arduino\FUGU-ARDUINO-MPPT-FIRMWARE-main\FUGU-ARDUINO-MPPT-FIRMWARE-main\ARDUINO_MPPT_FIRMWARE_V1.1\8_LCD_Menu.ino:
In function 'void LCD_Menu()':
8_LCD_Menu:554:6: error: insn does not satisfy its constraints:
554 | } }
| ^
(insn 11 4070 1574 179 (set (reg:SF 19 f0 [orig:139 _108 ] [139])
(mem/u/c:SF (symbol_ref/u:SI ("*.LC425") [flags 0x2]) [0 S4 A32]))
"C:\Users\chara\OneDrive\Documents\Arduino\FUGU-ARDUINO-MPPT-FIRMWARE-main\FUGU-ARDUINO-MPPT-FIRMWARE-main\ARDUINO_MPPT_FIRMWARE_V1.1\8_LCD_Menu.ino":289:33
49 {movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 0.0 [0x0.0p+0])
(nil)))
during RTL pass: postreload
C:\Users\chara\OneDrive\Documents\Arduino\FUGU-ARDUINO-MPPT-FIRMWARE-main\FUGU-ARDUINO-MPPT-FIRMWARE-main\ARDUINO_MPPT_FIRMWARE_V1.1\8_LCD_Menu.ino:554:6:
internal compiler error: in extract_constrain_insn, at recog.cc:2692
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116103
--- Comment #1 from Thomas Schwinge ---
Similarly for '-march=gfx908':
(In reply to myself from comment #0)
> [-PASS:-]{+FAIL:+} gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump-not
> ivopts "zero if "
..., and:
> [-PASS:-]{+FAIL:+} gcc.target/gcn/cond_smax_1.c scan-assembler-times
> \\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
> [-PASS:-]{+FAIL:+} gcc.target/gcn/cond_smin_1.c scan-assembler-times
> \\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
> [-PASS:-]{+FAIL:+} gcc.target/gcn/cond_umax_1.c scan-assembler-times
> \\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 56
> [-PASS:-]{+FAIL:+} gcc.target/gcn/cond_umin_1.c scan-assembler-times
> \\tv_cmp_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 56
..., but not the following ones:
> [-PASS:-]{+FAIL:+} gcc.target/gcn/smax_1.c scan-assembler-times
> \\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
> [-PASS:-]{+FAIL:+} gcc.target/gcn/smin_1.c scan-assembler-times
> \\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 80
> [-PASS:-]{+FAIL:+} gcc.target/gcn/umax_1.c scan-assembler-times
> \\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 56
> [-PASS:-]{+FAIL:+} gcc.target/gcn/umin_1.c scan-assembler-times
> \\tv_cmpx_gt_i32\\tvcc, s[0-9]+, v[0-9]+ 56
..., as these already did FAIL before (for '-march=gfx1030', '-march=gfx1100').
[Bug c++/116106] New: Unused concept template arguments not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116106
Bug ID: 116106
Summary: Unused concept template arguments not checked
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, jason at gcc dot
gnu.org,
ppalka at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 115746
Blocks: 110338
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #115746 +++
template concept C = true;
template requires (C)
constexpr bool foo () { return true; };
static_assert (foo ());
is incorrectly accepted by GCC with -std=c++20 or higher, while clang rejects
that.
Similarly
template concept A = true;
template concept B = B && true;
template requires (B)
constexpr bool bar () { return true; };
static_assert (bar ());
Jonathan mentions http://eel.is/c++draft/temp.constr.atomic#3.sentence-2
I bet this is because we see the concepts not actually using any template
arguments (or at least not using the argument to which typename T::type is
passed if it was modified to depend on another template parameter), so create a
NULL mapping (or one where T is not mentioned) and then when using the concept
don't add that mapping even when unused.
I guess it doesn't have to be added in the trivial and most common case where
just some other template parameter is passed to the concept, but if it is
something more complex like in this case it probably needs to be added.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
[Bug 110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115746
[Bug 115746] [C++26] P2963R3 - Ordering of constraints involving fold
expressions
[Bug c++/115746] [C++26] P2963R3 - Ordering of constraints involving fold expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115746 --- Comment #5 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #3) > BTW, with a modified version of fold-constr5.C which doesn't involve any > fold expanded constraints: I've filed PR116106 for that case as well as fold-constr5.C in the patch, which suffers from the same issue.
[Bug c++/116106] Unused concept template arguments not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116106 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||accepts-invalid Last reconfirmed||2024-07-26
[Bug target/116088] Solaris i386 - some GCC tests fails with: internal compiler error: Illegal Instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116088 --- Comment #12 from Sam James --- You're very welcome. Cheers!
[Bug target/116086] RISC-V: Hash mismatch with vectorized 557.xz_r at zvl128b and LMUL=m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116086 --- Comment #6 from Robin Dapp --- Ah, thanks for reducing. I didn't get much further with cvise yesterday. What were your settings for it? The reduced test case is great because it is easy to analyze and uncovers a fairly significant problem. However, I think it's not the same bug as in the original test case. After applying my fix the reduced test case works but I'm still seeing wrong code in the original test case. Going to test my fix and will try to post a patch later if successful. Maybe that will help cvise to not take the wrong turn.
[Bug libstdc++/69350] Don't define the C99 functions in -std=c++98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69350 --- Comment #3 from Jonathan Wakely --- I'm inclined to close this one as WONTFIX. We should fix PR 11196 but I don't really care about this C++98 non-conformance now, and we've been doing it this way since before C++11 was even a thing. Defining those functions before C++11 is not the same as dumping a load of totally non-standard GNU extensions into the global namespace.
[Bug ipa/115815] [13/14/15 Regression] ICE: in purge_all_uses, at ipa-param-manipulation.cc:632 with -O2 -flto and incorrect usage of attribute destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Martin Jambor --- I have proposed a fix on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6a5i4bc6k@virgil.suse.cz/T/#u
[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116103 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #2 from Richard Biener --- Cross-checking with AVX512 would also be useful. I think it might fail vector (4) which has QImode. So + if (VECTOR_TYPE_P (type)) +return VECTOR_MODE_P (TYPE_MODE (type)); needs a prior special case for VECTOR_BOOLEAN_TYPE_P (type) I think, maybe if (VECTOR_BOOLEAN_TYPE_P (type) && SCALAR_INT_MODE_P (TYPE_MODE (type))) return true; OTOH for emulated vectors with integer modes that would get false positives. So maybe in addition to that && TYPE_PRECISION (TREE_TYPE (type)) == 1 to only allow integer mode mask "vector modes" for single-bit bool vectors. Thomas, does that resolve the issue?
[Bug target/116104] [15 Regression] GCN vs. "[rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116104 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug libstdc++/60491] Macros defined in sys/sysmacros.h pulled in by even in -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=51749 Resolution|DUPLICATE |WORKSFORME --- Comment #2 from Jonathan Wakely --- This is fixed now thanks to glibc changes. is no longer included by other glibc headers.
[Bug target/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 --- Comment #10 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:29e4e4bdb674118b898d50ce7751c183aa0a44ee commit r15-2336-g29e4e4bdb674118b898d50ce7751c183aa0a44ee Author: Tamar Christina Date: Fri Jul 26 13:02:53 2024 +0100 middle-end: check for vector mode before calling get_mask_mode [PR116074] For historical reasons AArch64 has TI mode vector types but does not consider TImode a vector mode. What's happening in the PR is that get_vectype_for_scalar_type is returning vector(1) TImode for a TImode scalar. This then fails when we call targetm.vectorize.get_mask_mode (vecmode).exists (&) on the TYPE_MODE. This checks for vector mode before using the results of get_vectype_for_scalar_type. gcc/ChangeLog: PR target/116074 * tree-vect-patterns.cc (vect_recog_cond_store_pattern): Check vector mode. gcc/testsuite/ChangeLog: PR target/116074 * g++.target/aarch64/pr116074.C: New test.
[Bug target/116105] ESP32 error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116105 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-07-26 Target||avr Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Component|c |target --- Comment #1 from Richard Biener --- What version of GCC are you using? What is the GCC command-line?
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 116074, which changed state. Bug 116074 Summary: [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Tamar Christina --- Fixed, thanks for report.
[Bug libstdc++/78483] Error: reference to 'on_exit' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78483 --- Comment #6 from Jonathan Wakely --- FWIW Glibc defines this with _DEFAULT_SOURCE and _GNU_SOURCE: #ifdef __USE_MISC /* Register a function to be called with the status given to `exit' and the given argument. */ extern int on_exit (void (*__func) (int __status, void *__arg), void *__arg) __THROW __nonnull ((1)); #endif I don't know the origin of this function, it doesn't seem to be in BSD or SVR4.
[Bug libstdc++/60491] Macros defined in sys/sysmacros.h pulled in by even in -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491 Jonathan Wakely changed: What|Removed |Added CC||zhouyan at me dot com --- Comment #3 from Jonathan Wakely --- *** Bug 78920 has been marked as a duplicate of this bug. ***
[Bug libstdc++/78920] libstdc++ defines a macro named "major"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78920 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11196 --- Comment #4 from Jonathan Wakely --- This has been fixed by glibc changes, so that is no longer included by other headers. *** This bug has been marked as a duplicate of bug 60491 ***
[Bug libstdc++/57582] clone is effectively reserved by and should not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57582 --- Comment #2 from Jonathan Wakely --- N.B. using `class clone*` to refer to the type works. This is the same as needing to use `struct stat` to disambiguate the type from the function. If we stop defining _GNU_SOURCE that workaround wouldn't be needed.
[Bug middle-end/116107] New: [OpenMP] Array-section mapping with 'declare target' link accesses the wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116107
Bug ID: 116107
Summary: [OpenMP] Array-section mapping with 'declare target'
link accesses the wrong data
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
See also PR 115559 – which contains a Fortran testcase.
The problem is that the map does:
#pragma omp target enter data map(to:arr[5] [len: 40])
and stores the resulting memory address on the device side. But it should store
it with the offset of -sizeof(arr[0])*5 bytes to ensure that arr[5] on the
device side accesses the right element …
* * *
int arr[15] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
#pragma omp declare target link(arr)
#pragma omp begin declare target
void f(int *res)
{
__builtin_memcpy (res, &arr[5], sizeof(int)*10);
}
#pragma omp end declare target
int main()
{
int res[10], res2;
#pragma omp target enter data map(arr[5:10])
#pragma omp target map(from:res)
f(res);
for (int i = 0; i < 10; i++)
__builtin_printf("%d\n", res[i]);
#pragma omp target map(from:res2)
res2 = arr[5];
__builtin_printf("res2 = %d\n", res2);
}
[Bug c++/116108] New: GCC crashes on incorrect code with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116108
Bug ID: 116108
Summary: GCC crashes on incorrect code with -std=c++20
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: q1210081098 at gmail dot com
Target Milestone: ---
Reproducer: https://gcc.godbolt.org/z/37KzjK5T7
```cpp
#include
namespace std
{
template
class size_t_class {
public:
typedef std::uintptr value_type;
const size_t_class value = 1;
constexpr bool operator == (size_t_class u) const { return true; }
template constexpr operator U()
{
return static_cast(value);
}
};
}
struct Point3 {
std::size_t_class x = 0;
std::size_t_class y = 0;
};
int main() {
Point3 p = {4, std::size_t_class{2}};
p.x = 10;
return p.y<<'\n' ;
}
```
and get the error information
```
:7:22: error: 'uintptr' in namespace 'std' does not name a type
7 | typedef std::uintptr value_type;
| ^~~
:18:5: error: invalid use of template-name 'std::size_t_class' without
an argument list
18 | std::size_t_class x = 0;
| ^~~
:19:5: error: invalid use of template-name 'std::size_t_class' without
an argument list
19 | std::size_t_class y = 0;
| ^~~
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug c++/116106] Unused concept template arguments not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116106 --- Comment #1 from Andrew Pinski --- Hmm https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975#c2 suggests gcc is correct.
[Bug c++/116106] Unused concept template arguments not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116106
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Patrick Palka ---
> I bet this is because we see the concepts not actually using any template
> arguments (or at least not using the argument to which typename T::type is
> passed if it was modified to depend on another template parameter), so create
> a NULL mapping (or one where T is not mentioned) and then when using the
> concept don't add that mapping even when unused.
Exactly, so substitution into 'typename T::type' never occurs. I think we're
behaving correctly here according to the standard and it's other compilers that
aren't following the standard precisely. There's an open PR about this
PR102419.
A workaround is to make the concept trivially depend on the template parameter,
e.g.
concept C = requires { typename T; };
*** This bug has been marked as a duplicate of bug 102419 ***
[Bug c++/102419] [12/13/14/15 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419 Patrick Palka changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Patrick Palka --- *** Bug 116106 has been marked as a duplicate of this bug. ***
[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975 Patrick Palka changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #6 from Patrick Palka --- *** This bug has been marked as a duplicate of bug 102419 ***
[Bug c++/102419] [12/13/14/15 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419 Patrick Palka changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #13 from Patrick Palka --- *** Bug 102975 has been marked as a duplicate of this bug. ***
[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116103 --- Comment #3 from Li Pan --- Thanks Richard for the suggestion. Hi Thomas, could you please help to insight me the best practice of cross compile gfx908 in x86 linux? Then I can have a try following Richard's suggestion.
[Bug ipa/116055] [14/15 Regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after "Fix modref's iteraction with store merging"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116055 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #6 from Richard Biener --- So please fix on trunk and the branch! Thanks!
[Bug ipa/105690] [12/13/14/15 regression] -Warray-bounds sensitive false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug tree-optimization/108860] [12/13/14/15 regression] New (since gcc 12) false positive null-dereference in vector.resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108860 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug c++/109648] [13/14/15 Regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 since r13-272-gdc6c96f0707aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/109561] [12/13/14/15 regression] -Wmaybe-uninitialized false positive with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109561 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug middle-end/109856] [13/14/15 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/110645] [12/13/14/15 regression] False positive -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110645 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug target/111064] [13/14/15 regression] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2 Summary|[14/15 regression] 5-10%|[13/14/15 regression] 5-10% |regression of parest on |regression of parest on |icelake between |icelake between |g:d073e2d75d9ed492de9a8dc69 |g:d073e2d75d9ed492de9a8dc69 |70e5b69fae20e5a (Aug 15 |70e5b69fae20e5a (Aug 15 |2023) and |2023) and |g:9ade70bb86c8744f4416a48bb |g:9ade70bb86c8744f4416a48bb |69cf4705f00905a (Aug 16)|69cf4705f00905a (Aug 16)
[Bug target/111064] [13/14/15 regression] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064 Richard Biener changed: What|Removed |Added Target Milestone|14.2|13.4
[Bug middle-end/111552] [13/14/15 regression] 549.fotonik3d_r regression with -O2 -flto -march=native on zen between g:85d613da341b7630 (2022-06-21 15:51) and g:ecd11acacd6be57a (2022-07-01 16:07)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111552 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug rtl-optimization/114243] [13/14/15 Regression][avr] -fsplit-wide-types bloats code by more than 50%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/114253] [12/13/14/15 regression] False positive maybe-uninitialized with std::optional and ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5 CC||jamborm at gcc dot gnu.org --- Comment #7 from Richard Biener --- Looks like SRAs fault.
[Bug tree-optimization/114360] [12/13/14/15 regression] Bogus -Wmaybe-uninitialized inside std::map internals with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114360 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug tree-optimization/114385] [12/13/14/15 regression] -Wrestrict false positive creating std::string from iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug tree-optimization/114430] [12/13/14/15 regression] False positive for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114430 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug tree-optimization/114622] [12/13/14/15 regression] memcmp -Wstringop-overread false positive with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug tree-optimization/114592] [12/13/14/15 regression] Bogus `maybe-uninitialized` on std::variant with std::string with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114592 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug libbacktrace/114941] [14/15 regression] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2
[Bug fortran/115348] [13/14/15 Regression] -fcheck=recursion issue with intent(out) derived type argument without components with default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115348 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/114789] [12/13/14 regression] False positive -Wmaybe-uninitialized at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114789 Richard Biener changed: What|Removed |Added Known to work||15.0 Target Milestone|--- |12.5
[Bug ipa/115135] [12/13/14/15 regression] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants since r12-5113-gd70ef65692fced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug middle-end/115489] [12/13/14/15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589 since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115489 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |12.5
[Bug target/116085] [13/14/15 Regression] RISC-V: Miscompile at -O2 with zbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116085 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug c/109618] [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109618 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/109648] [13/14/15 Regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 since r13-272-gdc6c96f0707aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/111606] [12/13/14/15 Regression] [ICE] internal compiler error: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111606 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-07-26
Ever confirmed|0 |1
--- Comment #10 from Richard Biener ---
For this testcase the issue is that we value-number
_1 = *x_32(D);
..
_41 = MEM [(char * {ref-all})x_32(D)];
the same:
Value numbering stmt = _1 = *x_32(D);
Setting value number of _1 to _1 (changed)
...
Value numbering stmt = _41 = MEM [(char * {ref-all})x_32(D)];
Inserting name _50 for expression VIEW_CONVERT_EXPR(_1)
Setting value number of _41 to _50 (changed)
We already have mitigation of some of this for code hoisting but did not
yet disable all FP<->int punning since this was explicitly introduced
for optimization and there's currently no way to query the target whether
a FP load is not bit-representation preserving. I'm not sure if we can
look at the hardreg for the FP mode in question and decide based on its mode
for example.
The following fixes this. But I really think we need a target hook to avoid
pessimizing all targets.
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 0139f1b4e30..62f3de11b56 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -5825,6 +5825,13 @@ visit_reference_op_load (tree lhs, tree op, gimple
*stmt)
result = NULL_TREE;
else if (CONSTANT_CLASS_P (result))
result = const_unop (VIEW_CONVERT_EXPR, TREE_TYPE (op), result);
+ /* Do not treat a float-mode load as preserving the bit
+representation. See PR114659, on for x87 FP modes there
+is no load instruction that does not at least turn sNaNs
+into qNaNs. But allow the case of a constant FP value we an
+fold above. */
+ else if (SCALAR_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (result
+ result = NULL_TREE;
else
{
/* We will be setting the value number of lhs to the value number
For example gcc.dg/tree-ssa/ssa-fre-7.c explicitly tests for this transform,
so the patch regresses quite a few testcases.
[Bug libbacktrace/114941] [14/15 regression] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 Sam James changed: What|Removed |Added Keywords||build --- Comment #5 from Sam James --- r14-9655-gc2e68ff9edd5da and r15-2051-gc6803cdaba7a7b fixed this, I assume? Is this broken for just 14 or is it fixed for both 14+15 now?
[Bug libbacktrace/114941] [14/15 regression] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 --- Comment #6 from jcmvbkbc at gcc dot gnu.org --- This is fixed in master by r15-2051-gc6803cdaba7a + r15-2082-gf438299ef686
[Bug libbacktrace/114941] [14 regression] libbacktrace build is broken for FDPIC uclibc targets by r14-5173-g2b64e4a54042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941 Sam James changed: What|Removed |Added Summary|[14/15 regression] |[14 regression] |libbacktrace build is |libbacktrace build is |broken for FDPIC uclibc |broken for FDPIC uclibc |targets by |targets by |r14-5173-g2b64e4a54042 |r14-5173-g2b64e4a54042 Last reconfirmed||2024-07-26 Status|UNCONFIRMED |NEW CC||sjames at gcc dot gnu.org Ever confirmed|0 |1 Known to work||15.0
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to Richard Biener from comment #10) > I'm not sure if we can > look at the hardreg for the FP mode in question and decide based on its mode > for example. I think not just the mode, but would need to look at the targetm.c.excess_precision and whether the mode it promotes to has any padding bits or something similar. Though, I'm afraid targetm.c.excess_precision reflects mostly what the FEs should do, rather than what the hw instructions do with the mode, so maybe it would be better to have a target hook which says for a floating point scalar mode whether moves using it preserve all bits or not, default to yes (I think that is the behavior on most of the arches) and deal with the exceptions (i?86, ia64, m68k, what else). Are there some other targets which say canonicalize NaNs on simple moves?
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659 --- Comment #12 from Bruno Haible --- (In reply to Jakub Jelinek from comment #11) > Are there some other targets which say canonicalize NaNs on simple moves? No, it's only the flds, fldl, fldt instructions on x86 and x86_64. In my testing on other architectures, from m68k to loongarch64, I did not encounter this problem anywhere else.
[Bug ipa/105690] [12/13/14/15 regression] -Warray-bounds sensitive false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690 --- Comment #4 from Franz Sirl --- The testcode started to fail with the backwards jump threader rewrite in r12-2591-g2e96b5f14e4025691b57d2301d71aa6092ed44bc and a simple -Warray-bounds. This is proven by the fact that compiling the testcase with gcc@r12-2591 with an additional --param=threader-mode=legacy makes the warning go away. So this bug maybe a duplicate of the other bugs (couldn't find a metabug) related to r12-2591. PS: It seems I wrongly added this comment to PR 110458 before :-(.
[Bug tree-optimization/110458] [14/15 Regression] -Warray-bounds=2 new false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458 --- Comment #5 from Franz Sirl --- I wrongly added c#3 here, should have been PR 105690, sorry!
[Bug tree-optimization/110458] [14/15 Regression] -Warray-bounds=2 new false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #6 from Sam James --- Tidied, thanks!
[Bug tree-optimization/116109] New: Missed optimisation: unnecessary register dependency on reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116109 Bug ID: 116109 Summary: Missed optimisation: unnecessary register dependency on reduction Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mjr19 at cam dot ac.uk Target Milestone: --- With a loop such as function mod2(x,n) real(kind(1d0))::mod2,x(*),t integer::i,n t=0 !$omp simd reduction(+:t) do i=1,n t=t+x(i)*x(i) end do mod2=t end function mod2 compiled with -O3 -mavx2 -mfma -fopenmp code similar to .L8: vmovupd (%rax), %ymm2 addq$32, %rax vfmadd231pd %ymm2, %ymm2, %ymm0 cmpq%rax, %rcx jne .L8 is produced (the above is actually gfortran-13). The corresponding C code behaves identically. As each fma depends on the previous fma, this executes in a single fma unit at one result per the unit's latency. gfortran-14 splits the fma into separate mul and add, which then executes at the rate of one instruction per add latency, which, on older processors, beats one instruction per fma latency. Adding -funroll-loops --param max-unroll-times=2 gives no performance improvement, and .L8: vmovupd (%rax), %ymm6 vmovupd 32(%rax), %ymm7 addq$64, %rax vfmadd231pd %ymm6, %ymm6, %ymm5 vfmadd231pd %ymm7, %ymm7, %ymm5 cmpq%rax, %r11 jne .L8 changing this to vxorpd %xmm8, %xmm8, %xmm8 .L8: vmovupd (%rax), %ymm6 vmovupd 32(%rax), %ymm7 addq$64, %rax vfmadd231pd %ymm6, %ymm6, %ymm5 vfmadd231pd %ymm7, %ymm7, %ymm8 cmpq%rax, %r11 jne .L8 vaddpd %ymm8, %ymm5, %ymm5 runs twice as fast, as the two fmas in the loop are now independent of each other. For full performance one might want six or more, as the latency of an FMA unit is typically 3-5 cycles, and most processors have two. I think that both OMP simd reduction(+:) and -Ofast should permit this rearrangement, which is equivalent to simulating vector registers of double the existing width?
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #13 from Alexander Monakov --- fldt does not convert (otherwise there's no way to spill/reload x87 registers).
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659 --- Comment #14 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #13) > fldt does not convert (otherwise there's no way to spill/reload x87 > registers). Doesn't it still misbehave say on pseudo denormals, pseudo infinities, pseudo normals, pseudo NaNs etc.? And even if not, it still contains padding bits, as it loads 10 bytes rather than 12 or 16 it occupies in memory.
[Bug fortran/50410] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #54 from Paul Thomas --- > I've removed the other part that tries to detect the double initialization. > I think this is the wrong place as is would not detect e.g. the following: > > program p > type t > integer :: g > end type t > type(t) :: u > data u /t(3)/ > data u%g /2/ > end > > A better-suited place is probably the loop in gfc_assign_data_value, but > find_con_by_component seems not to be able to handle the current situation. For some reason that I cannot see, 'init' is disappearing for this case and so the attempt to update 'u' is silently passed over. This is the same behaviour as ifort, whereas nagfor throws "Error: pr50410.f90, line 8: U has already been completely initialised". This is heading towards a WONTFIX :-( Paul
[Bug fortran/50410] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #55 from Paul Thomas --- > I've removed the other part that tries to detect the double initialization. > I think this is the wrong place as is would not detect e.g. the following: > > program p > type t > integer :: g > end type t > type(t) :: u > data u /t(3)/ > data u%g /2/ > end > > A better-suited place is probably the loop in gfc_assign_data_value, but > find_con_by_component seems not to be able to handle the current situation. For some reason that I cannot see, 'init' is disappearing for this case and so the attempt to update 'u' is silently passed over. This is the same behaviour as ifort, whereas nagfor throws "Error: pr50410.f90, line 8: U has already been completely initialised". This is heading towards a WONTFIX :-( Paul
[Bug fortran/50410] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #56 from Paul Thomas --- > I've removed the other part that tries to detect the double initialization. > I think this is the wrong place as is would not detect e.g. the following: > > program p > type t > integer :: g > end type t > type(t) :: u > data u /t(3)/ > data u%g /2/ > end > > A better-suited place is probably the loop in gfc_assign_data_value, but > find_con_by_component seems not to be able to handle the current situation. For some reason that I cannot see, 'init' is disappearing for this case and so the attempt to update 'u' is silently passed over. This is the same behaviour as ifort, whereas nagfor throws "Error: pr50410.f90, line 8: U has already been completely initialised". This is heading towards a WONTFIX :-( Paul
[Bug testsuite/116080] New tests from r15-2233-g8d1af8f904a0c0 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Andi Kleen : https://gcc.gnu.org/g:ee41cd863b7c38ee3bc415ea7154954aa6facca3 commit r15-2339-gee41cd863b7c38ee3bc415ea7154954aa6facca3 Author: Andi Kleen Date: Wed Jul 24 20:18:56 2024 -0700 PR116080: Fix tail call dejagnu checks - Run the target_effective tail_call checks without optimization to match the actual test cases. - Add an extra check for external tail calls to handle targets like powerpc that cannot tail call between different object files. This one will also cover templates. gcc/testsuite/ChangeLog: PR testsuite/116080 * g++.dg/musttail10.C: Use external tail call target check. * g++.dg/musttail6.C: Dito. * lib/target-supports.exp: Add external_tail_call. Disable optimization for tail call checks.
[Bug c++/116019] Incorrect cannot-tail messages on targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019 --- Comment #1 from GCC Commits --- The trunk branch has been updated by Andi Kleen : https://gcc.gnu.org/g:899ee4815424a73a2b9d899591fab3fcc4520b61 commit r15-2340-g899ee4815424a73a2b9d899591fab3fcc4520b61 Author: Andi Kleen Date: Thu Jul 25 13:54:50 2024 -0700 PR116019: Improve tail call error message The "tail call must be the same type" message is common on some targets with C++, or without optimization. It is generated when gcc believes there is an access of the return value after the call. However usually it does not actually corespond to a type mismatch, but can be caused for other reasons. Make it slightly more vague to be less misleading. gcc/ChangeLog: PR c++/116019 * tree-tailcall.cc (find_tail_calls): Change tail call error message.
[Bug libstdc++/116110] New: Transitions obtained from chrono::time_zone::get_info should not treat times as UTC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116110
Bug ID: 116110
Summary: Transitions obtained from chrono::time_zone::get_info
should not treat times as UTC
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
using namespace std::chrono;
sys_days date(2014y/December/21);
auto zone = locate_zone("Asia/Bishkek");
auto info = zone->get_info(date);
zoned_time local(zone, info.begin);
std::println("{}: {}", zone->name(), local);
}
This prints:
Asia/Bishkek: 2005-08-12 06:00:00 +06
But the transition should be at midnight local time, not midnight UTC.
I noted this in the source:
// XXX The ri.until() time point should be
// "interpreted using the rules in effect just before the transition"
info.end = ri.until();
// XXX UNTIL field should be interpreted
// "using the rules in effect just before the transition"
// so might need to store as year_month_day and hh_mm_ss and only
// convert to a sys_time once we know the offset in effect.
inf.m_until = sys_days(year(y)/m.m/day(d)) + seconds(t.time);
[Bug tree-optimization/116101] [14/15 Regression] isel duplicates comparisons even at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116101 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:9fe53beacfc5c01e24690dc70d7599db084cc8b4 commit r15-2343-g9fe53beacfc5c01e24690dc70d7599db084cc8b4 Author: Andrew Pinski Date: Thu Jul 25 17:43:07 2024 -0700 isel: Don't duplicate comparisons for -O0 nor -fno-tree-ter [PR116101] While doing cleanups on this code I noticed that we do the duplicate of comparisons at -O0. For C and C++ code this makes no difference as the gimplifier never produces COND_EXPR. But it could make a difference for other front-ends. Oh and for -fno-tree-ter, duplicating the comparison is just a waste as it is never used for expand. I also decided to add a few testcases so this is checked in the future. Even added one for the duplication itself. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/116101 gcc/ChangeLog: * gimple-isel.cc (maybe_duplicate_comparison): Don't do anything for -O0 or -fno-tree-ter. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/dup_compare_cond-1.c: New test. * gcc.dg/tree-ssa/dup_compare_cond-2.c: New test. * gcc.dg/tree-ssa/dup_compare_cond-3.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/116101] [14/15 Regression] isel duplicates comparisons even at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116101 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/116065] [13/14/15 Regression] Function attribute optimize() might make ISA target attribute broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065 --- Comment #11 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8a5f528fba788f2af40a15a999bb63a2a0f6f455 commit r15-2344-g8a5f528fba788f2af40a15a999bb63a2a0f6f455 Author: Andrew Pinski Date: Thu Jul 25 09:37:49 2024 -0700 aarch64: Fix target/optimize option handling with transiting between O1 to O2 The problem here is the aarch64 backend enables -mearly-ra at -O2 and above but it is not marked as an Optimization in the .opt file so enabling it sometimes reset the target options when going from -O1 to -O2 for the first time. Build and tested for aarch64-linux-gnu with no regressions. PR target/116065 gcc/ChangeLog: * config/aarch64/aarch64.opt (mearly-ra=): Mark as Optimization rather than Save. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/target_optimization-1.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/116109] Missed optimisation: unnecessary register dependency on reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116109 --- Comment #1 from Andrew Pinski --- -fsplit-ivs-in-unroller might help. But the real issue is that the unroller is still implemented on the rtl level rather than gimple.
[Bug target/116105] ESP32 error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116105 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 98470 ***
[Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470 Andrew Pinski changed: What|Removed |Added CC||charantiruvuri99 at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 116105 has been marked as a duplicate of this bug. ***
[Bug c++/116108] [12/13/14/15 Regression] GCC crashes on incorrect code with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116108
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-07-26
Target Milestone|--- |12.5
Known to fail||10.1.0, 12.1.0
Known to work||9.5.0
Status|UNCONFIRMED |NEW
Summary|GCC crashes on incorrect|[12/13/14/15 Regression]
|code with -std=c++20|GCC crashes on incorrect
||code with -std=c++20
Keywords|error-recovery |
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
template
struct size_t_class {
const size_t_class value = 1;
};
size_t_class t{2};
```
This is invalid since size_t_class is incomplete type in itself :). Well and
there is no way to deduce the template argument here.
GCC 9.5.0 reported:
```
:5:17: error: class template argument deduction failed:
5 | size_t_class t{2};
| ^
:5:17: error: no matching function for call to 'size_t_class(int)'
:2:8: note: candidate: 'template
size_t_class(size_t_class)-> size_t_class'
2 | struct size_t_class {
|^~~~
:2:8: note: template argument deduction/substitution failed:
:5:17: note: mismatched types 'size_t_class' and 'int'
5 | size_t_class t{2};
| ^
```
So a regression.
[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #15 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Alexander Monakov from comment #13)
> > fldt does not convert (otherwise there's no way to spill/reload x87
> > registers).
>
> Doesn't it still misbehave say on pseudo denormals, pseudo infinities,
> pseudo normals, pseudo NaNs etc.?
That would be surprising to me. I tried the following test and it passed:
#include
#include
#include
static union {
struct {
long long mant;
short signexp;
} i;
long double ld;
} inp[] = {
{{ 0x7fff, 32767 }}, // pseudo-QNaN, max payload
{{ 0x4000, 32767 }}, // pseudo-QNaN, min payload
{{ 0x3fff, 32767 }}, // pseudo-SNaN, max payload
{{ 0x0001, 32767 }}, // pseudo-SNaN, min payload
{{ 0x, 32767 }}, // pseudo-Inf
{{ 0x7fff, 32766 }}, // max unnormal
{{ 0x0001, 1 }}, // min unnormal
{{ 0x, 0 }}, // max pseudo-denormal
{{ 0x8001, 0 }}, // min pseudo-denormal
// as above, with sign bit set
{{ 0x7fff, 0x8000 | 32767 }},
{{ 0x4000, 0x8000 | 32767 }},
{{ 0x3fff, 0x8000 | 32767 }},
{{ 0x0001, 0x8000 | 32767 }},
{{ 0x, 0x8000 | 32767 }},
{{ 0x7fff, 0x8000 | 32766 }},
{{ 0x0001, 0x8000 | 1 }},
{{ 0x, 0x8000 | 0 }},
{{ 0x8001, 0x8000 | 0 }},
};
static long double out[sizeof inp / sizeof *inp];
int main()
{
for (int i = 0; i < sizeof inp / sizeof *inp; i++) {
long double t = inp[i].ld;
asm("" : "+t"(t));
out[i] = t;
}
assert(!memcmp(out, inp, sizeof inp));
}
> And even if not, it still contains padding bits, as it loads 10 bytes rather
> than 12 or 16 it occupies in memory.
Yes, it would be wrong to copy a, say, __int128 using fldt/fstp.
[Bug libstdc++/78483] Error: reference to 'on_exit' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78483 --- Comment #7 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #6) > I don't know the origin of this function, it doesn't seem to be in BSD or > SVR4. https://man7.org/linux/man-pages/man3/on_exit.3.html mentions SunOS 4 (but removed from Solaris/SunOS 5).
[Bug target/7559] kdelibs miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7559 --- Comment #11 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug c++/9704] [3.3/3.4 regression] miscompilation of classes with bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9704 --- Comment #9 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug tree-optimization/16115] [4.0 regression] double-destruction problem with argument passing via temporary (breaks auto_ptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16115 --- Comment #16 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317 --- Comment #52 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322 --- Comment #7 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug tree-optimization/31966] [4.1/4.2 Regression] Miscompiles valid code with -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966 --- Comment #13 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug rtl-optimization/11536] [3.3/3.4 Regression] [strength-reduce] -O2 optimalization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11536 --- Comment #8 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
[Bug rtl-optimization/41033] RTL alias-oracle does not honor -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41033 --- Comment #6 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:a75c6295252d0d998a18927dc7510fac965134c4 commit r15-2349-ga75c6295252d0d998a18927dc7510fac965134c4 Author: Sam James Date: Thu Jul 18 08:27:29 2024 +0100 testsuite: Add dg-do run to even more tests All of these are for wrong-code bugs. Confirmed to be used before but with no execution. Tested on x86_64-pc-linux-gnu and checked test logs before/after. 2024-07-26 Sam James PR target/7559 PR c++/9704 PR c++/16115 PR c++/19317 PR rtl-optimization/11536 PR target/20322 PR tree-optimization/31966 PR rtl-optimization/41033 PR tree-optimization/67947 * g++.dg/cpp1z/byte1.C: Add dg-do run directive. * g++.dg/init/call1.C: Ditto. * g++.dg/init/copy5.C: Ditto. * g++.dg/opt/nrv9.C: Ditto. * gcc.dg/20021006-1.c: Ditto. * gcc.dg/20030721-1.c: Ditto. * gcc.dg/20050307-1.c: Ditto. * gcc.dg/pr41033.c: Ditto. * gcc.dg/torture/pr67947.c: Ditto. * gcc.dg/tree-ssa/pr31966.c: Ditto. * gcc.dg/tree-ssa/tailcall-3.c: Ditto. * gcc.dg/tree-ssa/vrp74.c: Ditto. * gcc.target/nvptx/abort.c: Fix whitespace in dg directive.
