[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312 Martin Liška changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-10-19 Summary|[13 Regression] ICE in |[13 Regression] ICE in |verify_range, at|verify_range, at |value-range.cc:1172, called |value-range.cc:1172, called |from range_true_and_false |from range_true_and_false ||since ||r13-3193-g8b6bcedc88d54415 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r13-3193-g8b6bcedc88d54415.
[Bug ipa/106783] [12/13 Regression] ICE in ipa-modref.cc:analyze_function since r12-5247-ga34edf9a3e907de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/107310] [12/13 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional since r12-5638-ga3e75c1491cd2d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[12/13 Regression] |[12/13 Regression] |"warning: control reaches |"warning: control reaches |end of non-void function" |end of non-void function" |with a throw under a|with a throw under a |trivially-true conditional |trivially-true conditional ||since ||r12-5638-ga3e75c1491cd2d50 --- Comment #3 from Martin Liška --- Started with r12-5638-ga3e75c1491cd2d50.
[Bug tree-optimization/106786] [12/13 Regression] SRA regression causes extra instructions sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106786
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Blocks||100453
CC||jamborm at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
The difference is (before SRA) good vs. bad:
+Rejected (2400): not aggregate: x
+Rejected (2401): not aggregate: y
+Candidate (2452): D.2452
+Rejected (2451): not aggregate: d
+Candidate (2447): D.2447
+Rejected (2446): not aggregate: d
+Rejected (2445): not aggregate: carry
+Candidate (2430): a
+Candidate (2404): z
+! Disqualifying z - Encountered a store to a read-only decl.
+Will attempt to totally scalarize D.2447 (UID: 2447):
+Will attempt to totally scalarize D.2452 (UID: 2452):
Changing the type of a replacement for a offset: 64, size: 8 to an integer.
-Created a replacement for a offset: 64, size: 8: a$8D.2422
+Created a replacement for a offset: 64, size: 8: a$8D.2453
so it looks like SRA is confused by 'z' being declared const?
Thus likely caused by r12-1529-gd7deee423f993b
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 1a3e12f18cc..1f4e5987292 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -922,12 +922,6 @@ create_access (tree expr, gimple *stmt, bool write)
if (!DECL_P (base) || !bitmap_bit_p (candidate_bitmap, DECL_UID (base)))
return NULL;
- if (write && TREE_READONLY (base))
-{
- disqualify_candidate (base, "Encountered a store to a read-only decl.");
- return NULL;
-}
-
HOST_WIDE_INT offset, size, max_size;
if (!poffset.is_constant (&offset)
|| !psize.is_constant (&size)
fixes the regression (leaving the rest of the checks in place, but not sure
how safe that is).
Martin?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
[Bug 100453] [12 Regression] wrong code at -O1 and above since r12-434
[Bug c/107308] ICE in expand_fn_using_insn, at internal-fn.cc:153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107308 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||richard.sandiford at arm dot com --- Comment #1 from Martin Liška --- Started with r9-393-gc566cc9f7847785b.
[Bug c/107307] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923 since r12-3278-g823685221de986af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307 Martin Liška changed: What|Removed |Added Summary|ICE tree check: expected|ICE tree check: expected |class 'type', have |class 'type', have |'exceptional' (error_mark) |'exceptional' (error_mark) |in |in |canonicalize_component_ref, |canonicalize_component_ref, |at gimplify.cc:2923 |at gimplify.cc:2923 since ||r12-3278-g823685221de986af Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||jsm28 at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||sayle at gcc dot gnu.org Last reconfirmed||2022-10-19 --- Comment #1 from Martin Liška --- Started with r12-3278-g823685221de986af.
[Bug c/107305] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107305 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r7-6561-g7af4b20d83a8ce30.
[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057
--- Comment #4 from Hongtao.liu ---
It lookes like after replace equiv value, the pattern turns into
3482(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
3483(vec_concat:V2DF (const_double:DF 1.0e+0 [0x0.8p+1])
3484(const_double:DF 1.0e+0 [0x0.8p+1]))) "/:7:10 5956
{vec_concatv2df}
3485 (expr_list:REG_EQUAL (const_vector:V2DF [
3486(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
3487])
3488(nil)))
and in op1 and op2(the same as op1) is forced to mem separately with
3734(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
3735(vec_concat:V2DF (mem/u/c:DF (reg:DI 330) [0 S8 A64])
3736(const_double:DF 1.0e+0 [0x0.8p+1]))) "":7:10 5956
{vec_concatv2df}
3737 (expr_list:REG_EQUAL (const_vector:V2DF [
3738(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
3739])
3740(nil)))
3741(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
3742(vec_concat:V2DF (mem/u/c:DF (reg:DI 330) [0 S8 A64])
3743(mem/u/c:DF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8
A64]))) "test.c":7:10 5956 {vec_concatv2df}
3744 (expr_list:REG_EQUAL (const_vector:V2DF [
3745(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
3746])
3747(nil)))
3755(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
3756(vec_concat:V2DF (mem/u/c:DF (reg:DI 330) [0 S8 A64])
3757(mem/u/c:DF (reg:DI 331) [0 S8 A64]))) "test.c":7:10 5956
{vec_concatv2df}
3758 (expr_list:REG_EQUAL (const_vector:V2DF [
3759(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
3760])
3761(nil)))
but gcc do set goal_alt_win[2] as false, but ignored it since below codes
thought it's already matched before.
4507 /* Operands that match previous ones have already been handled. */
4508=>if (goal_alt_matches[i] >= 0)
4509continue;
[Bug testsuite/106806] [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails after r13-2333-gca8f4e8af14869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|middle-end |testsuite Keywords||testsuite-fail
[Bug tree-optimization/85964] [10/11 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 Richard Biener changed: What|Removed |Added Known to work||12.1.0, 13.0 Status|ASSIGNED|NEW Summary|[10/11/12/13 Regression]|[10/11 Regression] compile |compile time hog w/ -O3 |time hog w/ -O3 -ftracer |-ftracer|-fno-guess-branch-probabili |-fno-guess-branch-probabili |ty |ty | Assignee|law at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #24 from Richard Biener --- GCC 8.4 and 9.5 take around 4s for me, GCC 10 and 11 about 10s, GCC 12 and trunk are instant (0.2s). GCC 12+ has the backwards threader rewritten, that's nothing to backport. But at least fixed in 12+ sofar. Nothing to do here anymore (not for Jeff either ;))
[Bug target/107271] [13 Regression] ICE: in expand_vec_perm_shufps_shufps, at config/i386/i386-expand.cc:19676 with __builtin_shuffle() since r13-2843-g3db8e9c2422d924a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107271 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1442e2031e0bc2d0a5bf88ef3c92c5410e044bab commit r13-3368-g1442e2031e0bc2d0a5bf88ef3c92c5410e044bab Author: liuhongt Date: Tue Oct 18 16:58:52 2022 +0800 Canonicalize vec_perm index to make the first index come from the first vector. Fix unexpected non-canon form from gimple vector selector. gcc/ChangeLog: PR target/107271 * config/i386/i386-expand.cc (ix86_vec_perm_index_canon): New. (expand_vec_perm_shufps_shufps): Call ix86_vec_perm_index_canon gcc/testsuite/ChangeLog: * gcc.target/i386/pr107271.c: New test.
[Bug target/106815] [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106815 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Richard Biener --- So fixed.(?)
[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target||ppc64le-linux-gnu
[Bug c++/106858] [12 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172 since r12-5835-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106858
Richard Biener changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-checking,
||ice-on-invalid-code
--- Comment #4 from Richard Biener ---
But it's rejected now:
t.ii: In member function 'void A::f()':
t.ii:3:34: error: invalid use of non-static member function 'void A::f()'
3 | #pragma omp target map(this->f)
|~~^
t.ii:2:8: note: declared here
2 | void f() {
|^
[Bug c++/106858] [12 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172 since r12-5835-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106858 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE: |[12 Regression] ICE: tree |tree check: expected tree |check: expected tree that |that contains 'decl common' |contains 'decl common' |structure, have 'baselink' |structure, have 'baselink' |in |in |cp_ubsan_maybe_instrument_m |cp_ubsan_maybe_instrument_m |ember_access, at|ember_access, at |cp/cp-ubsan.cc:172 since|cp/cp-ubsan.cc:172 since |r12-5835-g0ab29cf0bb68960c |r12-5835-g0ab29cf0bb68960c Known to work||13.0 Known to fail||12.2.0 Priority|P3 |P2 --- Comment #3 from Richard Biener --- fixed on trunk sofar.
[Bug debug/106859] [10/11/12/13 Regression] ICE in val_store, at var-tracking.cc:2532 since r7-3839-gde0a3fa38e2ad8f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106859 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Richard Biener --- The bisected rev. likely just exposes a latent bug.
[Bug target/106861] ICE in add_cfi_args_size, at dwarf2cfi.cc:501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106861 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE in |ICE in add_cfi_args_size, |add_cfi_args_size, at |at dwarf2cfi.cc:501 |dwarf2cfi.cc:501| Target Milestone|12.3|--- --- Comment #2 from Richard Biener --- So it's not a regression, with GCC 12+ -fnon-call-exceptions adds -fexceptions implicitely.
[Bug preprocessor/78581] Out of memory when preprocessing #include with -traditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78581 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-10-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Richard Biener --- Confirmed by the confirmed duplicate which has a slightly different testcase.
[Bug preprocessor/106874] [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106874 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Richard Biener --- Really looks like a duplicate. *** This bug has been marked as a duplicate of bug 78581 ***
[Bug preprocessor/78581] Out of memory when preprocessing #include with -traditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78581 Richard Biener changed: What|Removed |Added CC||gs...@t-online.de --- Comment #3 from Richard Biener --- *** Bug 106874 has been marked as a duplicate of this bug. ***
[Bug target/106875] [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/106877] [12 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |move_for_stack_reg, at |move_for_stack_reg, at |reg-stack.cc:1076 since |reg-stack.cc:1076 since |r12-248-gb58dc0b803057c0e |r12-248-gb58dc0b803057c0e Priority|P3 |P4 Known to work||13.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/106880] [12/13 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/88132] Compile time and memory hog w/ var-tracking on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88132 --- Comment #2 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.
[Bug target/97940] [11/12/13 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97940 --- Comment #5 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.
[Bug target/96544] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96544 --- Comment #1 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.
[Bug target/96448] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96448 --- Comment #3 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.
[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259 --- Comment #1 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a).
[Bug rtl-optimization/88596] [10/11/12/13 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596 --- Comment #15 from Arseny Solokha --- In case it's still worth it to track the underlying issue somewhere, does it make sense to open a new PR just for the issue highlighted by Vladimir in comment 8? Otherwise, I suppose this PR can be safely closed. The immediate issue was fixed long ago, as noted by Jakub in comment 7.
[Bug tree-optimization/85964] [10/11/12/13 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 --- Comment #23 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.
[Bug target/99706] [10/11/12/13 Regression] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99706 --- Comment #13 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2, though 11.3 is still affected.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #16 from Hongtao.liu --- (In reply to H.J. Lu from comment #15) > (In reply to Hongtao.liu from comment #14) > > (In reply to H.J. Lu from comment #12) > > > (In reply to Hongyu Wang from comment #10) > > > > > > > > Clang works properly as it overrides -march= to any target clones. I > > > > suppose > > > > we can do similar things in ix86_valid_target_attribute_p > > > > > > That will be wrong since target attribute can be used to disable vector > > > instructions. > > > > But target_clones can't? > > https://godbolt.org/z/jn6GMrdsb > > arch=nehalem will disable AVX. The question is should command line -mavx -march=nehalem disable avx? I think the currect implementation only set not clear isa bits. 2173#define DEF_PTA(NAME) \ 2174if (((processor_alias_table[i].flags & PTA_ ## NAME) != 0) \ 2175&& PTA_ ## NAME != PTA_64BIT \ 2176&& (TARGET_64BIT || PTA_ ## NAME != PTA_UINTR) \ 2177&& !TARGET_EXPLICIT_ ## NAME ## _P (opts)) \ 2178 SET_TARGET_ ## NAME (opts); 2179#include "i386-isa.def" 2180#undef DEF_PTA
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #15 from H.J. Lu --- (In reply to Hongtao.liu from comment #14) > (In reply to H.J. Lu from comment #12) > > (In reply to Hongyu Wang from comment #10) > > > > > > Clang works properly as it overrides -march= to any target clones. I > > > suppose > > > we can do similar things in ix86_valid_target_attribute_p > > > > That will be wrong since target attribute can be used to disable vector > > instructions. > > But target_clones can't? > https://godbolt.org/z/jn6GMrdsb arch=nehalem will disable AVX.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #9 from Jiang An --- Additionally, what happens when I write `using my_size_t = decltype(sizeof(0));` (C++) or `typedef typeof(sizeof(0)) my_size_t;` (GNU C or C23)? I think such enhancement of warnings effectively requires size_t to be some kind of "strong typedef", and the "strength" should be generated from sizeof, alignof, etc.. Perhaps the built-in operator- between pointers also needs to generate such "strength" for the purpose of ptrdiff_t.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #14 from Hongtao.liu --- (In reply to H.J. Lu from comment #12) > (In reply to Hongyu Wang from comment #10) > > > > Clang works properly as it overrides -march= to any target clones. I suppose > > we can do similar things in ix86_valid_target_attribute_p > > That will be wrong since target attribute can be used to disable vector > instructions. But target_clones can't? https://godbolt.org/z/jn6GMrdsb
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #13 from H.J. Lu ---
A simple testcase:
[hjl@gnu-tgl-3 pr107304]$ cat y1.c
typedef struct {
unsigned char v __attribute__((aligned(256))) __attribute__
((vector_size(64 * sizeof(unsigned char;
} stress_vec_u8_64_t;
void __attribute__ ((target ("arch=core2")))
stress_vecshuf_u8_64(stress_vec_u8_64_t *data)
{
data->v += data->v;
}
[hjl@gnu-tgl-3 pr107304]$ make y1.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
-march=tigerlake -S y1.c
during RTL pass: expand
y1.c: In function ‘stress_vecshuf_u8_64’:
y1.c:8:11: internal compiler error: in convert_move, at expr.cc:219
8 | data->v += data->v;
| ^~
0xe7c94c convert_move(rtx_def*, rtx_def*, int)
/export/gnu/import/git/gitlab/x86-gcc/gcc/expr.cc:219
0xe8105c convert_modes(machine_mode, machine_mode, rtx_def*, int)
/export/gnu/import/git/gitlab/x86-gcc/gcc/expr.cc:924
0xe9b586 store_field
/export/gnu/import/git/gitlab/x86-gcc/gcc/expr.cc:7780
0xe92c98 expand_assignment(tree_node*, tree_node*, bool)
/export/gnu/import/git/gitlab/x86-gcc/gcc/expr.cc:5904
0xcfb349 expand_gimple_stmt_1
/export/gnu/import/git/gitlab/x86-gcc/gcc/cfgexpand.cc:3946
0xcfb73e expand_gimple_stmt
/export/gnu/import/git/gitlab/x86-gcc/gcc/cfgexpand.cc:4044
0xd03a0c expand_gimple_basic_block
/export/gnu/import/git/gitlab/x86-gcc/gcc/cfgexpand.cc:6096
0xd05f21 execute
/export/gnu/import/git/gitlab/x86-gcc/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/107313] New: typo in stride_view::_Iterator::operator-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107313
Bug ID: 107313
Summary: typo in stride_view::_Iterator::operator-
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
std/ranges#L7877:
friend constexpr difference_type
operator-(default_sentinel_t __y, const _Iterator& __x)
requires sized_sentinel_for, iterator_t<_Base>>
{ return __detail::__div_ceil(__x._M_end, __x._M_current, __x._M_stride); }
The ',' should be '-'.
testcase:
#include
#include
int main() {
auto i = std::views::istream(std::cin);
auto r = std::views::counted(i.begin(), 4)
| std::views::stride(2);
auto d = r.begin() - r.end();
}
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #12 from H.J. Lu --- (In reply to Hongyu Wang from comment #10) > > Clang works properly as it overrides -march= to any target clones. I suppose > we can do similar things in ix86_valid_target_attribute_p That will be wrong since target attribute can be used to disable vector instructions.
[Bug tree-optimization/107312] New: [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
Bug ID: 107312
Summary: [13 Regression] ICE in verify_range, at
value-range.cc:1172, called from range_true_and_false
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/sve/vcond_2_run.c, w/ -mavx512vbmi -O1
-ftree-loop-vectorize:
void
foo (_Float16 *r, short int *a)
{
int i;
for (i = 0; i < 32; ++i)
r[i] = !!a[i];
}
% x86_64-pc-linux-gnu-gcc-13 -mavx512vbmi -O1 -ftree-loop-vectorize -c
ppt01ppy.c
during GIMPLE pass: dom
ppt01ppy.c: In function 'foo':
ppt01ppy.c:2:1: internal compiler error: in verify_range, at
value-range.cc:1172
2 | foo (_Float16 *r, short int *a)
| ^~~
0x7bcad5 irange::verify_range()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/value-range.cc:1172
0x1e6740b range_true_and_false
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/range.h:53
0x1e68c07 operator_not_equal::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_kind_t) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/range-op.cc:639
0x1d56084 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range-fold.cc:581
0x1d57a60 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range-fold.cc:489
0x1d4a6d3 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:258
0x1d4a6d3 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:319
0x1d4b23a gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:126
0x1034a45 cprop_operand
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:1968
0x1037232 cprop_into_stmt
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:2045
0x1037232 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:2273
0x10382cc dom_opt_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:1678
0x1d150ae dom_walker::walk(basic_block_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/domwalk.cc:311
0x1038dbc execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:939
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #11 from Hongtao.liu --- > > https://godbolt.org/z/v7xT1zahd The issue is still there without builtin_shuffle
[Bug target/104611] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611 vfdff changed: What|Removed |Added CC||zhongyunde at huawei dot com --- Comment #2 from vfdff --- Add a runtime case https://gcc.godbolt.org/z/Tv1YP6bPc
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #10 from Hongyu Wang ---
(In reply to H.J. Lu from comment #9)
> (In reply to Hongtao.liu from comment #8)
> > (In reply to H.J. Lu from comment #7)
> > > (In reply to Hongtao.liu from comment #6)
> > > > (In reply to Hongtao.liu from comment #5)
> > > > > (In reply to H.J. Lu from comment #4)
> > > > > > Since the default is -march=tigerlake, it enables AVX512 in the
> > > > > > middle end.
> > > > > > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to
> > > > > > non-AVX512
> > > > > > ISAs. It means that target_clones can't be more restrictive than the
> > > > > > default. We
> > > > > > should provide better diagnostics.
> > > > >
> > > > > Is there any place checking ISA difference for target_clones?
> > > >
> > > > ix86_valid_target_attribute_inner_p?
> > >
> > > It may not have all ISA infos. Will this
> > >
> > > diff --git a/gcc/config/i386/i386-options.cc
> > > b/gcc/config/i386/i386-options.cc
> > > index acb2291e70f..1efaae132e9 100644
> > > --- a/gcc/config/i386/i386-options.cc
> > > +++ b/gcc/config/i386/i386-options.cc
> > > @@ -2953,6 +2953,14 @@ ix86_option_override_internal (bool main_args_p,
> > > fine grained control & costing. */
> > >SET_OPTION_IF_UNSET (opts, opts_set, param_vect_partial_vector_usage,
> > > 0);
> > >
> > > + if (!main_args_p
> > > + && &global_options != opts
> > > + && (((opts->x_ix86_isa_flags & global_options.x_ix86_isa_flags)
> > > + != global_options.x_ix86_isa_flags)
> > > +|| ((opts->x_ix86_isa_flags2 & global_options.x_ix86_isa_flags2)
> > > +!= global_options.x_ix86_isa_flags2)))
> > > +error ("Target ISAs are more restrictive than the default");
> > > +
> > >return true;
> > > }
> > >
> > > work?
> >
> > Looks reasonable to me.
>
> It doesn't work since we may use target attribute to disable MMX/SSE/SSE2.
> This problem seems to be __builtin_shuffle related.
Clang works properly as it overrides -march= to any target clones. I suppose we
can do similar things in ix86_valid_target_attribute_p
https://godbolt.org/z/v7xT1zahd
[Bug target/106222] x86 Better code squence for __builtin_shuffle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106222 --- Comment #2 from Hongtao.liu --- This is fixed by r13-2843-g3db8e9c2422d92
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #9 from H.J. Lu ---
(In reply to Hongtao.liu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to Hongtao.liu from comment #6)
> > > (In reply to Hongtao.liu from comment #5)
> > > > (In reply to H.J. Lu from comment #4)
> > > > > Since the default is -march=tigerlake, it enables AVX512 in the
> > > > > middle end.
> > > > > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to
> > > > > non-AVX512
> > > > > ISAs. It means that target_clones can't be more restrictive than the
> > > > > default. We
> > > > > should provide better diagnostics.
> > > >
> > > > Is there any place checking ISA difference for target_clones?
> > >
> > > ix86_valid_target_attribute_inner_p?
> >
> > It may not have all ISA infos. Will this
> >
> > diff --git a/gcc/config/i386/i386-options.cc
> > b/gcc/config/i386/i386-options.cc
> > index acb2291e70f..1efaae132e9 100644
> > --- a/gcc/config/i386/i386-options.cc
> > +++ b/gcc/config/i386/i386-options.cc
> > @@ -2953,6 +2953,14 @@ ix86_option_override_internal (bool main_args_p,
> > fine grained control & costing. */
> >SET_OPTION_IF_UNSET (opts, opts_set, param_vect_partial_vector_usage, 0);
> >
> > + if (!main_args_p
> > + && &global_options != opts
> > + && (((opts->x_ix86_isa_flags & global_options.x_ix86_isa_flags)
> > + != global_options.x_ix86_isa_flags)
> > +|| ((opts->x_ix86_isa_flags2 & global_options.x_ix86_isa_flags2)
> > +!= global_options.x_ix86_isa_flags2)))
> > +error ("Target ISAs are more restrictive than the default");
> > +
> >return true;
> > }
> >
> > work?
>
> Looks reasonable to me.
It doesn't work since we may use target attribute to disable MMX/SSE/SSE2.
This problem seems to be __builtin_shuffle related.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 --- Comment #8 from Sam James --- FWIW, the Clang counterpart to this bug is https://github.com/llvm/llvm-project/issues/41959.
[Bug c/107311] New: New test case gcc.dg/c2x-enum-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107311
Bug ID: 107311
Summary: New test case gcc.dg/c2x-enum-1.c fails
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: ---
g:3b3083a598ca3f4b6203284e01ed39ab6ff0844f, r13-3360-g3b3083a598ca3f
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=gcc.dg/c2x-enum-1.c"
FAIL: gcc.dg/c2x-enum-1.c (test for excess errors)
This is failing with 32 bits on big endian powerpc64. 64 bits works fine.
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled39558.cc -m32
-fdiagnostics-plain-output -S -o exceptions_enabled39558.s
FAIL: gcc.dg/c2x-enum-1.c (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/c2x-enum-1.c:8:47: error:
pointer type mismatch in conditional expression
Author: Joseph Myers
Date: Tue Oct 18 14:07:27 2022 +
c: C2x enums wider than int [PR36113]
[Bug web/107297] Support markdown in bugzilla comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107297 --- Comment #5 from Jeff Muizelaar --- (In reply to Eric Gallager from comment #2) > I would also want comments to be editable if this gets turned on, in case I > screw up my formatting... is there a way to allow that in bugzilla? bugzilla.mozilla.org supports editing comments. I'm not sure if it's supported in stock Bugzilla. (In reply to Andrew Pinski from comment #4) > Being able to mark a comment or otherwise as not markdown is needed as all > old comments will be messed up that way. When bugzilla.mozilla.org enabled this, old comments were kept as plain text. That being said, I asked about how Markdown is implemented in bugzilla.mozilla.org: jrmuizel: > How is bmo's Markdown support implemented? > Is it easy for other bugzilla instances to turn on Markdown? glob: It was a lot of work to implement it. bugzilla.mozilla.org is very different from stock Bugzilla, it won't be easy to bring to other instances. I believe there are plans to switch stock Bugzilla to follow BMO, but we're not directly involved in that. So perhaps this is not as easy to enable as I thought it would be.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #8 from Hongtao.liu ---
(In reply to H.J. Lu from comment #7)
> (In reply to Hongtao.liu from comment #6)
> > (In reply to Hongtao.liu from comment #5)
> > > (In reply to H.J. Lu from comment #4)
> > > > Since the default is -march=tigerlake, it enables AVX512 in the middle
> > > > end.
> > > > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to
> > > > non-AVX512
> > > > ISAs. It means that target_clones can't be more restrictive than the
> > > > default. We
> > > > should provide better diagnostics.
> > >
> > > Is there any place checking ISA difference for target_clones?
> >
> > ix86_valid_target_attribute_inner_p?
>
> It may not have all ISA infos. Will this
>
> diff --git a/gcc/config/i386/i386-options.cc
> b/gcc/config/i386/i386-options.cc
> index acb2291e70f..1efaae132e9 100644
> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i386-options.cc
> @@ -2953,6 +2953,14 @@ ix86_option_override_internal (bool main_args_p,
> fine grained control & costing. */
>SET_OPTION_IF_UNSET (opts, opts_set, param_vect_partial_vector_usage, 0);
>
> + if (!main_args_p
> + && &global_options != opts
> + && (((opts->x_ix86_isa_flags & global_options.x_ix86_isa_flags)
> + != global_options.x_ix86_isa_flags)
> +|| ((opts->x_ix86_isa_flags2 & global_options.x_ix86_isa_flags2)
> +!= global_options.x_ix86_isa_flags2)))
> +error ("Target ISAs are more restrictive than the default");
> +
>return true;
> }
>
> work?
Looks reasonable to me.
[Bug web/107297] Support markdown in bugzilla comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107297 --- Comment #4 from Andrew Pinski --- Being able to mark a comment or otherwise as not markdown is needed as all old comments will be messed up that way.
[Bug web/107297] Support markdown in bugzilla comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107297 --- Comment #3 from Andrew Pinski --- I think for gcc I rather not support markdown because source gets mangled if not enclosed with ' or '''. And many folks don't use markdown especially when they are used to plain text. C++ is the worst where < gets eaten up. This has been one of issues with github even.
[Bug web/107297] Support markdown in bugzilla comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107297 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- I would also want comments to be editable if this gets turned on, in case I screw up my formatting... is there a way to allow that in bugzilla?
[Bug c++/107310] [12/13 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310 --- Comment #2 from Andrew Pinski --- Note the warning happens at -O0 only.
[Bug c++/107310] [12/13 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.1.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-10-19
Known to work||11.3.0
Target Milestone|--- |12.3
Keywords||diagnostic
Ever confirmed|0 |1
Summary|"warning: control reaches |[12/13 Regression]
|end of non-void function" |"warning: control reaches
|with a throw under a|end of non-void function"
|trivially-true conditional |with a throw under a
||trivially-true conditional
--- Comment #1 from Andrew Pinski ---
Confirmed. reduced testcase:
struct f
{
~f();
};
int foo(int t) {
f g;
switch (t) {
case 1: return 1;
}
if (true)
throw 1;
}
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
--- Comment #7 from H.J. Lu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > Since the default is -march=tigerlake, it enables AVX512 in the middle
> > > end.
> > > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to
> > > non-AVX512
> > > ISAs. It means that target_clones can't be more restrictive than the
> > > default. We
> > > should provide better diagnostics.
> >
> > Is there any place checking ISA difference for target_clones?
>
> ix86_valid_target_attribute_inner_p?
It may not have all ISA infos. Will this
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index acb2291e70f..1efaae132e9 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -2953,6 +2953,14 @@ ix86_option_override_internal (bool main_args_p,
fine grained control & costing. */
SET_OPTION_IF_UNSET (opts, opts_set, param_vect_partial_vector_usage, 0);
+ if (!main_args_p
+ && &global_options != opts
+ && (((opts->x_ix86_isa_flags & global_options.x_ix86_isa_flags)
+ != global_options.x_ix86_isa_flags)
+|| ((opts->x_ix86_isa_flags2 & global_options.x_ix86_isa_flags2)
+!= global_options.x_ix86_isa_flags2)))
+error ("Target ISAs are more restrictive than the default");
+
return true;
}
work?
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #6 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > (In reply to H.J. Lu from comment #4) > > Since the default is -march=tigerlake, it enables AVX512 in the middle end. > > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to > > non-AVX512 > > ISAs. It means that target_clones can't be more restrictive than the > > default. We > > should provide better diagnostics. > > Is there any place checking ISA difference for target_clones? ix86_valid_target_attribute_inner_p?
[Bug c/107164] No pedantic warning for declaration just referring to a previously-declared enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107164 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Joseph S. Myers --- Fixed for GCC 13.
[Bug c++/101764] ICE for constexpr if within fold expression within lambda expression within a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101764 --- Comment #6 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:f5f1d92fe2e1d75c3fae34497929a1965af704ae commit r13-3366-gf5f1d92fe2e1d75c3fae34497929a1965af704ae Author: Joseph Myers Date: Tue Oct 18 23:25:47 2022 + c: Diagnose "enum tag;" after definition [PR107164] As noted in bug 101764, a declaration "enum tag;" is invalid in standard C after a definition, as well as when no definition is visible; we had a pedwarn-if-pedantic for the forward declaration case, but were missing one for the other case. Add that missing diagnostic (if pedantic only). (These diagnostics will need to be appropriately conditioned when support is added for C2x enums with fixed underlying type, since "enum tag : type;" is OK both before and after a definition.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/107164 gcc/c/ * c-decl.cc (shadow_tag_warned): If pedantic, diagnose "enum tag;" with previous declaration visible. gcc/testsuite/ * gcc.dg/c99-tag-4.c, gcc.dg/c99-tag-5.c, gcc.dg/c99-tag-6.c: New tests.
[Bug c/107164] No pedantic warning for declaration just referring to a previously-declared enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107164 --- Comment #2 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:f5f1d92fe2e1d75c3fae34497929a1965af704ae commit r13-3366-gf5f1d92fe2e1d75c3fae34497929a1965af704ae Author: Joseph Myers Date: Tue Oct 18 23:25:47 2022 + c: Diagnose "enum tag;" after definition [PR107164] As noted in bug 101764, a declaration "enum tag;" is invalid in standard C after a definition, as well as when no definition is visible; we had a pedwarn-if-pedantic for the forward declaration case, but were missing one for the other case. Add that missing diagnostic (if pedantic only). (These diagnostics will need to be appropriately conditioned when support is added for C2x enums with fixed underlying type, since "enum tag : type;" is OK both before and after a definition.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/107164 gcc/c/ * c-decl.cc (shadow_tag_warned): If pedantic, diagnose "enum tag;" with previous declaration visible. gcc/testsuite/ * gcc.dg/c99-tag-4.c, gcc.dg/c99-tag-5.c, gcc.dg/c99-tag-6.c: New tests.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #5 from Hongtao.liu --- (In reply to H.J. Lu from comment #4) > Since the default is -march=tigerlake, it enables AVX512 in the middle end. > When "arch=alderlake" disables AVX512, we fails to expand AVX512 to > non-AVX512 > ISAs. It means that target_clones can't be more restrictive than the > default. We > should provide better diagnostics. Is there any place checking ISA difference for target_clones?
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #13 from Steve Kargl --- On Tue, Oct 18, 2022 at 10:40:59AM +, burnus at gcc dot gnu.org wrote: > > (In reply to kargl from comment #9) > > Please commit the patch in comment #7. character(kind=4) is not > > interoperable > > (unless C_CHAR is CHARACTER(KIND=4) which it isn't). This is an extension > > and > > gfortran should flag. > > While I concur that the example in comment 1 is not interoperable according to > the Fortran 2018 standard, I think the patch of comment 7 rejects too much > (cf. > '(b)' below.) > > Still, I think something should/could be done – hence, I did not close this > PR. > Namely: > > * * * > > For C interoperability, I think there are two parts to this: > > (a.1) module m; character(kind=4) :: c; end module m > (a.2) subroutine foo(x) bind(C) > character(kind=4) :: x > > To both the following applies (F2018, 18.3.1 Interoperability of intrinsic > types): > > "A Fortran intrinsic type with particular type parameter values is > interoperable with a C type if the type and kind type parameter value are > listed in the table on the same row as that C type. If the type is character, > the length type parameter is interoperable > if and only if its value is one." > > Hence, neither 'foo' nor 'c' are interoperable. I'm confused by what you are trying to show with (a.1). The standard has "If the length is not specified in a char-selector or a * char-length, the length is 1.", so that last sentence is no relevant. Moreover, there is no C binding issue as you did not write module m character(kind=4), bind(c) :: c end module m gfortran accepts the above when it should be rejected because of C820 A variable with the BIND attribute shall be interoperable (18.3). For (a.2), this should also be rejected per C1556 A variable that is a dummy argument of a procedure that has ar proc-language-binding-spec shall be assumed-type or of interoperable type and kind type parameters. > (b) subroutine bar(x, y, z) bind(C) > character(kind=4,len=*) :: x > character(kind=4) :: y(:) > character(kind=4), allocatable :: z > > This one is valid as F2018's "18.3.6 Interoperability of procedures and > procedure interfaces" states: > It's not valid per C1556 above and C1555 If proc-language-binding-spec is specified for a procedure, each dummy argument of type CHARACTER with the ALLOCATABLE or POINTER attribute shall have deferred character length.
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #12 from Steve Kargl --- On Tue, Oct 18, 2022 at 05:29:58PM +, sgk at troutmask dot apl.washington.edu wrote: > > % gfcx -c -std=f2018 a.f90 > a.f90:1:30: > > 1 | character(kind=4) function bar(x, y, z) bind(C) > | 1 > Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot > have the BIND(C) attribute > > The patch checks a *function* result variable for an interoperable > CHARACTER kind. > BTW, Fortran standard contains C1553 If proc-language-binding-spec is specified for a function, the function result shall be an interoperable scalar variable. So, accepting "character(kind=4) foo() bind(c)" is questionable (unless kind=4 is C_CHAR, which it isn't).
[Bug fortran/100098] Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch pinged: https://gcc.gnu.org/pipermail/fortran/2022-October/058363.html
[Bug c++/107310] New: "warning: control reaches end of non-void function" with a throw under a trivially-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310
Bug ID: 107310
Summary: "warning: control reaches end of non-void function"
with a throw under a trivially-true conditional
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lvoege at gmail dot com
Target Milestone: ---
Created attachment 53727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53727&action=edit
preprocessed test case
gcc 12 starting with revision a3e75c14 gives "warning: control reaches end of
non-void function" for the following contrived and I think minimal test case
when compiling without optimization. the preprocessed .ii file is attached for
completeness. remove any bit of it and it stops complaining.
#include
std::mutex m;
int t;
int foo() {
std::lock_guard guard(m);
switch (t) {
case 1: return 1;
}
if (true) {
throw std::runtime_error("!");
}
}
this is on ubuntu, but a build from source does the same, as does yesterday's
trunk:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-3ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1)
$ gcc -c foo3.cpp
foo3.cpp: In function ‘int foo()’:
foo3.cpp:14:1: warning: control reaches end of non-void function
[-Wreturn-type]
14 | }
| ^
[Bug libstdc++/104166] Implement C++20 std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |13.0
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #42 from Segher Boessenkool --- (In reply to H.J. Lu from comment #41) > (In reply to Segher Boessenkool from comment #40) > > Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no > > meaning. > > This is invalid RTL. If it ever works, or worked, that is an accident. > > Can we make it to work with a target hook? It will allow more backed > optimizations. No, you cannot. A lot of generic code will not work with your special re-interpretation of basic RTL rules. Just write correct code in your backend, it is not hard.
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #41 from H.J. Lu --- (In reply to Segher Boessenkool from comment #40) > Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no > meaning. > This is invalid RTL. If it ever works, or worked, that is an accident. Can we make it to work with a target hook? It will allow more backed optimizations.
[Bug c++/107256] Contradictory circular noexcept-specifier is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107256 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-10-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug ada/107309] New: GNAT does not apply type conversion rules to dependent expressions of conditional expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107309 Bug ID: 107309 Summary: GNAT does not apply type conversion rules to dependent expressions of conditional expressions Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jakub.s7920 at gmail dot com Target Milestone: --- Created attachment 53726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53726&action=edit if / case expression example According to AARM 4.5.7 (10/3), if the conditional expression is an argument of a type conversion then said conversion should apply to each of the dependent expressions. I tried compiling an example taken straight from AARM on GNAT 12.1.0 and GNAT 10.3.0 but got the following error message: > $ gnat make if_exp.adb > x86_64-linux-gnu-gcc-12 -c if_exp.adb > if_exp.adb:5:34: error: expected an integer type > if_exp.adb:5:34: error: found type universal real > x86_64-linux-gnu-gnatmake-12: "if_exp.adb" compilation error Similar results with an equivalent case expression: > $ gnat make case_exp.adb > x86_64-linux-gnu-gcc-12 -c case_exp.adb > case_exp.adb:7:30: error: expected type universal integer > case_exp.adb:7:30: error: found type universal real > x86_64-linux-gnu-gnatmake-12: "case_exp.adb" compilation error I've attached the source code of both files. The commented out code is, to my understanding, semantically the same as the corresponding version that doesn't compile. http://www.ada-auth.org/standards/12rat/html/Rat12-3-2.html http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-4-5-7.html
[Bug c++/107296] C++20 nested typename: non-template used as template, need typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107296 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- (In reply to Martin Liška from comment #2) > Likely started with r10-3735-gcb57504a55015891. Yes, error: need ‘typename’ before ‘Mixin::Nested::Mixin2’ because ‘Mixin::Nested’ is a dependent scope started with r10-3735-gcb57504a55015891, error: non-template ‘Mixin2’ used as template started with r12-4584-g1c690164668bda.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 H.J. Lu changed: What|Removed |Added Last reconfirmed||2022-10-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from H.J. Lu --- Since the default is -march=tigerlake, it enables AVX512 in the middle end. When "arch=alderlake" disables AVX512, we fails to expand AVX512 to non-AVX512 ISAs. It means that target_clones can't be more restrictive than the default. We should provide better diagnostics.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #18 from Stas Sergeev --- (In reply to Stas Sergeev from comment #5) > And its running on a stack previously > poisoned before pthread_cancel(). And the reason for that is because the glibc in use is the one not built with -fsanitize=address. When it calls its __do_cancel() which has attribute "noreturn", __asan_handle_noreturn() is not being called. Therefore the canceled thread remains with the poison below SP. I believe the glibc re-built with asan would not exhibit the crash. Note: all URLs above where I was pointing to the code, now either are a dead links or point to wrong lines. Its quite a shame that such a bug remains unfixed after a complete explanation was provided, but now that explanation is rotten...
[Bug c/107306] [12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107306 --- Comment #1 from Andrew Pinski --- I suspect this is invalid gimple without the options supplied in the dg command.
[Bug c/107308] New: ICE in expand_fn_using_insn, at internal-fn.cc:153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107308 Bug ID: 107308 Summary: ICE in expand_fn_using_insn, at internal-fn.cc:153 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9 and file gcc.dg/gimplefe-26.c : $ gcc-13-20221016 -c gimplefe-26.c -fgimple during RTL pass: expand gimplefe-26.c: In function 'foo_1': gimplefe-26.c:5:18: internal compiler error: in expand_fn_using_insn, at internal-fn.cc:153 5 | type __GIMPLE () foo_##num (type a, type b, type c) \ | ^~~~ gimplefe-26.c:12:1: note: in expansion of macro 'foo' 12 | foo(float, 1) | ^~~ 0xbe62ff expand_fn_using_insn ../../gcc/internal-fn.cc:153 0x960647 expand_call_stmt ../../gcc/cfgexpand.cc:2737 0x960647 expand_gimple_stmt_1 ../../gcc/cfgexpand.cc:3880 0x960647 expand_gimple_stmt ../../gcc/cfgexpand.cc:4044 0x967def expand_gimple_basic_block ../../gcc/cfgexpand.cc:6096 0x96a446 execute ../../gcc/cfgexpand.cc:6822
[Bug c/107307] New: ICE tree check: expected class 'type', have 'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
Bug ID: 107307
Summary: ICE tree check: expected class 'type', have
'exceptional' (error_mark) in
canonicalize_component_ref, at gimplify.cc:2923
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r12 between 20210822 and 20210905 :
$ cat z1.c
void f ()
{
const struct { int a[1]; } b;
int *c = b.a;
int *b;
}
$ gcc-13-20221016 -c z1.c
z1.c: In function 'f':
z1.c:4:12: warning: initialization discards 'const' qualifier from pointer
target type [-Wdiscarded-qualifiers]
4 | int *c = b.a;
|^
z1.c:5:8: error: conflicting type qualifiers for 'b'
5 | int *b;
|^
z1.c:3:30: note: previous declaration of 'b' with type 'const struct
'
3 | const struct { int a[1]; } b;
| ^
z1.c:4:13: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923
4 | int *c = b.a;
|~^~
0x6acb6d tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8886
0xb8578e tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3649
0xb8578e canonicalize_component_ref
../../gcc/gimplify.cc:2923
0xba3857 gimplify_compound_lval
../../gcc/gimplify.cc:3326
0xb9753a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16280
0xbaa91a gimplify_addr_expr
../../gcc/gimplify.cc:6529
0xb9913d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16375
0xba931f gimplify_modify_expr
../../gcc/gimplify.cc:6121
0xb998f7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16328
0xb9d7d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xba2343 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.cc:492
0xba2343 gimplify_decl_expr
../../gcc/gimplify.cc:1938
0xb988b2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16525
0xb9d7d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xb98bcb gimplify_statement_list
../../gcc/gimplify.cc:2021
0xb98bcb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16773
0xb9d7d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xb9e163 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xb990da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16529
0xb9d7d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
[Bug c/107305] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107305 --- Comment #2 from Andrew Pinski --- The input is invalid gimple to begin with so
[Bug c/107305] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107305 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-10-18 --- Comment #1 from Marek Polacek --- Confirmed. Without -fgimple: 107305.c:4:1: error: ‘__GIMPLE’ only valid with ‘-fgimple’ 4 | __GIMPLE int | ^~~~ during GIMPLE pass: lower 107305.c: In function ‘foo’: 107305.c:5:1: internal compiler error: in maybe_canonicalize_mem_ref_addr, at gimple-fold.cc:5976 5 | foo (int n) | ^~~ 0xf6da98 maybe_canonicalize_mem_ref_addr /home/mpolacek/src/gcc/gcc/gimple-fold.cc:5976 0xf6e630 fold_stmt_1 /home/mpolacek/src/gcc/gcc/gimple-fold.cc:6134 0xf6f28b fold_stmt(gimple_stmt_iterator*) /home/mpolacek/src/gcc/gcc/gimple-fold.cc:6379 0x29c1e62 lower_stmt /home/mpolacek/src/gcc/gcc/gimple-low.cc:784 0x29bff00 lower_sequence /home/mpolacek/src/gcc/gcc/gimple-low.cc:228 0x29c2300 lower_gimple_bind /home/mpolacek/src/gcc/gcc/gimple-low.cc:873 0x29bfb59 lower_function_body /home/mpolacek/src/gcc/gcc/gimple-low.cc:118 0x29bfe7c execute /home/mpolacek/src/gcc/gcc/gimple-low.cc:205
[Bug c/107306] New: [12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107306
Bug ID: 107306
Summary: [12/13 Regression] ICE: verify_gimple failed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r12 and file gcc.target/i386/pr101636.c :
$ gcc-13-20221016 -c pr101636.c -fgimple
pr101636.c: In function 'bar':
pr101636.c:93:1: error: incorrect type of vector 'constructor' elements
93 | }
| ^
{_150, _149, _148, _147, _146, _145, _144, _143, _142, _141, _140, _139, _138,
_137, _136, _135}
_151 = {_150, _149, _148, _147, _146, _145, _144, _143, _142, _141, _140, _139,
_138, _137, _136, _135};
during IPA pass: *free_lang_data
pr101636.c:93:1: internal compiler error: verify_gimple failed
0xf31434 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.cc:5649
0xdce16e execute_function_todo
../../gcc/passes.cc:2091
0xdceb8d do_per_function
../../gcc/passes.cc:1701
0xdcebf2 execute_todo
../../gcc/passes.cc:2145
[Bug testsuite/107213] New test case c-c++-common/pointer-to-fn1.c uses unsupported option r13-3202-g67efffec943656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107213 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Marek Polacek --- Fixed.
[Bug testsuite/107213] New test case c-c++-common/pointer-to-fn1.c uses unsupported option r13-3202-g67efffec943656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107213 --- Comment #1 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:cc694f45087c892e69ebbb177203c708f00b1bc7 commit r13-3365-gcc694f45087c892e69ebbb177203c708f00b1bc7 Author: Marek Polacek Date: Tue Oct 11 12:51:40 2022 -0400 testsuite: Only run -fcf-protection test on i?86/x86_64 [PR107213] This test fails on non-i?86/x86_64 targets because on those targets we get error: '-fcf-protection=full' is not supported for this target so this patch limits where the test is run. PR testsuite/107213 gcc/testsuite/ChangeLog: * c-c++-common/pointer-to-fn1.c: Only run on i?86/x86_64.
[Bug c/107305] New: ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107305
Bug ID: 107305
Summary: ICE: 'verify_gimple' failed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r7 :
$ cat z1.c
unsigned a;
static double *d;
static _Bool b;
__GIMPLE int
foo (int n)
{
b = __builtin_add_overflow (n, *d, &a);
}
$ gcc-13-20221016 -c z1.c -fgimple
z1.c: In function 'foo':
z1.c:5:1: error: invalid argument to gimple call
5 | foo (int n)
| ^~~
*d
b = __builtin_add_overflow (n, *d, &a);
during GIMPLE pass: *warn_unused_result
z1.c:5:1: internal compiler error: 'verify_gimple' failed
0xf2c76d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.cc:5301
0xdce2ca execute_function_todo
../../gcc/passes.cc:2093
0xdcebf2 execute_todo
../../gcc/passes.cc:2145
[Bug fortran/107266] Reject kind=4 characters for BIND(C) – it invalid and generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266 --- Comment #11 from Steve Kargl --- On Tue, Oct 18, 2022 at 10:40:59AM +, burnus at gcc dot gnu.org wrote: > > (b) subroutine bar(x, y, z) bind(C) > character(kind=4,len=*) :: x > character(kind=4) :: y(:) > character(kind=4), allocatable :: z > > This one is valid as F2018's "18.3.6 Interoperability of procedures and > procedure interfaces" states: I'm going to assume that you did not compile the above, or read the patch. % gfcx -c a.f90 a.f90:1:22: 1 | subroutine bar(x, y, z) bind(C) | 1 Error: Allocatable character dummy argument 'z' at (1) must have deferred length as procedure 'bar' is BIND(C) % cat a.f90 subroutine bar(x, y, z) bind(C) character(kind=4,len=*) :: x character(kind=4) :: y(:) character(kind=4,len=:), allocatable :: z end subroutine bar % gfcx -c a.f90 && nm a.o | grep bar T bar % gfcx -c -std=f2018 a.f90 && nm a.o | grep bar T bar % cat a.f90 character(kind=4) function bar(x, y, z) bind(C) character(kind=4,len=*) :: x character(kind=4) :: y(:) character(kind=4,len=:), allocatable :: z end function bar % gfcx -c a.f90 && nm a.o | grep bar T bar % gfcx -c -std=f2018 a.f90 a.f90:1:30: 1 | character(kind=4) function bar(x, y, z) bind(C) | 1 Error: GNU Extension: Symbol 'bar' at (1) with type CHARACTER(KIND=4) cannot have the BIND(C) attribute The patch checks a *function* result variable for an interoperable CHARACTER kind.
[Bug c++/107282] ICE on valid code template + overloaded + visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107282 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Martin Liška --- Yes, sorry, I can verify it started with r11-2455-gc6ef9d8d3f11221d.
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #3 from Colin Ian King --- Created attachment 53725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53725&action=edit Got the issue down to a small reproducer Ran code through gcc -E, hacked out the irrelevant code, got it down to the smallest reproducer. Notes: gcc-12 -c stress-vecshuf-repro-small.c -march=tigerlake Removing "arch=alderlake" from target clones makes the issue disappear. Making the for loop to a small number of iterations (e.g. 4) makes the issue disappear too. Compiling without -march=tigerlake makes the issue disappear too.
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #2 from Colin Ian King --- Created attachment 53724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53724&action=edit preprocessed source that can be compiled to show bug This is the pre-processed output from stress-vecshuf.c, compiling it will trigger the issue. gcc-12 -c stress-vecshuf-post-cpp.c -march=tigerlake
[Bug middle-end/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 --- Comment #1 from Colin Ian King --- See: https://github.com/ColinIanKing/stress-ng/issues/235
[Bug middle-end/107304] New: internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 Bug ID: 107304 Summary: internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: colin.king at intel dot com Target Milestone: --- compiling stress-ng using CLFLAGS=-march-tigerlake: git clone https://github.com/ColinIanKing/stress-ng cd stress-ng make clean CFLAGS=-march=tigerlake make -j 8 make stress-ng VERBOSE= make[1]: Entering directory '/home/cking/repos/stress-ng' CC stress-vecshuf.c during RTL pass: expand stress-vecshuf.c: In function 'stress_vecshuf_u128_4.arch_alderlake': stress-vecshuf.c:107:39: internal compiler error: in convert_move, at expr.cc:220 107 | static double TARGET_CLONES OPTIMIZE3 stress_vecshuf_ ## tag ## _ ## elements ( \ | ^~~ stress-vecshuf.c:139:1: note: in expansion of macro 'STRESS_VEC_SHUFFLE' 139 | STRESS_VEC_SHUFFLE(u128, 4) | ^~ 0x7f47b0cfb209 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f47b0cfb2bb __libc_start_main_impl ../csu/libc-start.c:389 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. make[1]: *** [Makefile:504: stress-vecshuf.o] Error 1 make[1]: Leaving directory '/home/cking/repos/stress-ng' make: *** [Makefile:488: all] Error 2 Without CFLAGS=-march=tigerlake it builds fine.
[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100616 Patrick Palka changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #5 from Patrick Palka --- *** Bug 105044 has been marked as a duplicate of this bug. ***
[Bug c++/105044] [modules] ICE in comptypes, at cp/typeck.cc:1531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105044 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- dup of PR100616 I think -- streaming of cNTTP arguments has been fixed on trunk by r13-2953 *** This bug has been marked as a duplicate of bug 100616 ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105044, which changed state. Bug 105044 Summary: [modules] ICE in comptypes, at cp/typeck.cc:1531 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105044 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105045, which changed state. Bug 105045 Summary: [modules] Can't deduce defaulted template parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105045 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105045] [modules] Can't deduce defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105045 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 CC||ppalka at gcc dot gnu.org --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0101137c7c5d612c0624f9a2fd5198b302243f85 commit r13-3362-g0101137c7c5d612c0624f9a2fd5198b302243f85 Author: Patrick Palka Date: Tue Oct 18 10:57:30 2022 -0400 c++ modules: stream non-trailing default targs [PR105045] This fixes the below testcase in which we neglect to stream the default argument for T only because the subsequent parameter U doesn't also have a default argument. PR c++/105045 gcc/cp/ChangeLog: * module.cc (trees_out::tpl_parms_fini): Don't assume default template arguments must be trailing. (trees_in::tpl_parms_fini): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/pr105045_a.C: New test. * g++.dg/modules/pr105045_b.C: New test. --- Comment #2 from Patrick Palka --- Fixed on trunk
[Bug tree-optimization/107275] [13 Regression] Recent ifcvt changes resulting in references to SSA_NAME on free list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jeffrey A. Law --- Fixed by Andre's patch on the trunk.
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #40 from Segher Boessenkool --- Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no meaning. This is invalid RTL. If it ever works, or worked, that is an accident. A MODE_CC stands for a comparison (in the mathematical sense). Saying it is "1" would mean what?
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 --- Comment #9 from Mikael Pettersson --- I can confirm that building the latest uClibc-ng for h8300 now succeeds with gcc master @ 4374c424a60777a7658050f0aeb1dcc9af915647.
[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48379 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #4 from David Crocker --- I too am getting fed up with having to add an explicit cast to double to suppress the warning whenever I pass a float to a varargs function. I have probably spent a few hours this year adding these casts. As has already been said, nothing can he done about the promotion in this context, so it's not worth warning about. Whereas in other situations, the warning is very useful to me because I work with embedded processors that have single-precision but not double-precision floating point hardware, so I want to avoid double precision maths as far as possible.
[Bug tree-optimization/106990] Missing TYPE_OVERFLOW_SANITIZED checks in match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106990 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 53723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53723&action=edit gcc13-pr106990.patch Untested fix.
[Bug c/36113] fix C enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Joseph S. Myers --- Fixed for GCC 13. (Where unsigned long is 64-bit, GCC may choose that instead of unsigned long long for the underlying type of the enum, so you'll get a format checking warning in that case, but all the enum constants now have the enum type if any of them don't fit in int, in accordance with C2X.)
[Bug c/36113] fix C enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
--- Comment #7 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:3b3083a598ca3f4b6203284e01ed39ab6ff0844f
commit r13-3360-g3b3083a598ca3f4b6203284e01ed39ab6ff0844f
Author: Joseph Myers
Date: Tue Oct 18 14:07:27 2022 +
c: C2x enums wider than int [PR36113]
C2x has two enhancements to enumerations: allowing enumerations whose
values do not all fit in int (similar to an existing extension), and
allowing an underlying type to be specified (as in C++). This patch
implements the first of those enhancements.
Apart from adjusting diagnostics to reflect this being a standard
feature, there are some semantics differences from the previous
extension:
* The standard feature gives all the values of such an enum the
enumerated type (while keeping type int if that can represent all
values of the enumeration), where previously GCC only gave those
values outside the range of int the enumerated type. This change
was previously requested in PR 36113; it seems unlikely that people
are depending on the detail of the previous extension that some
enumerators had different types to others depending on whether their
values could be represented as int, and this patch makes the change
to types of enumerators unconditionally (if that causes problems in
practice we could always make it conditional on C2x mode instead).
* The types *while the enumeration is being defined*, for enumerators
that can't be represented as int, are now based more directly on the
types of the expressions used, rather than a possibly different type
with the right precision constructed using c_common_type_for_size.
Again, this change is made unconditionally.
* Where overflow (or wraparound to 0, in the case of an unsigned type)
when 1 is implicitly added to determine the value of the next
enumerator was previously an error, it now results in a wider type
with the same signedness (as the while-being-defined type of the
previous enumerator) being chosen, if available.
When a type is chosen in such an overflow case, or when a type is
chosen for the underlying integer type of the enumeration, it's
possible that (unsigned) __int128 is chosen. Although C2x allows for
such types wider than intmax_t to be considered extended integer
types, we don't have various features required to do so (integer
constant suffixes; sufficient library support would also be needed to
define the associated macros for printf/scanf conversions, and
typedef names would need to be defined). Thus, there are
also pedwarns for exceeding the range of intmax_t / uintmax_t, as
while in principle exceeding that range is OK, it's only OK in a
context where the relevant types meet the requirements for extended
integer types, which does not currently apply here.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also
manually checked diagnostics for c2x-enum-3.c with -m32 to confirm the
diagnostics in that { target { ! int128 } } test are as expected.
PR c/36113
gcc/c-family/
* c-common.cc (c_common_type_for_size): Add fallback to
widest_unsigned_literal_type_node or
widest_integer_literal_type_node for precision that may not
exactly match the precision of those types.
gcc/c/
* c-decl.cc (finish_enum): If any enumerators do not fit in int,
convert all to the type of the enumeration. pedwarn if no integer
type fits all enumerators and default to
widest_integer_literal_type_node in that case. Otherwise pedwarn
for type wider than intmax_t.
(build_enumerator): pedwarn for enumerators outside the range of
uintmax_t or intmax_t, and otherwise use pedwarn_c11 for
enumerators outside the range of int. On overflow, attempt to
find a wider type that can hold the value of the next enumerator.
Do not convert value to type determined with
c_common_type_for_size.
gcc/testsuite/
* gcc.dg/c11-enum-1.c, gcc.dg/c11-enum-2.c, gcc.dg/c11-enum-3.c,
gcc.dg/c2x-enum-1.c, gcc.dg/c2x-enum-2.c, gcc.dg/c2x-enum-3.c,
gcc.dg/c2x-enum-4.c, gcc.dg/c2x-enum-5.c: New tests.
* gcc.dg/pr30260.c: Explicitly use -std=gnu11. Update expected
diagnostics.
* gcc.dg/torture/pr25183.c: Update expected diagnostics.
[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043
--- Comment #14 from Marek Polacek ---
I've encountered this bug with:
struct S { };
void g(S&&);
void
f (S&& arg)
{
g(S(arg)); // warning: useless cast to type 'struct S'
}
which doesn't compile without the cast, because then "arg" is an lvalue that
cannot bind to S&&.
I'd like to disable then warning when a class is cast to a non-reference type.
