[Bug testsuite/104756] gcc.dg/vect/vect-fmax-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104756 Rainer Orth changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/610457.html Target Milestone|12.3|13.0 --- Comment #6 from Rainer Orth --- Fixed for GCC 13.
[Bug testsuite/107808] gcc.dg/vect/vect-bitfield-write-2.c etc.FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107808 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/610458.html Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #5 from Rainer Orth --- Fixed for GCC 13.
[Bug testsuite/107808] gcc.dg/vect/vect-bitfield-write-2.c etc.FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107808 --- Comment #4 from CVS Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:e304e9283a97e28dc0074d8d30715d3f626b4e87 commit r13-5321-ge304e9283a97e28dc0074d8d30715d3f626b4e87 Author: Rainer Orth Date: Tue Jan 24 08:49:44 2023 +0100 testsuite: Fix gcc.dg/vect/vect-bitfield-write-[23].c on SPARC [PR107808] The gcc.dg/vect/vect-bitfield-write-[23].c tests FAIL on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect "vectorized 1 loops" 1 As discussed in the PR, they require vect_long_long support, but fail to require that. This patch fixes this. Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. 2023-01-20 Rainer Orth gcc/testsuite: PR testsuite/107808 * gcc.dg/vect/vect-bitfield-write-2.c: Require vect_long_long. * gcc.dg/vect/vect-bitfield-write-3.c: Likewise.
[Bug testsuite/104756] gcc.dg/vect/vect-fmax-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104756 --- Comment #5 from CVS Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:7b8f4c85051501e9c804df2de1a08f11aa187e9d commit r13-5320-g7b8f4c85051501e9c804df2de1a08f11aa187e9d Author: Rainer Orth Date: Tue Jan 24 08:48:11 2023 +0100 testsuite: Fix gcc.dg/vect/vect-fmax-1.c etc. on SPARC [PR104756] The gcc.dg/vect/vect-fmax-?.c etc. tests FAIL on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/vect-fmax-1.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmax-1.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmax-2.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmax-2.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmax-3.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmax-3.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-2.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-2.c scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-3.c -flto -ffat-lto-objects scan-tree-dump vect "Detected reduction" FAIL: gcc.dg/vect/vect-fmin-3.c scan-tree-dump vect "Detected reduction" As discussed in the PR, they require vect_float support, but the tests don't declare it. This patch fixes this. Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. 2023-01-20 Rainer Orth gcc/testsuite: PR testsuite/104756 * gcc.dg/vect/vect-fmax-1.c: Require vect_float. * gcc.dg/vect/vect-fmax-2.c: Likewise. * gcc.dg/vect/vect-fmax-3.c: Likewise. * gcc.dg/vect/vect-fmin-1.c: Likewise. * gcc.dg/vect/vect-fmin-2.c: Likewise. * gcc.dg/vect/vect-fmin-3.c: Likewise.
[Bug ipa/108509] New: [13 Regression] ICE in add, at hash-set.h:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
Bug ID: 108509
Summary: [13 Regression] ICE in add, at hash-set.h:64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc 13.0.1 20230122 snapshot (g:844eab81da3f49da88e8bb02e2b1255ba88d02b0) ICEs
when compiling the following testcase, reduced from
test/CodeGenCXX/vtable-available-externally.cpp from the clang 15 test suite,
w/ -O1 -fdevirtualize -fno-tree-fre:
struct B {
virtual void deref ();
};
struct RefPtr {
B *p;
RefPtr ()
{
p->deref ();
}
};
void
f ()
{
RefPtr b;
}
% g++-13 -O1 -fdevirtualize -fno-tree-fre -c ce52fpmj.cpp
during IPA pass: remove_symbols
ce52fpmj.cpp:18:1: internal compiler error: in add, at hash-set.h:64
18 | }
| ^
0x7fa104 hash_set
>::add(symtab_node* const&)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/hash-set.h:64
0x7faaf4 hash_set >::add(void* const&)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/tree.h:3644
0x7faaf4 walk_polymorphic_call_targets
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/ipa.cc:185
0x7faaf4 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/ipa.cc:430
0x1108079 execute_todo
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/passes.cc:2159
[Bug c/107048] GCC lacks -fsanitize=kcfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048 --- Comment #2 from Sam James --- See https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608723.html and so on. kees mentioned this is currently in review and a new version is being spun up.
[Bug target/107731] loongarch Operand Modifiers are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731 chenglulu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from chenglulu --- Fixed
[Bug target/107731] loongarch Operand Modifiers are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107731 --- Comment #8 from CVS Commits --- The master branch has been updated by LuluCheng : https://gcc.gnu.org/g:b5ea0f071aca505c82cc8c062e57bf9892900277 commit r13-5319-gb5ea0f071aca505c82cc8c062e57bf9892900277 Author: Lulu Cheng Date: Wed Jan 18 11:06:56 2023 +0800 LoongArch: Fixed a compilation failure with '%c' in inline assembly [PR107731]. Co-authored-by: Yang Yujie PR target/107731 gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_classify_address): Add precessint for CONST_INT. (loongarch_print_operand_reloc): Operand modifier 'c' is supported. (loongarch_print_operand): Increase the processing of '%c'. * doc/extend.texi: Adds documents for LoongArch operand modifiers. And port the public operand modifiers information to this document. gcc/testsuite/ChangeLog: * gcc.target/loongarch/tst-asm-const.c: Moved to... * gcc.target/loongarch/pr107731.c: ...here.
[Bug rtl-optimization/108508] New: [13 Regression] ICE in insert_def_after, at rtl-ssa/accesses.cc:622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
Bug ID: 108508
Summary: [13 Regression] ICE in insert_def_after, at
rtl-ssa/accesses.cc:622
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.1 20230122 snapshot (g:844eab81da3f49da88e8bb02e2b1255ba88d02b0) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/vldN_lane_1.c, w/ -O3
-fharden-conditional-branches -fno-dce -fno-guess-branch-probability:
#include
int
test_vld3q_lane_f64 (void)
{
float64x2x3_t vectors;
float64_t temp[2];
int i, j;
for (i = 0; i < 3; i++)
{
vst1q_f64 (temp, vectors.val[i]);
for (j = 0; j < 2; j++)
if (temp[j])
return 1;
}
return 0;
}
void
foo (void)
{
if (test_vld3q_lane_f64 () || test_vld3q_lane_f64 ())
__builtin_abort ();
}
% aarch64-linux-gnu-gcc-13 -O3 -fharden-conditional-branches -fno-dce
-fno-guess-branch-probability -c sajwlgxq.c
during RTL pass: fwprop1
sajwlgxq.c: In function 'foo':
sajwlgxq.c:26:1: internal compiler error: in insert_def_after, at
rtl-ssa/accesses.cc:622
26 | }
| ^
0x884123 rtl_ssa::function_info::insert_def_after(rtl_ssa::def_info*,
rtl_ssa::def_info*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/accesses.cc:622
0x1d86aa6 rtl_ssa::function_info::append_phi(rtl_ssa::ebb_info*,
rtl_ssa::phi_info*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/blocks.cc:383
0x1d86aa6 rtl_ssa::function_info::create_phi(rtl_ssa::ebb_info*,
rtl_ssa::resource_info, rtl_ssa::access_info**, unsigned int)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/blocks.cc:507
0x1d86c70 rtl_ssa::function_info::create_degenerate_phi(rtl_ssa::ebb_info*,
rtl_ssa::set_info*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/blocks.cc:529
0x1cb5e20 rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/changes.cc:508
0x1cb658a
rtl_ssa::function_info::change_insns(array_slice)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/changes.cc:659
0x1cb6cf4 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/rtl-ssa/changes.cc:717
0x1b49d55 try_fwprop_subst_pattern
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:553
0x1b49d55 try_fwprop_subst
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:627
0x1b4a349 forward_propagate_and_simplify
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:823
0x1b4a349 forward_propagate_into
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:886
0x1b4a6f6 fwprop_insn
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:943
0x1b4a8e2 fwprop
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230122/work/gcc-13-20230122/gcc/fwprop.cc:995
[PATCH] options: fix cl_target_option_print_diff() with strings
Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2.
This bug caused the dump file produced by -fdump-ipa-inline-details to
not correctly show the difference in target options when a function
could not be inlined due to a target option mismatch.
gcc/ChangeLog:
* optc-save-gen.awk: Fix copy-and-paste error.
Fixes: b54ecc769f59 ("re PR bootstrap/90543 (Build failure on MINGW for
gcc-9.1.0)")
Signed-off-by: Eric Biggers
---
gcc/optc-save-gen.awk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
index e91adf7f132..d2cb53c477f 100644
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -1013,7 +1013,7 @@ for (i = 0; i < n_target_string; i++) {
print " indent, \"\",";
print " \"" name "\",";
print " ptr1->x_" name " ? ptr1->x_" name " : \"(null)\",";
- print " ptr2->x_" name " ? ptr1->x_" name " : \"(null)\");";
+ print " ptr2->x_" name " ? ptr2->x_" name " : \"(null)\");";
print "";
}
--
2.39.1.405.gd4c25cc71f-goog
[Bug c++/108488] segfault with -fmodules-ts and class-scope friend declaration first in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108488 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 104234. *** This bug has been marked as a duplicate of bug 104234 ***
[Bug c++/107329] [13 Regression] ICE in gimplify_expr, at gimplify.cc:17118 since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107329 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/104234] ICE with -fmodules-ts and std::map/_Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104234 Andrew Pinski changed: What|Removed |Added CC||wendellcraigbaker at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 108488 has been marked as a duplicate of this bug. ***
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/107329] [13 Regression] ICE in gimplify_expr, at gimplify.cc:17118 since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107329 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:049a52909075117f5112971cc83952af2a818bc1 commit r13-5318-g049a52909075117f5112971cc83952af2a818bc1 Author: Jason Merrill Date: Mon Jan 23 16:25:07 2023 -0500 c++: TARGET_EXPR collapsing [PR107303] In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by discarding the outer one, but as in this testcase that breaks if the TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always be safe to strip the inner one; if its slot were reused, there would be a COMPOUND_EXPR around the TARGET_EXPR. For 107329, if we're setting *walk_subtrees, we also need to fold TARGET_EXPR_CLEANUP. PR c++/107303 PR c++/107329 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_r) [TARGET_EXPR]: In case of double TARGET_EXPR, keep the outer one instead of the inner one. (maybe_replace_decl): New. gcc/testsuite/ChangeLog: * g++.dg/ext/builtin-shufflevector-5.C: New test. * g++.dg/init/new51.C: New test.
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:049a52909075117f5112971cc83952af2a818bc1 commit r13-5318-g049a52909075117f5112971cc83952af2a818bc1 Author: Jason Merrill Date: Mon Jan 23 16:25:07 2023 -0500 c++: TARGET_EXPR collapsing [PR107303] In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by discarding the outer one, but as in this testcase that breaks if the TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always be safe to strip the inner one; if its slot were reused, there would be a COMPOUND_EXPR around the TARGET_EXPR. For 107329, if we're setting *walk_subtrees, we also need to fold TARGET_EXPR_CLEANUP. PR c++/107303 PR c++/107329 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_r) [TARGET_EXPR]: In case of double TARGET_EXPR, keep the outer one instead of the inner one. (maybe_replace_decl): New. gcc/testsuite/ChangeLog: * g++.dg/ext/builtin-shufflevector-5.C: New test. * g++.dg/init/new51.C: New test.
[Bug tree-optimization/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-24
Component|ipa |tree-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
assign_dfs_numbers has not changed for years ...
1: *cfun.cfg = {x_entry_block_ptr = 0x773ef6c0, x_exit_block_ptr =
0x773ef720, x_basic_block_info = 0x7fffbcdd4000, x_n_basic_blocks =
1399837, x_n_edges = 1399836, x_last_basic_block = 1399837, last_label_uid = 1,
x_label_to_block_map = 0x77277f18, x_profile_status = PROFILE_ABSENT,
x_dom_computed = {
DOM_NO_FAST_QUERY, DOM_NONE}, x_n_bbs_in_dom_tree = {1399837, 0},
max_jumptable_ents = 0, count_max = {static n_bits = 61, static max_count =
2305843009213693950, static uninitialized_count = 2305843009213693951, m_val =
2305843009213693951, m_quality = GUESSED_LOCAL}, edge_flags_allocated = 262143,
bb_flags_allocated = 32767}
#0 assign_dfs_numbers (node=0x45b8ae0, num=num@entry=0x7fffd850) at
/home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:644
#1 0x00b0ca0c in compute_dom_fast_query (dir=,
dir@entry=) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:674
#2 calculate_dominance_info(cdi_direction) () at
/home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:748
#3 0x00fbb0ea in cleanup_tree_cfg_noloop (ssa_update_flags=) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfgcleanup.cc:
#4 cleanup_tree_cfg(unsigned int) () at
/home/apinski/src/upstream-gcc/gcc/gcc/tree-cfgcleanup.cc:1212
#5 0x00e7b27d in execute_function_todo(function*, void*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:2057
#6 0x00e7b70f in execute_todo(unsigned int) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:2145
#7 0x00e7e9f7 in execute_one_pass(opt_pass*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:2690
#8 0x00e7ef00 in execute_pass_list_1(opt_pass*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:2753
#9 0x00e7ef39 in execute_pass_list(function*, opt_pass*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:2764
#10 0x00e7f85d in do_per_function_toporder(void (*)(function*, void*),
void*) [clone .part.0] () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:1780
#11 0x00e7fa8f in do_per_function_toporder (data=,
callback=0xe7ef20 ) at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:3098
#12 execute_ipa_pass_list(opt_pass*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/passes.cc:3098
#13 0x00ad8274 in ipa_passes () at
/home/apinski/src/upstream-gcc/gcc/gcc/cgraphunit.cc:2203
#14 symbol_table::compile() [clone .part.0] () at
/home/apinski/src/upstream-gcc/gcc/gcc/cgraphunit.cc:2324
#15 0x00adac18 in symbol_table::compile (this=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cgraphunit.cc:2576
#16 symbol_table::finalize_compilation_unit (this=0x77246000) at
/home/apinski/src/upstream-gcc/gcc/gcc/cgraphunit.cc:2576
#17 0x00f69660 in compile_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:471
#18 0x00907eb2 in do_compile (no_backend=false, no_backend@entry=) at /home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:2125
#19 toplev::main(int, char**) () at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:2277
#20 0x00909afb in main (argc=20, argv=0x7fffdd48) at
/home/apinski/src/upstream-gcc/gcc/gcc/main.cc:39
almost 2 basic blocks per time the function inlined ...
Maybe we can do some bb merging before calculate_dominance_info
[Bug ipa/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #2 from Andrew Pinski --- #21 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x137731a8, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #22 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13773160, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #23 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13773118, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #24 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x137730d0, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #25 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13773088, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #26 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13773040, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #27 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772ff8, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #28 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772fb0, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #29 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772f68, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #30 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772f20, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #31 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772ed8, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #32 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772e90, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #33 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772e48, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #34 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772e00, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #35 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772db8, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #36 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772d70, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #37 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772d28, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #38 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772ce0, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #39 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772c98, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #40 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772c50, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #41 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772c08, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #42 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772bc0, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 #43 0x00b0ad8b in assign_dfs_numbers (node=node@entry=0x13772b78, num=num@entry=0x7fffd850) at /home/apinski/src/upstream-gcc/gcc/gcc/dominance.cc:648 ...
[Bug c++/107267] [13 Regression] ICE in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jason Merrill --- Fixed.
[Bug target/30527] Use of input/output operands in __asm__ templates not fully documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527 --- Comment #9 from Andrew Pinski --- (In reply to Nate Eldredge from comment #8) > So that makes this into a compatibility issue. I disagree there. Inline-asm does not need to be compatiable between two compilers at all. In fact it is just happens that clang adopted GNU style inline-asm rather than inventing their own style (badly by the way for most targets because inline-asm depends on GCC's own internal definitions to get correct).
[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |13.0
Last reconfirmed||2023-01-24
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, here is a testcase that does not error out before the ICE:
```
namespace std {
template struct tuple_size;
template struct tuple_element;
}
struct A {
template int get() { return 1; }
};
template<> struct std::tuple_size { static const int value = 3; };
template struct std::tuple_element { using type = int; };
struct B {
A *begin();
A *end();
};
void f (B a)
{
#pragma omp for collapse(2)
for (auto [i, j, k] : a)
for (int l = i; l < j; l += k)
;
}
```
Note -fopenmp -Wall is needed to get the ICE.
[Bug jit/96089] Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #4 from Andrew Pinski --- (In reply to Antoni from comment #3) > This can be closed as this was done in > 3736837806fdb26daa51300bee1554bef89db9fe. r12-5962-g3736837806fdb2
[Bug middle-end/108506] bit_cast from 32-byte vector generates worse code than memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-01-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/108506] bit_cast from 32-byte vector generates worse code than memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
--- Comment #2 from Andrew Pinski ---
Confirmed.
Internals of what is going on:
Gimple IR
bad (__builtin_bit_cast):
MEM[(struct Foo *)output_7(D) + ivtmp.13_20 * 1] = VIEW_CONVERT_EXPR(_1);
vs good (memcpy):
MEM [(char * {ref-all})output_7(D) + ivtmp.28_20 *
1] = _1;
Both look ok really. Though the first one could be rewritten into the second
one which would fix the expansion. Though maybe it could be fixed in the
middle-end while doing the expansion of gimple to RTL.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #36 from Bill Zissimopoulos --- (In reply to niXman from comment #34) > (In reply to Bill Zissimopoulos from comment #33) > > Now that we have a potential patch what are the steps to get it included > > into the gcc codebase? > > great question! > I think the best option is to give me rights to merge =) My apologies but I am new to bugzilla and I do not know what that means. I am looking aroung the bug report user interface and I do not see any obvious way to give you "rights to merge". (In reply to niXman from comment #35) > and the rights to edit my comments too =) FYI I do not see any obvious way to edit my comments either :)
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 --- Comment #1 from Antoni --- Patch posted here: https://gcc.gnu.org/pipermail/jit/2022q4/001594.html
[Bug jit/96089] Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- This can be closed as this was done in 3736837806fdb26daa51300bee1554bef89db9fe.
[Bug c++/107267] [13 Regression] ICE in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #12 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4cbc71691e47b1ca6b64feb0af678606705d2f92 commit r13-5316-g4cbc71691e47b1ca6b64feb0af678606705d2f92 Author: Jason Merrill Date: Mon Jan 23 17:14:11 2023 -0500 c++: TARGET_EXPR_ELIDING_P and std::move [PR107267] With -ffold-simple-inlines, we turn calls to std::move into the static_cast equivalent. In this testcase, this exposes the FindResult temporary to copy elision which is not specified by the standard, through an optimization in gimplify_modify_expr_rhs. Since the type is not TREE_ADDRESSABLE, this is not detectable by the user, so we just need to soften the assert. PR c++/107267 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_gimplify_init_expr): Allow unexpected elision of trivial types. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/move2.C: New test.
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #10 from Gavin Howard --- I have confirmed that the GCC bug (if it is a bug) also exists in 12.2.1, at least using the amal.c I have attached.
[Bug other/108507] New: [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507 Bug ID: 108507 Summary: [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a09bfa03 fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:c6a09bfa038ccbfc9f123ede14a3d6237fab, r13-5244-gc6a09bfa03 This test case is failing on some of power powerpc64 servers. This run was on a power 9: make -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/SARD-tc841-basic-00182-min.c" FAIL: gcc.dg/analyzer/SARD-tc841-basic-00182-min.c (test for excess errors) # of unexpected failures1 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/SARD-tc841-basic-00182-min.c:67:3: warning: 'fgets' writing 11 bytes into a region of size 10 overflows the destination [-Wstringop-overflow=] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/SARD-tc841-basic-00182-min.c:67:3: warning: 'fgets' writing 11 bytes into a region of size 10 overflows the destination [-Wstringop-overflow=] commit c6a09bfa038ccbfc9f123ede14a3d6237fab (HEAD, refs/bisect/bad) Author: David Malcolm Date: Wed Jan 18 11:41:47 2023 -0500 analyzer: add SARD testsuite 81
[Bug c++/107267] [13 Regression] ICE in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/108506] bit_cast from 32-byte vector generates worse code than memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506 --- Comment #1 from m.cencora at gmail dot com --- "that is the only difference between the two funcs" I mean that deserialize and deserialize2 differ only by the way they perform store from v32uc to output (bit_cast vs memcpy)
[Bug c++/108506] New: bit_cast from 32-byte vector generates worse code than memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
Bug ID: 108506
Summary: bit_cast from 32-byte vector generates worse code than
memcpy
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Gcc trunk on x86-64 produces much worse assembly for 'deserialize' func than
for equivalent 'deserialize2'.
These two should be equivalent as bit_cast should be just a type-safe
equivalent of memcpy (that is the only difference between the two funcs).
g++ -std=c++23 -O3 -mavx2
using v32uc = unsigned char __attribute((vector_size(32)));
constexpr auto N = 1024;
struct Foo
{
int a[8];
};
static_assert(sizeof(Foo) == sizeof(v32uc));
void deserialize(const unsigned char* input, Foo* output)
{
for (auto i = 0u; i != N; ++i)
{
v32uc vec;
__builtin_memcpy(, input, sizeof(vec));
input += sizeof(vec);
vec = __builtin_shuffle(vec,
v32uc{
3, 2, 1, 0,
7, 6, 5, 4,
11, 10, 9, 8,
15, 14, 13, 12,
19, 18, 17, 16,
23, 22, 21, 20,
27, 26, 25, 24,
31, 30, 29, 28
}
);
*output = __builtin_bit_cast(Foo, vec);
output++;
}
}
void deserialize2(const unsigned char* input, Foo* output)
{
for (auto i = 0u; i != N; ++i)
{
v32uc vec;
__builtin_memcpy(, input, sizeof(vec));
input += sizeof(vec);
vec = __builtin_shuffle(vec,
v32uc{
3, 2, 1, 0,
7, 6, 5, 4,
11, 10, 9, 8,
15, 14, 13, 12,
19, 18, 17, 16,
23, 22, 21, 20,
27, 26, 25, 24,
31, 30, 29, 28
}
);
__builtin_memcpy(output, , sizeof(vec));
output++;
}
}
Disassembly:
deserialize(unsigned char const*, Foo*):
push rbp
xor eax, eax
mov rbp, rsp
and rsp, -32
vmovdqa ymm1, YMMWORD PTR .LC0[rip]
.L2:
vmovdqu ymm3, YMMWORD PTR [rdi+rax]
vpshufb ymm2, ymm3, ymm1
vmovdqa YMMWORD PTR [rsp-32], ymm2
mov rdx, QWORD PTR [rsp-32]
mov rcx, QWORD PTR [rsp-24]
vmovdqa xmm4, XMMWORD PTR [rsp-16]
vmovq xmm0, rdx
vpinsrq xmm0, xmm0, rcx, 1
vmovdqu XMMWORD PTR [rsi+16+rax], xmm4
vmovdqu XMMWORD PTR [rsi+rax], xmm0
add rax, 32
cmp rax, 32768
jne .L2
vzeroupper
leave
ret
deserialize2(unsigned char const*, Foo*):
vmovdqa ymm1, YMMWORD PTR .LC0[rip]
xor eax, eax
.L7:
vmovdqu ymm2, YMMWORD PTR [rdi+rax]
vpshufb ymm0, ymm2, ymm1
vmovdqu YMMWORD PTR [rsi+rax], ymm0
add rax, 32
cmp rax, 32768
jne .L7
vzeroupper
ret
.LC0:
.byte 3
.byte 2
.byte 1
.byte 0
.byte 7
.byte 6
.byte 5
.byte 4
.byte 11
.byte 10
.byte 9
.byte 8
.byte 15
.byte 14
.byte 13
.byte 12
.byte 3
.byte 2
.byte 1
.byte 0
.byte 7
.byte 6
.byte 5
.byte 4
.byte 11
.byte 10
.byte 9
.byte 8
.byte 15
.byte 14
.byte 13
.byte 12
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:51767f31878a95161142254dca7119b409699670 commit r13-5315-g51767f31878a95161142254dca7119b409699670 Author: Harald Anlauf Date: Mon Jan 23 22:13:44 2023 +0100 Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502] gcc/fortran/ChangeLog: PR fortran/108502 * dependency.cc (gfc_check_dependency): Prevent NULL pointer dereference while recursively checking expressions. gcc/testsuite/ChangeLog: PR fortran/108502 * gfortran.dg/pr108502.f90: New test.
[Bug c++/107797] "warning right operand of comma operator has no effect" for expressions with no comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/107797] "warning right operand of comma operator has no effect" for expressions with no comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed for GCC 13.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 107797, which changed state. Bug 107797 Summary: "warning right operand of comma operator has no effect" for expressions with no comma operator https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/107797] "warning right operand of comma operator has no effect" for expressions with no comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:e3585e6acdfd5c1793f877476647d2521620c95c
commit r13-5314-ge3585e6acdfd5c1793f877476647d2521620c95c
Author: Marek Polacek
Date: Thu Jan 19 17:12:34 2023 -0500
c++: Quash bogus -Wunused-value with new [PR107797]
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so
we can just suppress -Wunused-value.
PR c++/107797
gcc/cp/ChangeLog:
* cvt.cc (ocp_convert): copy_warning when creating a new
COMPOUND_EXPR.
* init.cc (build_new_1): Suppress -Wunused-value on
compiler-generated COMPOUND_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wunused-value-1.C: New test.
[Bug fortran/108434] [12/13 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434 --- Comment #6 from anlauf at gcc dot gnu.org --- The reported issue should be fixed for gcc-13 and on 12-branch. There is another potential issue (see comment#1) which might be related to this one or not. Keeping this PR open until the finalization work reaches the next stage...
[Bug c++/107329] [13 Regression] ICE in gimplify_expr, at gimplify.cc:17118 since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107329 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/108434] [12/13 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ea99f8d0f6674de2c2f20a5bc3221ae6325032ea commit r12-9059-gea99f8d0f6674de2c2f20a5bc3221ae6325032ea Author: Harald Anlauf Date: Wed Jan 18 22:13:29 2023 +0100 Fortran: error recovery for invalid CLASS component [PR108434] gcc/fortran/ChangeLog: PR fortran/108434 * expr.cc (class_allocatable): Prevent NULL pointer dereference or invalid read. (class_pointer): Likewise. gcc/testsuite/ChangeLog: PR fortran/108434 * gfortran.dg/pr108434.f90: New test. (cherry picked from commit 117848f425a3c0eda85517b4bdaf2ebe3bc705c2)
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #8 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array.
>
> do you mean for the following example:
>
> typedef struct {
> char pad;
> char data[];
> } F2;
>
> typedef struct {
> unsigned pad;
> F2 flex;
> } S2;
>
> although C standard disallow the above, GCC extension treats S2.flex.data as
> a flex-array?
>
> How about:
>
> typedef struct {
> char pad;
> char data[];
> } F2;
>
> typedef struct {
> F2 flex;
> unsigned pad;
> } S2;
>
> do we have any documentation on this Gcc extension?
There's an open bug to document these semantics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058820.html
[Bug c++/107303] [13 Regression] ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3060 with nested __builtin_shufflevector() since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107303 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector since r13-4564-gd081807d8d70e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector since r13-4564-gd081807d8d70e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:72e46b3c7ad5e3d2c69868a510c00707c356106a commit r13-5313-g72e46b3c7ad5e3d2c69868a510c00707c356106a Author: Jason Merrill Date: Mon Jan 23 15:03:47 2023 -0500 c++: vector of class with bool ctor [PR108195] The transformation done by r13-4564 to use the iterator constructor instead of the initializer-list constructor breaks if the iterator pointers are themselves treated as elements of an initializer-list, so check for that. PR c++/108195 gcc/cp/ChangeLog: * call.cc (build_user_type_conversion_1): Check whether the iterators also find a list ctor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-vect2.C: New test.
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:771d793df1622a476e1cf8d05f0a6aee350fa56b commit r13-5312-g771d793df1622a476e1cf8d05f0a6aee350fa56b Author: Harald Anlauf Date: Mon Jan 23 21:19:03 2023 +0100 Fortran: avoid ICE on invalid array subscript triplets [PR108501] gcc/fortran/ChangeLog: PR fortran/108501 * interface.cc (get_expr_storage_size): Check array subscript triplets that we actually have integer values before trying to extract with mpz_get_si. gcc/testsuite/ChangeLog: PR fortran/108501 * gfortran.dg/pr108501.f90: New test.
[Bug c++/108504] [13 Regression] ICE in cp_lexer_handle_early_pragma, at cp/parser.cc:675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108504 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|openmp | Last reconfirmed||2023-01-23 Target Milestone|--- |13.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Most likely one of these two patches: r13-1605-gcb7b01db7a1979 r13-1544-ge46f4d7430c521 The first one is a fix for the second one ... here is a testcase without openmp: ``` "" #pragma GCC diagnostic push ``` Confirmed.
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058818.html
[Bug fortran/108502] ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-01-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. A NULL pointer dereference during error handling. Required option: -ffrontend-optimize I have a patch.
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code, |ice-on-invalid-code |rejects-valid | --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > First, I think the code is actually valid, adjusting keywords. Oops, I cannot read, and Intel accepted the code when forgetting to enfore standard conformance checking. Putting a brown bag over my head. Fixing keywords again...
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 54330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54330=edit Patch for the ICE in get_expr_storage_size
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> GCC considered this as a flex-array.
do you mean for the following example:
typedef struct {
char pad;
char data[];
} F2;
typedef struct {
unsigned pad;
F2 flex;
} S2;
although C standard disallow the above, GCC extension treats S2.flex.data as a
flex-array?
How about:
typedef struct {
char pad;
char data[];
} F2;
typedef struct {
F2 flex;
unsigned pad;
} S2;
do we have any documentation on this Gcc extension?
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-01-23 Keywords|ice-on-invalid-code |ice-on-valid-code, ||rejects-valid Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- First, I think the code is actually valid, adjusting keywords. Furthermore, there are two issues here, an underlying one, namely that we reject the following: program p real, parameter :: n = 2 real :: a(1,(n),2) end pr108501.f90:3:14: 3 | real :: a(1,(n),2) | 1 Error: Expression at (1) must be of INTEGER type, found REAL pr108501.f90:3:20: 3 | real :: a(1,(n),2) |1 Error: The module or main program array 'a' at (1) must have constant shape This is already present in gcc-7, so although it is a nasty bug, it's not a regression. The other issue is likely exposed by this misbehavior, leading to an ICE when checking the argument of the call in get_expr_storage_size. This issue is also present in all versions down to at least gcc-7, so arguably not really a regression. I have a patch for the latter.
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Siddhesh Poyarekar from comment #2) > The standard does not allow the nesting, but gcc supports it as an extension. when GCC supports it as an extension, I see two possible situations: A. the structure with the flexible array member will be the last field of the outer structure; B. the structure with the flexible array member will be the middle field of the outer structure; I see GCC compile the above 2 cases without any complain (i.e, GCC extension accepts both A and B) and Adding -Wpedantic issues warnings for both. My questions: 1. Should GCC extension support the above case B? (it should NOT, right? what's the point to support it) 2. If GCC extension support the above case A (looks like this is the case, and some application use this case extensively, for example, Linux Kernel uses this a lot, See bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832), what's the clear definition for it? Does it still treat the flexible array member in the inner structure as a flexible array member in the outer structure? If so, we might need to clearly document this in GCC's extension, and then user will have consistent expectation on this.
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e6669c0a50ed8aee9e5997d61e6271668d149218 commit r13-5311-ge6669c0a50ed8aee9e5997d61e6271668d149218 Author: Harald Anlauf Date: Mon Jan 16 21:41:09 2023 +0100 Fortran: fix ICE in check_charlen_present [PR108420] gcc/fortran/ChangeLog: PR fortran/108420 * iresolve.cc (check_charlen_present): Preserve character length if there is no array constructor. gcc/testsuite/ChangeLog: PR fortran/108420 * gfortran.dg/pr108420.f90: New test.
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector since r13-4564-gd081807d8d70e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/108496] [13 Regression] NRV ICE since r13-4469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108496 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/108496] [13 Regression] NRV ICE since r13-4469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108496 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4b125d01a5d5e601961419396332b74eea2219bb commit r13-5310-g4b125d01a5d5e601961419396332b74eea2219bb Author: Jason Merrill Date: Mon Jan 23 13:33:07 2023 -0500 c++: result location and explicit inst [PR108496] In r13-4469 we started to build the RESULT_DECL in grokdeclarator, while we still know the location of the return type. But in this testcase, we hit that code again when parsing the explicit instantiation, and clobber the DECL_RESULT that was previously used in parsing the function. So, only set DECL_RESULT if it isn't already set. PR c++/108496 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check whether DECL_RESULT is already set. gcc/testsuite/ChangeLog: * g++.dg/template/explicit-instantiation5.C: New test.
[Bug tree-optimization/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #13) > Ok, this seems wrong: > > New sequence of 1 stores to replace old one of 10 stores > # .MEM_102 = VDEF <.MEM_101> > MEM [(void *)] = "\x02\x00\xff\x03\x00\x01\x02\x03"; > Exceeded original number of stmts (2). Not profitable to emit new sequence. > > > The size should be 9 rather 8 ... I'll have a look.
[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432 --- Comment #3 from Segher Boessenkool --- (In reply to David Malcolm from comment #2) > Unfortunately, some analyzer warnings work better with optimization > *disabled*. -fanalyzer runs much later than most other static analyzers. Understood. But some work better with it enabled, right? > For example, -Wanalyzer-deref-before-check doesn't work well with > optimization, as the dereference means that that optimized can remove the > checks before the analyzer "sees" them. Yes. > I think there's a natural tension between optimization and detecting > undefined behavior, in that -fanalyzer wants to report on possible undefined > behavior, whereas optimization wants to take advantage of undefined behavior. "Take advantage of"... A program that contains UB is erroneous, has no defined semantics *at all*, so what the compiler is really doing is assuming the program is a correct program, and generating more optimal target code based on that not unreasonable assumption. This sounds a bit better, right? It still is true that the compiler cannot detect all UB during compilation (it needs to know the program's input as well for that, and even then it isn't realistic). Is it even possible to detect *all* UB at runtime?
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-23 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- >'--with-multilib-list=aprofile,rmprofile' is the key here really. The problem is there is a loop around the multilib list and tm_file="$tm_file arm/arm-mlib.h" gets executed twice. So you get arm/arm-mlib.h in the list twice and gengtype does not like that.
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 --- Comment #3 from Srinath Parvathaneni --- I introduced the bug, working on the fix.
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 --- Comment #2 from Srinath Parvathaneni --- /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/configure' '--target=arm-none-eabi' '--prefix=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/install' '--with-gmp=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/host-tools' '--with-mpfr=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/host-tools' '--with-mpc=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/host-tools' '--with-isl=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/host-tools' '--disable-shared' '--disable-nls' '--disable-threads' '--disable-tls' '--enable-checking=yes' '--without-cloog' '--without-isl' '--with-newlib' '--without-headers' '--with-gnu-as' '--with-gnu-ld' '--with-sysroot=/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/install/arm-none-eabi' '--with-multilib-list=aprofile,rmprofile' '--with-pkgversion=unknown' 'target_alias=arm-none-eabi' 'CFLAGS=-O0 -g3' 'CXXFLAGS=-O0 -g3' '--enable-languages=c,lto' $ac_configure_extra_args --no-create --no-recursion
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 --- Comment #1 from Andrew Pinski --- How did you configure GCC?
[Bug tree-optimization/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #15 from Adam Stylinski --- (In reply to Adam Stylinski from comment #14) > (In reply to Andrew Pinski from comment #13) > > Ok, this seems wrong: > > > > New sequence of 1 stores to replace old one of 10 stores > > # .MEM_102 = VDEF <.MEM_101> > > MEM [(void *)] = "\x02\x00\xff\x03\x00\x01\x02\x03"; > > Exceeded original number of stmts (2). Not profitable to emit new sequence. > > > > > > The size should be 9 rather 8 ... > > Ah cool. I guess the suboptimality is probably a bug in its own right. Any > reason it's using so many stores to memory? The clang version can > accomplish it almost entirely in GPRs. I guess "entirely in GPRs" isn't very true. Clang does it in 7 stores, with the last being the return value on the stack. GCC is doing it in 16 stores and quite a few loads. The stack churn is a bit unnerving, is there anything that can be done to improve this?
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c/108505] New: Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 Bug ID: 108505 Summary: Arm: arm-none-eabi toolchain build failing with compiler error. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: srinath.parvathaneni at arm dot com Target Milestone: --- The latest arm-none-eabi build for gcc-trunk failing with following error: /bin/bash /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../move-if-change tmp-constants.h insn-constants.h /bin/bash /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../move-if-change tmp-enums.cc insn-enums.cc echo timestamp > s-constants echo timestamp > s-enums /bin/bash /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../move-if-change tmp-options.h options.h echo timestamp > s-options-h build/gengtype \ -S /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc -I gtyp-input.list -w tmp-gtype.state g++ -c -O0 -g3 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc -I/media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/build -I/media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../include -I/media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../libcpp/include \ -o build/gencheck.o /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/gencheck.cc gtyp-input.list:19: file /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/config/arm/arm-mlib.h specified more than once for language (all) g++ -O0 -g3 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/gencheck \ build/gencheck.o ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a build/gencheck > tmp-check.h /bin/bash /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../move-if-change tmp-check.h tree-check.h echo timestamp > s-check make[1]: *** [Makefile:2823: s-gtype] Error 1 make[1]: *** Waiting for unfinished jobs /bin/bash /media/sripar01/2tb_work/trunk_gcc_13/src/gcc/gcc/../move-if-change tmp-mlib.h multilib.h echo timestamp > s-mlib rm gcov.pod gcov-dump.pod gpl.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod gcov-tool.pod lto-dump.pod make[1]: Leaving directory '/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/obj/gcc1/gcc' make: *** [Makefile:4600: all-gcc] Error 2 make: Leaving directory '/media/sripar01/2tb_work/trunk_gcc_13/build-arm-none-eabi/obj/gcc1' And this build failure is due to following patch: commit 3a0dd2cc28ee2833dc5bf1d4fb6d746a8c55ca4d Author: Srinath Parvathaneni Date: Mon Jan 23 11:04:19 2023 + arm: Add pacbti related multilib support for armv8.1-m.main.
[Bug c/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 dhekir at gmail dot com changed: What|Removed |Added Attachment #54328|0 |1 is obsolete|| --- Comment #1 from dhekir at gmail dot com --- Created attachment 54329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54329=edit .tar.gz compressed version of program causing crash
[Bug tree-optimization/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #14 from Adam Stylinski --- (In reply to Andrew Pinski from comment #13) > Ok, this seems wrong: > > New sequence of 1 stores to replace old one of 10 stores > # .MEM_102 = VDEF <.MEM_101> > MEM [(void *)] = "\x02\x00\xff\x03\x00\x01\x02\x03"; > Exceeded original number of stmts (2). Not profitable to emit new sequence. > > > The size should be 9 rather 8 ... Ah cool. I guess the suboptimality is probably a bug in its own right. Any reason it's using so many stores to memory? The clang version can accomplish it almost entirely in GPRs.
[Bug tree-optimization/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Component|middle-end |tree-optimization Last reconfirmed||2023-01-23 Status|UNCONFIRMED |NEW --- Comment #13 from Andrew Pinski --- Ok, this seems wrong: New sequence of 1 stores to replace old one of 10 stores # .MEM_102 = VDEF <.MEM_101> MEM [(void *)] = "\x02\x00\xff\x03\x00\x01\x02\x03"; Exceeded original number of stmts (2). Not profitable to emit new sequence. The size should be 9 rather 8 ...
[Bug c++/108504] New: [13 Regression] ICE in cp_lexer_handle_early_pragma, at cp/parser.cc:675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108504 Bug ID: 108504 Summary: [13 Regression] ICE in cp_lexer_handle_early_pragma, at cp/parser.cc:675 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 between 20220703 and 20220710 : $ cat z1.cc "1" #pragma omp target $ g++-13-20230122 -c z1.cc -fopenmp z1.cc:2:9: internal compiler error: in cp_lexer_handle_early_pragma, at cp/parser.cc:675 2 | #pragma omp target | ^~~ 0x90d288 cp_lexer_handle_early_pragma ../../gcc/cp/parser.cc:675 0x90d288 cp_lexer_new_main ../../gcc/cp/parser.cc:734 0x90d288 c_parse_file() ../../gcc/cp/parser.cc:49398 0x9f4e01 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1248
[Bug c++/108503] New: [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503
Bug ID: 108503
Summary: [13 Regression] ICE in get_array_or_vector_nelts, at
cp/constexpr.cc:4119
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 between 20221127 and 20221204 :
$ cat z1.cc
namespace std {
template struct tuple_size;
template struct tuple_element;
}
struct A {
template int& get() { return 1; }
};
template<> struct std::tuple_size { static const int value = 3; };
template struct std::tuple_element { using type = int; };
struct B {
A *begin();
A *end();
};
void f (B a)
{
#pragma omp for collapse(2)
for (auto [i, j, k] : a)
for (int l = i; l < j; l += k)
;
}
$ g++-13-20230122 -c z1.cc -fopenmp -Wall
z1.cc: In member function 'int& A::get()':
z1.cc:6:40: error: cannot bind non-const lvalue reference of type 'int&' to an
rvalue of type 'int'
6 | template int& get() { return 1; }
|^
z1.cc: In function 'void f(B)':
z1.cc:18:25: internal compiler error: in get_array_or_vector_nelts, at
cp/constexpr.cc:4119
18 | for (int l = i; l < j; l += k)
| ^
0x88770e get_array_or_vector_nelts
../../gcc/cp/constexpr.cc:4119
0x887804 eval_and_check_array_index
../../gcc/cp/constexpr.cc:4171
0x88b5e9 cxx_eval_array_reference
../../gcc/cp/constexpr.cc:4208
0x8826ed cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:7516
0x880e9a cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:7042
0x8837ac cxx_eval_indirect_ref
../../gcc/cp/constexpr.cc:5642
0x8837ac cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:7358
0x88d3ba cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:8252
0x892882 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.cc:8527
0x956053 fold_for_warn(tree_node*)
../../gcc/cp/expr.cc:421
0xc1d801 warn_tautological_cmp(op_location_t const&, tree_code, tree_node*,
tree_node*)
../../gcc/c-family/c-warn.cc:485
0x84369b build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:7354
0xb485cd build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../gcc/cp/typeck.cc:4722
0xa1c40f cp_parser_omp_for_cond
../../gcc/cp/parser.cc:42701
0xa1c40f cp_parser_omp_for_loop
../../gcc/cp/parser.cc:43652
0xa410f6 cp_parser_omp_for
../../gcc/cp/parser.cc:44005
0xa56f14 cp_parser_omp_construct
../../gcc/cp/parser.cc:48527
0xa20a7f cp_parser_pragma
../../gcc/cp/parser.cc:49207
0xa2740c cp_parser_statement
../../gcc/cp/parser.cc:12434
0xa28884 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12909
[Bug fortran/108502] New: ICE in gfc_check_dependency, at fortran/dependency.cc:1295
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108502 Bug ID: 108502 Summary: ICE in gfc_check_dependency, at fortran/dependency.cc:1295 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 integer function n() integer :: a(1) a = [1] / 0 end program p integer :: b = n() end $ cat z3.f90 integer function n() implicit none integer :: a(1) a = [1] / 0 n = 1 end program p implicit none integer :: n integer :: b = n() end $ cat z5.f90 integer function n() implicit none integer :: a(1) a = [1] / 0 n = 1 end program p integer, parameter :: b = n() end $ gfortran-13-20230122 -c z1.f90 -O2 f951: internal compiler error: Segmentation fault 0xdaa49f crash_signal ../../gcc/toplev.cc:314 0x86f6e1 gfc_check_dependency(gfc_expr*, gfc_expr*, bool) ../../gcc/fortran/dependency.cc:1295 0x86f70a gfc_check_dependency(gfc_expr*, gfc_expr*, bool) ../../gcc/fortran/dependency.cc:1298 0x90be8b optimize_assignment ../../gcc/fortran/frontend-passes.cc:1684 0x90be8b optimize_code ../../gcc/fortran/frontend-passes.cc:329 0x90f679 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.cc:5352 0x910a2a optimize_namespace ../../gcc/fortran/frontend-passes.cc:1479 0x910e7f gfc_run_passes(gfc_namespace*) ../../gcc/fortran/frontend-passes.cc:169 0x8417a8 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17673 0x841bab gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:2635 0x841bab resolve_global_procedure ../../gcc/fortran/resolve.cc:2637 0x838a66 resolve_function ../../gcc/fortran/resolve.cc:3306 0x838a66 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7195 0x7c77a4 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.cc:3168 0x7ca700 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.cc:3216 0x7b442b variable_decl ../../gcc/fortran/decl.cc:3036 0x7b442b gfc_match_data_decl() ../../gcc/fortran/decl.cc:6343 0x8215d3 match_word ../../gcc/fortran/parse.cc:67 0x8215d3 decode_statement ../../gcc/fortran/parse.cc:378 0x82301a next_free ../../gcc/fortran/parse.cc:1403
[Bug fortran/108501] New: [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 Bug ID: 108501 Summary: [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20221218 and 20230108 : $ cat z1.f90 program p real, parameter :: n = 2 real :: a(1,(n),2) call s(a(:,:,1)) end subroutine s(x) real :: x(2) end $ gfortran-13-20230122 -c z1.f90 z1.f90:3:15: 3 |real :: a(1,(n),2) | 1 Error: Expression at (1) must be of INTEGER type, found REAL z1.f90:3:21: 3 |real :: a(1,(n),2) | 1 Error: The module or main program array 'a' at (1) must have constant shape f951: internal compiler error: Segmentation fault 0xf8a79f crash_signal ../../gcc/toplev.cc:314 0x848fd9 get_expr_storage_size ../../gcc/fortran/interface.cc:2941 0x848fd9 gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*, int, int, bool, locus*) ../../gcc/fortran/interface.cc:3327 0x9b3136 check_externals_procedure ../../gcc/fortran/frontend-passes.cc:5742 0x9b7e29 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.cc:5352 0x9b968b gfc_check_externals0 ../../gcc/fortran/frontend-passes.cc:5861 0x9ba614 gfc_check_externals(gfc_namespace*) ../../gcc/fortran/frontend-passes.cc:5883 0x89f2c0 gfc_parse_file() ../../gcc/fortran/parse.cc:6942 0x8edd9f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #12 from Andrew Pinski --- (In reply to Adam Stylinski from comment #11) > It's possible's a glibc bug and clang avoids it by simply not needing it but > it seems doubtful a small memcpy like this would have an issue that didn't > show up until now. It seems like if it did need a memcpy, GCC would invoke > it's builtin for a struct like like this rather than call into a library > function. Is there a compilation flag I can invoke to rule that out? Like > some sort of "only builtins"? No I misread the generated code. I missed there is a store missing. store to offset 124 is missing I think.
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #11 from Adam Stylinski --- (In reply to Andrew Pinski from comment #9) > The only thing is memcpy could be broken ... > > I can't find anything wrong with the generated code. > > > 17cc: 38 a0 00 44 li r5,68 > ... > 17d8: 3c 00 02 00 lis r0,512 > 17dc: 60 00 ff 03 ori r0,r0,65283 > 17e0: 78 00 07 c6 sldir0,r0,32 > 17e4: 64 00 00 01 orisr0,r0,1 > 17e8: 60 00 02 03 ori r0,r0,515 > ... > 17fc: 38 81 00 74 addir4,r1,116 > ... > 180c: 7c 7f 1b 78 mr r31,r3 > ... > 1818: f8 01 00 74 std r0,116(r1) > ... > 182c: 4b ff fd 15 bl 1540 > <003b.plt_call.memcpy@@GLIBC_2.3> > ... > > > > > > On the main side: > addi %r3,%r1,116 > ld %r9,-28688(%r13) > std %r9,184(%r1) > li %r9,0 > bl emit_test > lwz %r4,124(%r1) It's possible's a glibc bug and clang avoids it by simply not needing it but it seems doubtful a small memcpy like this would have an issue that didn't show up until now. It seems like if it did need a memcpy, GCC would invoke it's builtin for a struct like like this rather than call into a library function. Is there a compilation flag I can invoke to rule that out? Like some sort of "only builtins"?
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #10 from Andrew Pinski --- oh wait there is no store to 124 ...
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #9 from Andrew Pinski --- The only thing is memcpy could be broken ... I can't find anything wrong with the generated code. 17cc: 38 a0 00 44 li r5,68 ... 17d8: 3c 00 02 00 lis r0,512 17dc: 60 00 ff 03 ori r0,r0,65283 17e0: 78 00 07 c6 sldir0,r0,32 17e4: 64 00 00 01 orisr0,r0,1 17e8: 60 00 02 03 ori r0,r0,515 ... 17fc: 38 81 00 74 addir4,r1,116 ... 180c: 7c 7f 1b 78 mr r31,r3 ... 1818: f8 01 00 74 std r0,116(r1) ... 182c: 4b ff fd 15 bl 1540 <003b.plt_call.memcpy@@GLIBC_2.3> ... On the main side: addi %r3,%r1,116 ld %r9,-28688(%r13) std %r9,184(%r1) li %r9,0 bl emit_test lwz %r4,124(%r1)
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102343 --- Comment #18 from Iain Sandoe --- there are still fixes needed - to the passing of parameters to C preprocessor jobs that ensures the multilib settings are correct there .. see PR102343 for the candidate patch.
[Bug modula2/108405] modula-2: Testsuite fails: concurrentstore.mod, contimer.mod, tinytimer.mod on Darwin (and likely elsewhere)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Sandoe --- so fixed on trunk.
[Bug c/108500] New: -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 Bug ID: 108500 Summary: -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhekir at gmail dot com Target Milestone: --- Created attachment 54328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54328=edit compressed version of a simplified program causing the ICE In the attached preprocessed program (compressed with .tar.gz), running 'gcc -O -finline-small-functions' results in: gcc: internal compiler error: Segmentation fault signal terminated program cc1 The original program is more interesting than this simplified version. Still, it does have more than 700k function calls in the main function, which is causing the problem. The original command line was simply 'gcc -O2', then I narrowed the options down to -finline-small-functions. I tried several GCC Docker images (running 'gcc -O2' on the attached file), and I narrowed it down to: - with gcc:10.4 (or older), compilation works without any errors; - with gcc:11.1 (or newer; I tested up to 12.2.0), segmentation fault happens.
[Bug modula2/108480] gm2 fails to find SYSTEM module after relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108480 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:47b269caf87904fd0112e8c9e96884dd0313ed15 commit r13-5308-g47b269caf87904fd0112e8c9e96884dd0313ed15 Author: Iain Sandoe Date: Wed Jan 11 10:22:34 2023 + modula-2, driver, Front end: Revise handling of I and L paths [PR108182]. The adds the includes in the FE as done in other GCC languages. It also revises the library handling to avoid additional -L options from hiding LIBDIR. For the include/import paths as presented to the front end initialisation, we capture them and then arrange to emit the 'standard library' paths in the same order as specified for C. The specs are tidied up. The use of the internal prefix also fixes searching in a relocated compiler. Signed-off-by: Iain Sandoe PR modula2/108182 PR modula2/108480 gcc/m2/ChangeLog: * Make-lang.in: Pass libsubdir to the language init build. * gm2-lang.cc (INCLUDE_VECTOR): Define. (add_one_import_path): New. (add_m2_import_paths): New. (gm2_langhook_post_options): Arrange to add the include paths (and add the system ones) in the same order as C uses. * gm2spec.cc (build_archive_path): Remove. (add_default_combination): Remove. (add_default_archives): Remove. (add_default_libs): We no longer need a '-L' option, just emit the -l and each library in use. (build_include_path): Remove. (add_include): Remove. (add_default_includes): Remove. (library_installed): Remove. (check_valid_library): Remove. (check_valid_list): Remove. (convert_abbreviation): Diagnose unhandled cases. (lang_specific_driver): Skip options where we will add back a validated version. * lang-specs.h (M2CPP): Reformat, append %I when -fcpp is not in use. Revise the cc1gm2 spec to omit mentioning options that are handled in the c pre-processor line. * lang.opt: Allow preprocessing and path options as input to the cc1gm2 invocation, so that they can be passed to the preprocessor invocation.
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #17 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:47b269caf87904fd0112e8c9e96884dd0313ed15 commit r13-5308-g47b269caf87904fd0112e8c9e96884dd0313ed15 Author: Iain Sandoe Date: Wed Jan 11 10:22:34 2023 + modula-2, driver, Front end: Revise handling of I and L paths [PR108182]. The adds the includes in the FE as done in other GCC languages. It also revises the library handling to avoid additional -L options from hiding LIBDIR. For the include/import paths as presented to the front end initialisation, we capture them and then arrange to emit the 'standard library' paths in the same order as specified for C. The specs are tidied up. The use of the internal prefix also fixes searching in a relocated compiler. Signed-off-by: Iain Sandoe PR modula2/108182 PR modula2/108480 gcc/m2/ChangeLog: * Make-lang.in: Pass libsubdir to the language init build. * gm2-lang.cc (INCLUDE_VECTOR): Define. (add_one_import_path): New. (add_m2_import_paths): New. (gm2_langhook_post_options): Arrange to add the include paths (and add the system ones) in the same order as C uses. * gm2spec.cc (build_archive_path): Remove. (add_default_combination): Remove. (add_default_archives): Remove. (add_default_libs): We no longer need a '-L' option, just emit the -l and each library in use. (build_include_path): Remove. (add_include): Remove. (add_default_includes): Remove. (library_installed): Remove. (check_valid_library): Remove. (check_valid_list): Remove. (convert_abbreviation): Diagnose unhandled cases. (lang_specific_driver): Skip options where we will add back a validated version. * lang-specs.h (M2CPP): Reformat, append %I when -fcpp is not in use. Revise the cc1gm2 spec to omit mentioning options that are handled in the c pre-processor line. * lang.opt: Allow preprocessing and path options as input to the cc1gm2 invocation, so that they can be passed to the preprocessor invocation.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #25 from Andrew Macleod --- Created attachment 54327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54327=edit possible patch There's another infrastructure patch which precedes this one which turns existing relation_union and relation_intersection calls into union_ and intersection calls through the value_relation class.THen we can isolate all the union and intersection calls in one place. This patch introduces VREL_OTHER and adjusts intersection and union to produce it as appropriate only if the operands are floating point. if intersection produces UNDEFINED and either of the relations feeding it were <, <=, >, or >= then it turns it to VR_OTHER. the prevents false sides of branches from combining to produce UNDEFINED when they end up being a known NAN. Union is adjusted such that < >, or <= >= also produce VREL_OTHER. < > cannot be properly represented, and <= >= was producing VARYING, which is also not correct. Does this cover things sufficiently? The test case correctly compiles and runs now (I think :-) I am running builds/tests now and will post the complete patchset when complete.
[Bug modula2/108405] modula-2: Testsuite fails: concurrentstore.mod, contimer.mod, tinytimer.mod on Darwin (and likely elsewhere)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405 --- Comment #4 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:bcc023e2b4dd0dc1fd1fca3ea12664d5bdade4dc commit r13-5307-gbcc023e2b4dd0dc1fd1fca3ea12664d5bdade4dc Author: Iain Sandoe Date: Sat Jan 14 10:20:47 2023 + modula-2: Fix stack size request in initPreemptive [PR108405] As noted in the PR, the problem is that we make a request for additional stack that violates the constraints on some systems. This patch chooses a value that is divisible by common OS page sizes. TODO: the user value should be checked and then an exception thrown if it is not suitable. Signed-off-by: Iain Sandoe PR modula2/108405 gcc/m2/ChangeLog: * gm2-libs-iso/Preemptive.mod (initPreemptive): Use a value for extra space that is divisible by common OS pagesizes.
[Bug target/107678] [13 Regression] Segfault in aarch64_fallback_frame_state when running SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Wilco --- Fixed
[Bug c/108476] Please turn -Wreturn-type on by default for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476 --- Comment #3 from Alex Henrie --- (In reply to Andrew Pinski from comment #1) > Note the warning should really be split into two different options. One for > the return type of the declaration and one for the missing return in > non-void case. That would be nice, I agree. I'd just like to note that since the warning should occur by default in both situations, this feature request does not depend on splitting the warning in two. (In reply to Jakub Jelinek from comment #2) > The reason it is enabled by default for C++ is that the 2 languages differ > significantly in this regard. Falling through the end of a non-void > function in C++ is undefined behavior, in C it is not, in C it is only UB if > the caller actually uses the uninitialized return value (which is much > harder to warn about). Yes, I did read the note about that in the documentation (although I didn't quote that part in comment #0). You're right that it's slightly less bad in C because not specifying the return value is immediately undefined behavior in C++, whereas in C it only becomes undefined behavior once the return value is used. However, few people know about that subtle difference between C and C++ (which leads to a false sense of security when the warning does not appear in C), and not specifying the return value will almost certainly lead to undefined behavior in C even though technically there are situations where it does not. > And in C it is enabled in -Wall, which you should use anyway if you care > about warnings. I do use -Wall whenever I can. Unfortunately, not everyone does (particularly novices or people stuck with awful embedded-toolchain IDEs that don't make it easy to change compiler settings), so I'd like the default to be both less confusing and more protective against likely undefined behavior.
[Bug analyzer/108432] Analyzer fails to detect out-of-bounds issues within loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432 --- Comment #2 from David Malcolm --- (In reply to Segher Boessenkool from comment #1) > Many warning messages are also dependent on optimisation level. And the > actual generated code is as well ;-) > > -O0 means do the least possible work to generate correct code. There is > friction between that and having -fanalyzer do deep inspection of the code. > I think we should document -fanalyzer needs some optimisation enabled (does > it need -O2 in some cases, or just -O1 always, btw?) > > The suggestion to at least check the last loop iteration is good of course. Unfortunately, some analyzer warnings work better with optimization *disabled*. -fanalyzer runs much later than most other static analyzers. For example, -Wanalyzer-deref-before-check doesn't work well with optimization, as the dereference means that that optimized can remove the checks before the analyzer "sees" them. I think there's a natural tension between optimization and detecting undefined behavior, in that -fanalyzer wants to report on possible undefined behavior, whereas optimization wants to take advantage of undefined behavior.
[Bug tree-optimization/108499] False positive -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108499 --- Comment #1 from Andrew Pinski --- Adding: if (!theSize) __builtin_unreachable(); After the declaration of theSize, fixes the warning. I don't know if in the original code there was a check for zero theSize or not but the warning disappears if there is. There is no way to figure out for the compiler that theSize is not zero either.
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #8 from Adam Stylinski --- Here's the code GCC emits: 17a0 <.emit_test>: 17a0: 7c 08 02 a6 mflrr0 17a4: fb e1 ff f8 std r31,-8(r1) 17a8: 3d 42 ff fe addis r10,r2,-2 17ac: 81 4a 8a 08 lwz r10,-30200(r10) 17b0: 38 80 00 00 li r4,0 17b4: 39 20 00 00 li r9,0 17b8: 39 60 00 01 li r11,1 17bc: 38 c0 00 02 li r6,2 17c0: 38 e0 00 04 li r7,4 17c4: 79 4a c1 e4 sldir10,r10,24 17c8: 39 00 00 08 li r8,8 17cc: 38 a0 00 44 li r5,68 17d0: f8 01 00 10 std r0,16(r1) 17d4: f8 21 ff 31 stdur1,-208(r1) 17d8: 3c 00 02 00 lis r0,512 17dc: 60 00 ff 03 ori r0,r0,65283 17e0: 78 00 07 c6 sldir0,r0,32 17e4: 64 00 00 01 orisr0,r0,1 17e8: 60 00 02 03 ori r0,r0,515 17ec: eb ed 8f f0 ld r31,-28688(r13) 17f0: fb e1 00 b8 std r31,184(r1) 17f4: 3b e0 00 00 li r31,0 17f8: f8 81 00 a8 std r4,168(r1) 17fc: 38 81 00 74 addir4,r1,116 1800: f9 41 00 b0 std r10,176(r1) 1804: 99 21 00 80 stb r9,128(r1) 1808: 99 21 00 88 stb r9,136(r1) 180c: 7c 7f 1b 78 mr r31,r3 1810: 99 21 00 a8 stb r9,168(r1) 1814: 91 21 00 ac stw r9,172(r1) 1818: f8 01 00 74 std r0,116(r1) 181c: 91 61 00 84 stw r11,132(r1) 1820: 90 c1 00 8c stw r6,140(r1) 1824: 98 e1 00 98 stb r7,152(r1) 1828: 91 01 00 9c stw r8,156(r1) 182c: 4b ff fd 15 bl 1540 <003b.plt_call.memcpy@@GLIBC_2.3> 1830: e8 41 00 28 ld r2,40(r1) 1834: e9 41 00 b8 ld r10,184(r1) 1838: e9 2d 8f f0 ld r9,-28688(r13) 183c: 7d 4a 4a 79 xor.r10,r10,r9 1840: 39 20 00 00 li r9,0 1844: 40 82 00 1c bne 1860 <.emit_test+0xc0> 1848: 38 21 00 d0 addir1,r1,208 184c: 7f e3 fb 78 mr r3,r31 1850: e8 01 00 10 ld r0,16(r1) 1854: eb e1 ff f8 ld r31,-8(r1) 1858: 7c 08 03 a6 mtlrr0 185c: 4e 80 00 20 blr 1860: 4b ff fd 41 bl 15a0 <003b.plt_call.__stack_chk_fail@@GLIBC_2.4> 1864: e8 41 00 28 ld r2,40(r1) 1868: 00 00 00 00 .long 0x0 186c: 00 00 00 01 .long 0x1 1870: 80 01 00 00 lwz r0,0(r1) 1874: 60 00 00 00 nop 1878: 00 00 00 00 .long 0x0 187c: 00 01 f7 78 .long 0x1f778
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #7 from Adam Stylinski --- Err wait, my bad, I had added the workaround in that source code. The bug still exists when I take out that pragma to push no store-merging. adam@g5box ~ $ valgrind ./test.out ==27014== Memcheck, a memory error detector ==27014== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==27014== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==27014== Command: ./test.out ==27014== ==27014== Use of uninitialised value of size 8 ==27014==at 0x415B8C8: _itoa_word (in /lib64/libc.so.6) ==27014==by 0x4167BE3: __vfprintf_internal (in /lib64/libc.so.6) ==27014==by 0x15F7: main (in /home/adam/test.out) ==27014== ==27014== Conditional jump or move depends on uninitialised value(s) ==27014==at 0x415B8D0: _itoa_word (in /lib64/libc.so.6) ==27014==by 0x4167BE3: __vfprintf_internal (in /lib64/libc.so.6) ==27014==by 0x15F7: main (in /home/adam/test.out) ==27014== ==27014== Conditional jump or move depends on uninitialised value(s) ==27014==at 0x41683F4: __vfprintf_internal (in /lib64/libc.so.6) ==27014==by 0x4252C13: __printf_chk@@GLIBC_2.4 (in /lib64/libc.so.6) ==27014==by 0x15F7: main (in /home/adam/test.out) ==27014== ==27014== Conditional jump or move depends on uninitialised value(s) ==27014==at 0x4168FA8: __vfprintf_internal (in /lib64/libc.so.6) ==27014==by 0x4252C13: __printf_chk@@GLIBC_2.4 (in /lib64/libc.so.6) ==27014==by 0x15F7: main (in /home/adam/test.out) ==27014== sat? = 0 ==27014== ==27014== HEAP SUMMARY: ==27014== in use at exit: 0 bytes in 0 blocks ==27014== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==27014== ==27014== All heap blocks were freed -- no leaks are possible ==27014== ==27014== Use --track-origins=yes to see where uninitialised values come from ==27014== For lists of detected and suppressed errors, rerun with: -s ==27014== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) adam@g5box ~ $ ./test.out sat? = 1
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #6 from Adam Stylinski --- (In reply to Richard Biener from comment #5) > maybe a stack sharing issue? Can you try -fstack-reuse=none? So that does fix it, at least when the struct is backed by the stack. And also valgrind is no longer finding uninitialized memory being used: adam@g5box ~ $ gcc -O2 -fstack-reuse=none bug_rep2.c -o test.out adam@g5box ~ $ ./test.out sat? = 0 adam@g5box ~ $ valgrind ./test.out ==26982== Memcheck, a memory error detector ==26982== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==26982== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==26982== Command: ./test.out ==26982== sat? = 0 ==26982== ==26982== HEAP SUMMARY: ==26982== in use at exit: 0 bytes in 0 blocks ==26982== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==26982== ==26982== All heap blocks were freed -- no leaks are possible ==26982== ==26982== For lists of detected and suppressed errors, rerun with: -s ==26982== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Not sure what it might do if backed by the heap, but the code is written in a way that it initializes the struct on the stack, anyway.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- I think so.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- Fixed?
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||powerpc64 --- Comment #5 from Richard Biener --- maybe a stack sharing issue? Can you try -fstack-reuse=none?
[Bug middle-end/108498] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #4 from Adam Stylinski --- Also I strongly suspect valgrind is correctly identifying the unitialized bits because the underlying bug it produces is a "sometimes" bug, depending on what's on the heap. Sometimes insn.sat is 0 (when it behaves correctly), sometimes it's 1 (black screen).
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 --- Comment #1 from Segher Boessenkool --- This error is from sysv4.h SUBTARGET_OVERRIDE_OPTIONS. -msecure-plt is unconditionally required. It looks like an oversight that it is not required in the assembler you used (which is that?)
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-23 Status|UNCONFIRMED |WAITING --- Comment #3 from Andrew Pinski --- Did you compile binutils first? Are you doing a combined build?
[Bug c++/108499] New: False positive -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108499
Bug ID: 108499
Summary: False positive -Warray-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steveire at gmail dot com
Target Milestone: ---
```
#include
class MyStruct
{
public:
std::vector const& refAccessor();
std::size_t getSize();
};
void emitsWarning()
{
MyStruct params;
auto unusedThing = params.refAccessor();
(void)unusedThing;
auto const theSize = params.getSize();
std::vector initialVelocities(theSize, 0.0);
initialVelocities.back() = 6;
std::vector initialJoints(theSize, 0.0);
initialJoints.back() = 5;
}
```
-Werror=array-bounds -O2
```
: In function 'void emitsWarning()':
:20:27: error: array subscript -1 is outside array bounds of 'double
[1152921504606846975]' [-Werror=array-bounds]
20 | initialVelocities.back() = 6;
| ~~^~
cc1plus: some warnings being treated as errors
Compiler returned: 1
```
https://gcc.godbolt.org/z/sYrK6o54a
