[Bug c++/87497] constexprs involving non-literal const variables are incorrectly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87497
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Andrew Pinski ---
Seems to be fixed on the trunk.
I get now:
: In function 'void g()':
:3:63: in 'constexpr' expansion of 'foo(local_s)'
:3:71: error: the value of 'local_s' is not usable in a constant
expression
3 | void g () { const s local_s = { 1, 2 }; constexpr int a = foo
(local_s); }
| ^
:3:21: note: 'local_s' was not declared 'constexpr'
3 | void g () { const s local_s = { 1, 2 }; constexpr int a = foo
(local_s); }
| ^~~
[Bug c/106560] [12/13 Regression] ICE after conflicting types of redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|12.3|13.0 Status|ASSIGNED|RESOLVED --- Comment #10 from Andrew Pinski --- Fixed.
[Bug c/106560] [12/13 Regression] ICE after conflicting types of redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106560 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b03ad138a61f64d8a77876d6864aad5103fff498 commit r13-4181-gb03ad138a61f64d8a77876d6864aad5103fff498 Author: Andrew Pinski Date: Sat Nov 19 12:48:27 2022 -0800 Fix PR 106560: Another ICE after conflicting types of redeclaration This another one of these ICE after error issues with the gimplifier and a fallout from r12-3278-g823685221de986af. The problem here is gimplify_modify_expr does not check if either from or to was an error operand. This adds the check and fixes the ICE. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * gimplify.cc (gimplify_modify_expr): If either *from_p or *to_p were error_operand return early. gcc/testsuite/ChangeLog: * gcc.dg/redecl-23.c: New test. * gcc.dg/redecl-24.c: New test. * gcc.dg/redecl-25.c: New test.
[Bug c++/99772] New built-ins for comparisons that must yield a total order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99772 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-21 --- Comment #1 from Andrew Pinski --- .
[Bug analyzer/107783] New: [13 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:3238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107783
Bug ID: 107783
Summary: [13 Regression] ICE in deref_rvalue, at
analyzer/region-model.cc:3238
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20221120 snapshot (g:a16a5460447eaaff0b4468064e4d7b1cc8fc42eb) ICEs
when compiling the following testcase w/ -fanalyzer:
int
foo (void)
{
return bind (0, 0, 0);
}
% gcc-13 -fanalyzer -w -c oerlsfmf.c
during IPA pass: analyzer
oerlsfmf.c: In function 'foo':
oerlsfmf.c:4:10: internal compiler error: in deref_rvalue, at
analyzer/region-model.cc:3238
4 | return bind (0, 0, 0);
| ^~
0x7bd370 ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:3238
0x13091e4 check_for_new_socket_fd
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:1785
0x130b16d on_bind
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:1848
0x130b16d ana::region_model::on_bind(ana::call_details const&, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:2284
0x12e7646 ana::kf_bind::outcome_of_bind::update_model(ana::region_model*,
ana::exploded_edge const*, ana::region_model_context*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model-impl-calls.cc:630
0x12a8cee ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:4170
0x12a984a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:3457
0x12abfd4 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:6110
0x12acfd6 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:6198
0x129b8d8 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/analyzer-pass.cc:87
[Bug c++/107782] New: constexpr volatile variable is permitted to appear in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107782
Bug ID: 107782
Summary: constexpr volatile variable is permitted to appear in
a constant expression
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
int main() {
constexpr volatile int i = 0;
constexpr volatile int j = i;
return j;
}
is properly rejected by Clang since according to
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4093.html#1688
constexpr volatile variable cannot appear in a constant expression.
Unfortunately GCC (and MSVC) accept invalid program. Online demo:
https://gcc.godbolt.org/z/43ee65Peq
Related discussion: https://stackoverflow.com/q/74511594/7325599
[Bug c++/107781] New: strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107781 Bug ID: 107781 Summary: strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- I do canadian compilation and it fails due to contracts.cc ../../../../../gcc/gcc/cp/contracts.cc: In function 'bool role_name_equal(const char*, const char*)': ../../../../../gcc/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not declared in this scope; did you mean 'strchr'? 213 | size_t role_len = strchrnul (role, ':') - role; | ^ | strchr
[Bug c++/107780] New: strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107780 Bug ID: 107780 Summary: strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- I do canadian compilation and it fails due to contracts.cc ../../../../../gcc/gcc/cp/contracts.cc: In function 'bool role_name_equal(const char*, const char*)': ../../../../../gcc/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not declared in this scope; did you mean 'strchr'? 213 | size_t role_len = strchrnul (role, ':') - role; | ^ | strchr
[Bug lto/107779] Support implicit references from inline assembler to compiler symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||inline-asm --- Comment #1 from Andrew Pinski --- There are better ways of solving this. One way is to have top level inline-asm accept input operands and use that. Plus if I read this code, it only works with x86 inlineasm but it is generic part of the compiler, a huge issue. Amd no documentation either. Inline-asm is already not well documented and now adding even more is not helping.
[Bug lto/107779] New: Support implicit references from inline assembler to compiler symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 Bug ID: 107779 Summary: Support implicit references from inline assembler to compiler symbols Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org, mliska at suse dot cz Target Milestone: --- Created attachment 53933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53933=edit prototype patch So I looked into the problem the kernel people complained about: a lot of assembler statements reference C symbols, which need externally_visible and global for gcc LTO, otherwise they can end up in the wrong asm file and cause missing symbols. I came up with the attached (hackish) patch that tries to solve the problem very partially: it parses the assembler strings and looks for anything that could be an identifier, and then tries to mark it externally_visible. It has the following open issues: - The parsing is very approximate and doesn't handle some obscure cases. With the approximation it's also impossible to give error messages, but hopefully the linker takes care of that. It also gives false positives with some assembler syntax, but in the worst case would just lose some optimization from unnecessary references. - It doesn't handle the case (which happens in the kernel) that the C declaration is after the asm statement. This could be fixed with some more effort. - It doesn't work for static which can get mangled (that's a lot of the kernel cases) static is a difficult problem because there could be conflicting names, so we cannot jut put it all in partition zero. This would need some special handling in the LTO partitioning code to create new partitions just for having unique name spaces, and then avoid mangling. Related problem is also PR50676 It's likely possible to create situations where it's impossible to solve, there could be circular dependencies etc. But I assume in this case the non LTO case would fail too. Or maybe do something with redefining symbols at the assembler level. This one is somewhat difficult and I don't have a simple solution currently. Unfortunately to solve the kernel issue would need a solution for static.
[Bug tree-optimization/107766] [13 Regression] ICE Segmentation fault since r13-4137-gc5df8392c5848c04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107766 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Richard Biener --- Testing a patch.
[Bug tree-optimization/91470] [10/11/12 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #10 from Richard Biener --- I wonder what exactly fixed it.
[Bug tree-optimization/67196] [10/11/12 Regression] loop-induced false positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196 Richard Biener changed: What|Removed |Added Known to work||13.0 Keywords||needs-bisection --- Comment #10 from Richard Biener --- Confirmed that it works, the cited patch didn't fix it though(?), so I wonder what did.
[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > BTW. Why does the default contract does not crash program when it violates? Also why the function is not noexcept?
[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 --- Comment #2 from cqwrteur --- BTW. Why does the default contract does not crash program when it violates?
[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778
--- Comment #1 from cqwrteur ---
__attribute__ ((weak)) void
handle_contract_violation (const std::experimental::contract_violation &)
{
__builtin_trap();
}
some thing like that. I cannot afford stdio and iostream
[Bug libstdc++/107778] New: handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 Bug ID: 107778 Summary: handle_contract_violation should reflect _GLIBCXX_VERBOSE Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: ---
[Bug analyzer/107777] New: [13 Regression] ICE in get_representative_path_var_1, at analyzer/region-model.cc:4750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: [13 Regression] ICE in get_representative_path_var_1,
at analyzer/region-model.cc:4750
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20221120 snapshot (g:a16a5460447eaaff0b4468064e4d7b1cc8fc42eb) ICEs
when compiling the following testcase w/ -fanalyzer:
int *
__errno_location (void);
long int
read (int, void *, unsigned long int);
struct IOBUF {
int fd;
};
void
do_getline_end_data (struct IOBUF *iop, int tree)
{
char end_data;
if (tree)
*__errno_location () = 0;
read (iop->fd, _data, sizeof end_data);
}
% gcc-13 -fanalyzer -c ofd9impz.c
during IPA pass: analyzer
ofd9impz.c: In function 'do_getline_end_data':
ofd9impz.c:19:3: internal compiler error: in get_representative_path_var_1, at
analyzer/region-model.cc:4750
19 | read (iop->fd, _data, sizeof end_data);
| ^~
0x7bd41c ana::region_model::get_representative_path_var_1(ana::region const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4750
0x12cbbd8 ana::region_model::get_representative_path_var(ana::region const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4896
0x131dc1f ana::binding_cluster::get_representative_path_vars(ana::region_model
const*, hash_set >*, ana::region const*, ana::svalue const*, auto_vec*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/store.cc:2111
0x131e7e8 ana::store::get_representative_path_vars(ana::region_model const*,
hash_set >*,
ana::svalue const*, auto_vec*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/store.cc:2987
0x12cb1a8 ana::region_model::get_representative_path_var_1(ana::svalue const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4626
0x12cb501 ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4693
0x12cb501 ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4685
0x12cb501 ana::region_model::get_representative_tree(ana::svalue const*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/region-model.cc:4712
0x12add04 ana::impl_sm_context::get_diagnostic_tree(tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:433
0x13089ef check_for_open_fd
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:1550
0x1309cfc on_read
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:1533
0x1309cfc on_stmt
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/sm-fd.cc:1246
0x12a590f ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:1485
0x12a8895 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:4054
0x12a984a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:3457
0x12abfd4 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:6110
0x12acfd6 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/engine.cc:6198
0x129b8d8 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/analyzer/analyzer-pass.cc:87
[Bug tree-optimization/107776] New: [13 Regression] ICE: SIGSEGV in complex_mul_pattern::matches (tree-vect-slp-patterns.cc:1042) with -O2 -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107776 Bug ID: 107776 Summary: [13 Regression] ICE: SIGSEGV in complex_mul_pattern::matches (tree-vect-slp-patterns.cc:1042) with -O2 -std=c11 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: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 53932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53932=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -ffp-contract=off testcase.c -wrapper valgrind,-q ==31587== Invalid read of size 2 ==31587==at 0x165C620: complex_mul_pattern::matches(_complex_operation, hash_map<_slp_tree*, _complex_perm_kinds, simple_hashmap_traits, _complex_perm_kinds> >*, hash_map, nofree_ptr_hash<_slp_tree> >, bool, simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**, vec<_slp_tree*, va_heap, vl_ptr>*) [clone .part.0] (tree-vect-slp-patterns.cc:1042) ==31587==by 0x165D6E3: matches (tree-vect-slp-patterns.cc:1023) ==31587==by 0x165D6E3: complex_operations_pattern::recognize(hash_map<_slp_tree*, _complex_perm_kinds, simple_hashmap_traits, _complex_perm_kinds> >*, hash_map, nofree_ptr_hash<_slp_tree> >, bool, simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**) (tree-vect-slp-patterns.cc:1424) ==31587==by 0x16481FF: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, _complex_perm_kinds, simple_hashmap_traits, _complex_perm_kinds> >*, hash_map, nofree_ptr_hash<_slp_tree> >, bool, simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.cc:3010) ==31587==by 0x16481C5: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, _complex_perm_kinds, simple_hashmap_traits, _complex_perm_kinds> >*, hash_map, nofree_ptr_hash<_slp_tree> >, bool, simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.cc:3003) ==31587==by 0x1649557: vect_match_slp_patterns (tree-vect-slp.cc:3042) ==31587==by 0x1649557: vect_analyze_slp(vec_info*, unsigned int) (tree-vect-slp.cc:3533) ==31587==by 0x1653A6F: vect_slp_analyze_bb_1 (tree-vect-slp.cc:7317) ==31587==by 0x1653A6F: vect_slp_region(vec, vec, vec*, unsigned int, loop*) (tree-vect-slp.cc:7419) ==31587==by 0x165574C: vect_slp_bbs(vec const&, loop*) (tree-vect-slp.cc:7610) ==31587==by 0x16559C6: vect_slp_function(function*) (tree-vect-slp.cc:7698) ==31587==by 0x165E611: (anonymous namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.cc:1532) ==31587==by 0x1296F9A: execute_one_pass(opt_pass*) (passes.cc:2644) ==31587==by 0x129788F: execute_pass_list_1(opt_pass*) (passes.cc:2753) ==31587==by 0x12978A1: execute_pass_list_1(opt_pass*) (passes.cc:2754) ==31587== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31587== during GIMPLE pass: slp testcase.c: In function 'foo': testcase.c:6:1: internal compiler error: Segmentation fault 6 | foo (void) | ^~~ 0x139f4af crash_signal /repo/gcc-trunk/gcc/toplev.cc:314 ... $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4175-20221120174242-g6b5c98c1c00-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-4175-20221120174242-g6b5c98c1c00-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20221118 (experimental) (GCC)
[Bug c++/107764] -Wreturn-type and -Wuninitialized documentation could link to a FAQ about enum and switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107764 Eric Gallager changed: What|Removed |Added Last reconfirmed||2022-11-21 CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Yeah this is definitely one I've noticed before; confirmed.
[Bug rtl-optimization/107775] New: misoptimization in vec_set lower part of vector in the memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107775
Bug ID: 107775
Summary: misoptimization in vec_set lower part of vector in the
memory.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
The case is found when i'm looking at
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606373.html, currently
x86 gcc can optimize set_lower same as set_lower1, but not after adjusting in
can_change_mode_class. The issue can be reproduce with aarch64 gcc. I'm looking
at rtl dump, the main difference comes from subreg1, where currently it will
split 128-bit load/store into 2 64-bit load/stores which expose the opportunity
to optimize the upper 64-bit load/store off.
typedef double v2df __attribute__((vector_size(16)));
v2df reg;
void
set_lower (double b)
{
double v[2];
*((v2df*)[0]) = reg;
v[0] = b;
reg = *((v2df*)[0]);
}
void
set_lower1 (double b)
{
reg[0] = b;
}
[Bug rtl-optimization/107774] New: rtl failed to simplify subreg:vec_select to just vec_select.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107774 Bug ID: 107774 Summary: rtl failed to simplify subreg:vec_select to just vec_select. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com Target Milestone: --- When i'm looking at https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606373.html, I notice there's some misoptimization in rtl. It failed to simplift (subreg:SF (vec_select:V2SF (reg:V4SF) (parallel [(const_int 2) (const_int 3)]) 0) to just (vec_select:SF (reg:V4SF) (parallel [(const_int 2)]) The optimization is exposed after adjustment of ix86_can_change_mode_class, w/o that, i don't have a case to reproduce this issue. But I can think backends canonicalizing vec_select to subreg may have such issue.
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 Tamar Christina changed: What|Removed |Added Component|libstdc++ |libgcc --- Comment #11 from Tamar Christina --- So seems to be a libgcc issue rather than libstdc++.
[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #10 from Tamar Christina --- I've bisected this to: commit 6e80a1d164d1f996ad08a512c25a7c2ca893 Author: Thomas Neumann Date: Tue Mar 1 21:57:35 2022 +0100 eliminate mutex in fast path of __register_frame The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is somewhat expensive even if single-threaded. There was already a fast-path that avoided taking the mutex if no frame was registered at all. This commit eliminates both the mutex and the sorted list from the atomic fast path, and replaces it with a btree that uses optimistic lock coupling during lookup. This allows for fully parallel unwinding and is essential to scale exception handling to large core counts. libgcc/ChangeLog: * unwind-dw2-fde.c (release_registered_frames): Cleanup at shutdown. (__register_frame_info_table_bases): Use btree in atomic fast path. (__deregister_frame_info_bases): Likewise. (_Unwind_Find_FDE): Likewise. (base_from_object): Make parameter const. (classify_object_over_fdes): Add query-only mode. (get_pc_range): Compute PC range for lookup. * unwind-dw2-fde.h (last_fde): Make parameter const. * unwind-dw2-btree.h: New file. libgcc/unwind-dw2-btree.h | 953 ++ libgcc/unwind-dw2-fde.c | 194 +++--- libgcc/unwind-dw2-fde.h | 2 +- 3 files changed, 1098 insertions(+), 51 deletions(-) create mode 100644 libgcc/unwind-dw2-btree.h Looking at the patch it looks like it now forces an eager registration of objects during frame registration vs a lazy initialization that was there before.
[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:196cb25ddbc6c4fae5e7b1c0a09f32f59bdabaa8 commit r12-8922-g196cb25ddbc6c4fae5e7b1c0a09f32f59bdabaa8 Author: Jakub Jelinek Date: Sun Nov 20 17:42:42 2022 +0100 reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183] As the following testcase shows, the swap_rtx_condition function in reg-stack can result in different code generation between -g and -g0. The function is doing the changes as it goes, so does analysis and changes together, which makes it harder to deal with DEBUG_INSNs, where normally analysis phase ignores them and the later phase doesn't. swap_rtx_condition walks instructions two different ways, one is using next_flags_user function which stops on non-call instructions that mention the flags register, and the other is a loop on fnstsw where it stops on instructions mentioning it and tries to find sahf instruction that uses it (in both cases calls stop it and so does end of basic block). Now both of these currently stop on DEBUG_INSNs that mention the flags register resp. the fnstsw result register. On success the function recurses on next flags user instruction if still live and if the recursion failed, reverts the changes it did too and fails. If it were just for the next_flags_user case, the fix could be just not doing INSN_CODE (insn) = -1; if (recog_memoized (insn) == -1) fail = 1; on DEBUG_INSNs (assuming all changes to those are fine), swap_rtx_condition_1 just changes one comparison to a different one. But due to the possibility of fnstsw result being used in theory before sahf in some DEBUG_INSNs, this patch takes a different approach. swap_rtx_condition has now a new argument and two modes. The first mode is when debug_seen is >= 0, in this case both next_flags_user and the loop for fnstsw -> sahf will ignore but note DEBUG_INSNs (that mention flags register or fnstsw result). If no such DEBUG_INSN is found during the whole call including recursive invocations (so e.g. for -g0 but probably most often for -g as well), it behaves as before, if it returns true all the changes are done and nothing further needs to be done later. If any DEBUG_INSNs are seen along the way, even when returning success all the changes are reverted, so it just reports that the function would be successful if DEBUG_INSNs were ignored. In this case, compare_for_stack_reg needs to call it again in debug_seen = -1 mode, which tells the function to update everything including DEBUG_INSNs. For the fnstsw -> sahf case which I hope will be very rare I just reset the DEBUG_INSNs, I don't really know how to express it easily otherwise. For the rest swap_rtx_condition_1 is done even on the DEBUG_INSNs. 2022-11-20 Jakub Jelinek PR target/107183 * reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument. If >= 0 and a DEBUG_INSN would be otherwise returned, set DEBUG_SEEN to 1 and ignore it. (swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0 mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs were seen and revert all changes on success in that case. Don't try to recog_memoized DEBUG_INSNs. (compare_for_stack_reg): Adjust swap_rtx_condition caller. If it returns true and debug_seen is 1, call swap_rtx_condition again with debug_seen -1. * gcc.dg/ubsan/pr107183.c: New test. (cherry picked from commit 6b5c98c1c0003bd470a4428bede6c862637a94b8)
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #18 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86dea99d8525bf49d51636332d6be440e51b931a commit r12-8920-g86dea99d8525bf49d51636332d6be440e51b931a Author: Jakub Jelinek Date: Tue Nov 15 08:14:45 2022 +0100 libatomic: Handle AVX+CX16 AMD like Intel for 16b atomics [PR104688] We got a response from AMD in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10 so the following patch starts treating AMD with AVX and CMPXCHG16B ISAs like Intel by using vmovdqa for atomic load/store in libatomic. We still don't have confirmation from Zhaoxin and VIA (anything else with CPUs featuring AVX and CX16?). 2022-11-15 Jakub Jelinek PR target/104688 * config/x86/init.c (__libat_feat1_init): Don't clear bit_AVX on AMD CPUs. (cherry picked from commit 4a7a846687e076eae58ad3ea959245b2bf7fdc07)
[Bug target/104689] aarch64: libgcc: DW_CFA_val_expression is not supported for RA_SIGN_SATE register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104689 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- (In reply to nsz from comment #2) > fixed for gcc-13 In an AArch64 Ubuntu 22.04 VM on my Apple Silicon M1 I see : Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint i.e. PACA / PACG , I see this test failing with trunk as of 136029059686fed2d99c755baf35f98553fc0232 simply bootstrapped with $srcdir/configure --enable-languages=c,c++ . I'll see if I can pull something out when I have some time. Ramana
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #13 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #12)
> Testing the following:
>
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -5869,37 +5869,37 @@ cgraph_edge_brings_all_scalars_for_node (struct
> cgraph_edge *cs,
> /* Determine whether CS also brings all aggregate values that NODE is
> specialized for. */
>
> static bool
> cgraph_edge_brings_all_agg_vals_for_node (struct cgraph_edge *cs,
> struct cgraph_node *node)
> {
>ipcp_transformation *ts = ipcp_get_transformation_summary (node);
>if (!ts || vec_safe_is_empty (ts->m_agg_values))
> return true;
>
>const ipa_argagg_value_list existing (ts->m_agg_values);
>auto_vec edge_values;
>ipa_node_params *dest_info = ipa_node_params_sum->get (node);
>gcc_checking_assert (dest_info->ipcp_orig_node);
>dest_info = ipa_node_params_sum->get (dest_info->ipcp_orig_node);
>push_agg_values_from_edge (cs, dest_info, _values, );
>const ipa_argagg_value_list avl (_values);
> - return avl.superset_of_p (existing);
> + return existing.superset_of_p (avl);
> }
It was not enough.
What I expected:
- avl contains: callback_fn_L and callback_fn_R
- existing contains: callback_fn_L
What I get:
- avl contains: callback_fn_L
- existing contains: callback_fn_L
It seems to have something to do with
push_agg_values_from_edge()/push_agg_values_for_index_from_edge() behaviour of
filtering self-recursive lattice values:
if (interim && self_recursive_pass_through_p (cs, jfunc, index))
{
interim->push_adjusted_values (src_idx, index, unit_delta,
res);
return;
}
Here we seem to ignore lattice values discovered on the edges and only copy
already encountered values. But we only populate 'interim' with values we
specialised the self-recursive call against:
push_agg_values_from_edge (cs, dest_info, _values, );
('existing' variable is populated by values caller uses in one location).
The following hack seems to fix the test case for me but I suspect it just
breaks any self-recursive propagation:
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -5868,35 +5868,35 @@ cgraph_edge_brings_all_scalars_for_node (struct
cgraph_edge *cs,
/* Determine whether CS also brings all aggregate values that NODE is
specialized for. */
static bool
cgraph_edge_brings_all_agg_vals_for_node (struct cgraph_edge *cs,
struct cgraph_node *node)
{
ipcp_transformation *ts = ipcp_get_transformation_summary (node);
if (!ts || vec_safe_is_empty (ts->m_agg_values))
return true;
const ipa_argagg_value_list existing (ts->m_agg_values);
auto_vec edge_values;
ipa_node_params *dest_info = ipa_node_params_sum->get (node);
gcc_checking_assert (dest_info->ipcp_orig_node);
dest_info = ipa_node_params_sum->get (dest_info->ipcp_orig_node);
- push_agg_values_from_edge (cs, dest_info, _values, );
+ push_agg_values_from_edge (cs, dest_info, _values, NULL);
const ipa_argagg_value_list avl (_values);
return avl.superset_of_p (existing);
}
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233 --- Comment #10 from Zack Weinberg --- The examples found by other people still don't demangle, though... $ c++filt --version 2>&1 | head -n1 GNU c++filt (GNU Binutils for Debian) 2.39 $ c++filt <<\EOF _ZNK3FooIPvEcvS_IT_EIiEEv _ZN5vnullcv3vecIT_T0_T1_EI10double_int7va_heap6vl_ptrEEv EOF _ZNK3FooIPvEcvS_IT_EIiEEv _ZN5vnullcv3vecIT_T0_T1_EI10double_int7va_heap6vl_ptrEEv
[Bug c++/107773] Class members do not hide nested types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107773
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||accepts-invalid,
||rejects-valid, wrong-code
Last reconfirmed||2022-11-20
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed, a compile time testcase:
struct a { using get = void; };
struct b : a { int get(int i); };
template
concept c = requires { typename T::get; };
template constexpr int f(T t) {return 0;}
template constexpr int f(T t) { typename T::get t1; return 1; }
static_assert(f(b{}) == 0);
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233 --- Comment #9 from Andrew Pinski --- (In reply to Zack Weinberg from comment #0) > > _ZN9convertercvPT_I4DestEEv [apinski@xeond2 stage1-gcc]$ c++filt _ZN9convertercvPT_I4DestEEv converter::operator Dest*() This now demangles as of 2.30. > _ZN9convertercvPT_IN4DestEEEv So does this. [apinski@xeond2 stage1-gcc]$ c++filt _ZN9convertercvPT_IN4DestEEEv converter::operator Dest*()
[Bug c++/77660] Conversion operator unknown or ambiguous: gcc or clang behave differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77660 --- Comment #1 from Andrew Pinski --- I am pretty sure this is really a dup of bug 61663.
[Bug c++/61663] [DR 976] Deduction for const T& conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61663 Andrew Pinski changed: What|Removed |Added CC||alvinhochun at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 107771 has been marked as a duplicate of this bug. ***
[Bug c++/107771] template const reference conversion operator not considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107771 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 61663. *** This bug has been marked as a duplicate of bug 61663 ***
[Bug c++/107771] Cannot resolve templated conversion operator in templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107771 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-20 Ever confirmed|0 |1
[Bug c++/107771] Cannot resolve templated conversion operator in templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107771
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
struct bind_in
{
template
operator R const& () const;
}a;
int x(void) {
return a;
}
```
[Bug c++/107773] New: Class members do not hide nested types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107773
Bug ID: 107773
Summary: Class members do not hide nested types
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eiband at mail dot de
Target Milestone: ---
The following program exits with code 1.
test.cpp:
struct a
{
using get = void;
};
struct b : a
{
int get(int i) const;
};
template
concept c = requires { typename T::get; };
int main()
{
return c;
}
$ g++ test.cpp -std=c++20
$ ./a.out
$ echo $?
1
Expected is exit code 0, because T::get is not a type for T=b.
The code snippet is based on user "apple apple"'s comment on
https://stackoverflow.com/questions/74509418/why-does-member-function-not-hide-type-alias-in-base-class-when-compiling-with-g.
User "n. m." also notes that GCC happily compiles
https://eel.is/c++draft/temp.res.general#example-4 which does not use concepts
and should emit an error.
$ g++ -v
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~20.04)
[Bug rtl-optimization/107772] function prologue generated even though it's only needed in an unlikely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-20 --- Comment #1 from Andrew Pinski --- Confirmed, though this is more than just the your normal shrink wrapping case as you need to split the loop into two. Though maybe having the prologue and epoligue around the function call instead might be better Anyways this is still a more complex case for shrink wrapping. I Noticed that LLVM does not even do a shrink wrapping for the early return if b == e on entering the function.
[Bug target/107568] Bootstrap failure on macOS 12.6 (monterey)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-20 Status|UNCONFIRMED |NEW --- Comment #5 from Iain Sandoe --- sorry this bug is in two places; when I first encountered the issue it was with my prototype aarch64 development branch, so not appropriate to BZ ... .. however seems it does also affect unpatched master. summary: - the headers are (at least IMO) buggy since the functions are not deprecated in any of the standards I have access too. - it might be very nice to make GCC more robust by using the 'n' versions, but that's quite a big project and not going to be appropriate to GCC-13. - We can fixincludes the deprecations, as Andrew and Jakub have commented (but I'll wait for the XC14.1 release)
[Bug rtl-optimization/107772] New: [missed optimization] function prologue generated even though it's only needed in an unlikely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
Bug ID: 107772
Summary: [missed optimization] function prologue generated even
though it's only needed in an unlikely path
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avi at scylladb dot com
Target Milestone: ---
Consider
int g(int);
void f(int* b, int* e) {
while (b != e) {
if (__builtin_expect(*b != 0, false)) [[unlikely]] {
*b = g(*b);
}
++b;
}
}
If we believe the __builtin_expect and/or unlikely annotations (had both for
extra safety), the loop usually does nothing. So we would expect any register
saving and restoring to be pushed to the unlikely section. Yet (-O3):
f(int*, int*):
cmp rdi, rsi
je .L10
pushrbp
mov rbp, rsi
pushrbx
mov rbx, rdi
sub rsp, 8
.L4:
mov edi, DWORD PTR [rbx]
testedi, edi
jne .L14
.L3:
add rbx, 4
cmp rbp, rbx
jne .L4
add rsp, 8
pop rbx
pop rbp
ret
.L14:
callg(int)
mov DWORD PTR [rbx], eax
jmp .L3
.L10:
ret
I count 8 instructions that could/should have been pushed to .L14.
[Bug c++/107771] New: Cannot resolve templated conversion operator in templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107771
Bug ID: 107771
Summary: Cannot resolve templated conversion operator in
templated struct
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alvinhochun at gmail dot com
Target Milestone: ---
With this code:
===
template
struct bind_in
{
bind_in(T const& object) noexcept : object(object) {}
T const& object;
template
operator R const& () const noexcept {
return reinterpret_cast(object);
}
};
struct SomeType {
int v;
};
void func(SomeType in);
void x(const SomeType& v) {
func(bind_in(v));
}
===
GCC produces an error:
error: could not convert 'bind_in((* & v))' from 'bind_in'
to 'SomeType'
Compiler Explorer: https://godbolt.org/z/rrhY7rr3b
[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Andrew Pinski changed:
What|Removed |Added
Summary|-flto with -Os/-O2/-O3 |[12/13 Regression] -flto
|emitted code with gcc 12.x |with -Os/-O2/-O3 emitted
|segfaults via mutated |code with gcc 12.x
|global in .rodata |segfaults via mutated
||global in .rodata
Ever confirmed|0 |1
Known to fail||12.1.0, 13.0
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.3
Last reconfirmed||2022-11-20
Known to work||11.1.0
--- Comment #1 from Andrew Pinski ---
Confirmed, reduced further, removing malloc and changing srand into a function
inside the TU (with noipa attribute):
[[gnu::noipa]]
void hjj (unsigned int lk)
{
(void)lk;
}
void nn(int i, int n);
[[gnu::noinline]]
int ll(void) {
return 1;
}
void hh(int* dest, int src)
{
if (!ll() && !src)
hjj(100);
(*dest) = 1;
}
void gg(int* result, int x)
{
if (x >= 0)
return;
int xx;
xx = *result;
hh(result, ll());
if (xx >= *result)
nn(xx, *result);
}
void nn(int i, int n) {
int T8_;
if (n < 0)
__builtin_exit(0);
T8_ = 0;
gg(_, i);
__builtin_exit(0);
}
void kk(int* x, int i) {
hh(x, ll());
if (i < 0 || i >= *x)
nn(i,*x);
}
int g__r_1 = 0;
int main() {
kk(__r_1, 0);
return 0;
}
[Bug jit/107770] New: Comparison of vectors of float doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107770 Bug ID: 107770 Summary: Comparison of vectors of float doesn't work Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch to fix this.
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 --- Comment #18 from gagan sidhu (broly) --- hi, i wanted to correct an inaccuracy in my previous comment, as i needed to build a MIPS64 multilib toolchain today and ran into the same problem. the solution is, as my friend of chinese origin suggested: https://reviews.llvm.org/D129749 the solution here: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9f943b2446f2d0 is not conducive to the overall fix, which i will be commenting on in the llvm review since it's not exactly relevant to the issue here. this issue focuses exclusively on the assertion failure, but not the struct stat issues that arise when trying to build a multilib toolchain for MIPS. sorry for any confusion!
[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6b5c98c1c0003bd470a4428bede6c862637a94b8 commit r13-4175-g6b5c98c1c0003bd470a4428bede6c862637a94b8 Author: Jakub Jelinek Date: Sun Nov 20 17:42:42 2022 +0100 reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183] As the following testcase shows, the swap_rtx_condition function in reg-stack can result in different code generation between -g and -g0. The function is doing the changes as it goes, so does analysis and changes together, which makes it harder to deal with DEBUG_INSNs, where normally analysis phase ignores them and the later phase doesn't. swap_rtx_condition walks instructions two different ways, one is using next_flags_user function which stops on non-call instructions that mention the flags register, and the other is a loop on fnstsw where it stops on instructions mentioning it and tries to find sahf instruction that uses it (in both cases calls stop it and so does end of basic block). Now both of these currently stop on DEBUG_INSNs that mention the flags register resp. the fnstsw result register. On success the function recurses on next flags user instruction if still live and if the recursion failed, reverts the changes it did too and fails. If it were just for the next_flags_user case, the fix could be just not doing INSN_CODE (insn) = -1; if (recog_memoized (insn) == -1) fail = 1; on DEBUG_INSNs (assuming all changes to those are fine), swap_rtx_condition_1 just changes one comparison to a different one. But due to the possibility of fnstsw result being used in theory before sahf in some DEBUG_INSNs, this patch takes a different approach. swap_rtx_condition has now a new argument and two modes. The first mode is when debug_seen is >= 0, in this case both next_flags_user and the loop for fnstsw -> sahf will ignore but note DEBUG_INSNs (that mention flags register or fnstsw result). If no such DEBUG_INSN is found during the whole call including recursive invocations (so e.g. for -g0 but probably most often for -g as well), it behaves as before, if it returns true all the changes are done and nothing further needs to be done later. If any DEBUG_INSNs are seen along the way, even when returning success all the changes are reverted, so it just reports that the function would be successful if DEBUG_INSNs were ignored. In this case, compare_for_stack_reg needs to call it again in debug_seen = -1 mode, which tells the function to update everything including DEBUG_INSNs. For the fnstsw -> sahf case which I hope will be very rare I just reset the DEBUG_INSNs, I don't really know how to express it easily otherwise. For the rest swap_rtx_condition_1 is done even on the DEBUG_INSNs. 2022-11-20 Jakub Jelinek PR target/107183 * reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument. If >= 0 and a DEBUG_INSN would be otherwise returned, set DEBUG_SEEN to 1 and ignore it. (swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0 mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs were seen and revert all changes on success in that case. Don't try to recog_memoized DEBUG_INSNs. (compare_for_stack_reg): Adjust swap_rtx_condition caller. If it returns true and debug_seen is 1, call swap_rtx_condition again with debug_seen -1. * gcc.dg/ubsan/pr107183.c: New test.
[Bug c/107769] New: -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Bug ID: 107769
Summary: -flto with -Os/-O2/-O3 emitted code with gcc 12.x
segfaults via mutated global in .rodata
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: resence at parsoma dot net
Target Milestone: ---
Created attachment 53931
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53931=edit
Small, preprocessed testcase to reproduce this issue via -save-temps
On a Debian unstable amd64 system running "gcc (Debian 12.2.0-9) 12.2.0"
running any of:
gcc -flto -Wall -Wextra -pedantic -fopt-info -finline-limit=150 -Os
-fno-strict-aliasing -o r.OsNoG repro.c
gcc -flto -Wall -g -Wextra -pedantic -finline-limit=150 -Os
-fno-strict-aliasing -o r.Os repro.c
gcc -flto -Wall -Wextra -pedantic -fopt-info -finline-limit=150 -O2
-fno-strict-aliasing -o r.O2NoG repro.c
gcc -flto -Wall -g -Wextra -pedantic -finline-limit=150 -O2
-fno-strict-aliasing -o r.O2 repro.c
gcc -flto -Wall -Wextra -pedantic -finline-limit=150 -O3 -fno-strict-aliasing
-o r.O3noG repro.c
gcc -flto -Wall -Wextra -g -pedantic -finline-limit=150 -O3
-fno-strict-aliasing -o r.O3 repro.c
on the attached repro.c test case results in
repro.c: In function ‘incRef__system_5450’:
repro.c:12:39: warning: unused parameter ‘c’ [-Wunused-parameter]
12 | static void incRef__system_5450(void* c) {
| ~~^
repro.c: In function ‘isOnStack__system_5438’:
repro.c:15:74: warning: unused parameter ‘p’ [-Wunused-parameter]
15 | unsigned char __attribute__((__noinline__)) isOnStack__system_5438(void
*p) {
|
~~^
and a binary which segfaults:
$ for i in r.O*; do echo $i; ./$i; done
r.O2
Segmentation fault
r.O2NoG
Segmentation fault
r.O3
Segmentation fault
r.O3noG
Segmentation fault
r.Os
Segmentation fault
r.OsNoG
Segmentation fault
Running valgrind results in:
==1048150== Memcheck, a memory error detector
==1048150== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1048150== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1048150== Command: ./r.Os
==1048150==
==1048150==
==1048150== Process terminating with default action of signal 11 (SIGSEGV)
==1048150== Bad permissions for mapped region at address 0x10A008
==1048150==at 0x109098: UnknownInlinedFun (repro.c:24)
==1048150==by 0x109098: UnknownInlinedFun (repro.c:45)
==1048150==by 0x109098: main (repro.c:50)
(with similar output for other optimization settings, less for settings without
debug information)
The proximate cause of this is that the global variable g__r_1 has been placed
in the .rodata section:
(gdb) p __r_1
$2 = (void **) 0x6008
(gdb) info file
...
0x6000 - 0x6010 is .rodata
...
This seems to only happen with a combination of all of (a) -flto (even with one
source file), (b) some greater-than-O1 level optimization level, (c) absence of
-fno-inline-small-functions option; and (d) gcc 12.x or newer.
Running gcc UBSAN on this reveals nothing obviously additional:
$ rm -v a.out && gcc -Og -flto -finline-limit=150 -fsanitize=undefined -Wall
-Wextra -pedantic -fno-strict-aliasing repro.c && ./a.out && echo gcc UBSAN
complete
removed 'a.out'
repro.c: In function ‘incRef__system_5450’:
repro.c:12:39: warning: unused parameter ‘c’ [-Wunused-parameter]
12 | static void incRef__system_5450(void* c) {
| ~~^
repro.c: In function ‘isOnStack__system_5438’:
repro.c:15:74: warning: unused parameter ‘p’ [-Wunused-parameter]
15 | unsigned char __attribute__((__noinline__)) isOnStack__system_5438(void
*p) {
|
~~^
gcc UBSAN complete
[Bug regression/107767] GCC has some problems in optimizer of trivial case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #1 from Коренберг Марк --- See assembler output for firewall2(). It's not -Os optimized (compare to firewall(), which is ok) ``` firewall: movw64(%rdi), %ax cmpb$17, (%rdi) sete%cl leal-15(%rax), %edx testw $-9, %dx movb$1, %dl sete%sil cmpw$47, %ax ja .L2 movabsq $-180319906955279, %rdx btq %rax, %rdx setc%dl .L2: movl%edx, %eax xorl$1, %eax orl %esi, %eax andl%ecx, %eax movzbl %al, %eax ret firewall2: movw64(%rdi), %ax xorl%edx, %edx decl%eax cmpw$46, %ax ja .L5 movzwl %ax, %eax movsbl CSWTCH.2(%rax), %edx .L5: movl%edx, %eax ret CSWTCH.2: .byte 1 .byte 1 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 0 .byte 1 .byte 0 .byte 0 .byte 1 .byte 0 .byte 1 ```
[Bug c++/107768] New: Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 Bug ID: 107768 Summary: Bogus -Wzero-as-null-pointer-constant in coroutine Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eaneiros at gmail dot com Target Milestone: --- Created attachment 53930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53930=edit Sample code I was trying one of the cppreference coroutine examples and encountered what appears to be a false positive for -Wzero-as-null-pointer-constant. See attached for sample code. According to godbolt.org this happens in gcc trunk. To trigger it just compile with -Wzero-as-null-pointer-constant. Godbolt link: https://godbolt.org/z/41aMEErx4
[Bug regression/107767] New: GCC has some problems in optimizer of trivial case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Bug ID: 107767
Summary: GCC has some problems in optimizer of trivial case
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/rTfTondfP
```
#include
int firewall(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
if (ip_proto == 17 && dst_port == 15) return 1;
if (ip_proto == 17 && dst_port == 23) return 1;
if (ip_proto == 17 && dst_port == 47) return 1;
if (ip_proto == 17 && dst_port == 45) return 1;
if (ip_proto == 17 && dst_port == 42) return 1;
if (ip_proto == 17 && dst_port == 1) return 1;
if (ip_proto == 17 && dst_port == 2) return 1;
if (ip_proto == 17 && dst_port == 3) return 1;
return 0;
}
int firewall2(const uint8_t *restrict data) {
const uint16_t dst_port = *((const uint16_t *)data + 32);
if (dst_port == 15) return 1;
if (dst_port == 23) return 1;
if (dst_port == 47) return 1;
if (dst_port == 45) return 1;
if (dst_port == 42) return 1;
if (dst_port == 1) return 1;
if (dst_port == 2) return 1;
if (dst_port == 3) return 1;
return 0;
}
```
Compile with -Os.
Second function IS NOT minimal, obviously. It's a bug. GCC 12.2 does not have
it.
[Bug tree-optimization/107766] [13 Regression] ICE Segmentation fault since r13-4137-gc5df8392c5848c04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107766 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-11-20 Status|UNCONFIRMED |NEW Known to fail||13.0 Target Milestone|--- |13.0 Ever confirmed|0 |1
[Bug tree-optimization/107766] New: [13 Regression] ICE Segmentation fault since r13-4137-gc5df8392c5848c04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107766
Bug ID: 107766
Summary: [13 Regression] ICE Segmentation fault since
r13-4137-gc5df8392c5848c04
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: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
The following is reduced from blender package:
$ cat bt.ii
typedef double btScalar;
struct btVector3 {
operator btScalar *() const;
};
double m_vec[2];
struct btShapeMatrix {
double [](int i) { return m_vec[i]; }
};
btScalar shape_function___1pxt1pz, shape_function__fac;
struct btMiniSDF {
void shape_function_(btVector3 const &) const;
};
void btMiniSDF::shape_function_(btVector3 const ) const {
btShapeMatrix res;
btScalar _1m3y = 1.0 - 3.0 * xi[1], _1p3y = 1.0 + 3.0 * xi[1],
fact1m3y = shape_function__fac * _1m3y,
fact1p3y = shape_function__fac * _1p3y;
res[22] = fact1m3y * shape_function___1pxt1pz;
res[23] = fact1p3y * shape_function___1pxt1pz;
}
$ g++ bt.ii -c -O2 -ffp-contract=off
during GIMPLE pass: slp
bt.ii: In member function ‘void btMiniSDF::shape_function_(const btVector3&)
const’:
bt.ii:13:6: internal compiler error: Segmentation fault
13 | void btMiniSDF::shape_function_(btVector3 const ) const {
| ^
0x11d53ef crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:314
0x1493370 complex_mul_pattern::matches(_complex_operation, hash_map<_slp_tree*,
_complex_perm_kinds, simple_hashmap_traits,
_complex_perm_kinds> >*, hash_map,
nofree_ptr_hash<_slp_tree> >, bool,
simple_hashmap_traits,
nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**, vec<_slp_tree*, va_heap,
vl_ptr>*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp-patterns.cc:1042
0x1494443 complex_mul_pattern::matches(_complex_operation, hash_map<_slp_tree*,
_complex_perm_kinds, simple_hashmap_traits,
_complex_perm_kinds> >*, hash_map,
nofree_ptr_hash<_slp_tree> >, bool,
simple_hashmap_traits,
nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**, vec<_slp_tree*, va_heap,
vl_ptr>*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp-patterns.cc:1023
0x1494443 complex_operations_pattern::recognize(hash_map<_slp_tree*,
_complex_perm_kinds, simple_hashmap_traits,
_complex_perm_kinds> >*, hash_map,
nofree_ptr_hash<_slp_tree> >, bool,
simple_hashmap_traits,
nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**)
/home/marxin/Programming/gcc/gcc/tree-vect-slp-patterns.cc:1424
0x147ee67 vect_match_slp_patterns_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3010
0x147eebe vect_match_slp_patterns_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3003
0x147eebe vect_match_slp_patterns_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3003
0x147eebe vect_match_slp_patterns_2
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3003
0x14801d3 vect_match_slp_patterns
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3042
0x14801d3 vect_analyze_slp(vec_info*, unsigned int)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:3533
0x148a6c3 vect_slp_analyze_bb_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7317
0x148a6c3 vect_slp_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7419
0x148c39c vect_slp_bbs
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7610
0x148c623 vect_slp_function(function*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7698
0x1495371 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1532
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
