[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2dc5d6b1e7ec8822f5bd78761962ca2c85d4a2b4 commit r13-4607-g2dc5d6b1e7ec8822f5bd78761962ca2c85d4a2b4 Author: Richard Biener Date: Mon Dec 12 08:13:33 2022 +0100 tree-optimization/89317 - another pattern for >x != p + 4 As seen in the original testcase for PR89317 we are missing comparison simplification patterns for >x != p + 4. Fixed by making an existing one apply. To make the pattern apply during CCP we need to simplify ccp_fold to not use GENERIC folding of conditions but also use GIMPLE folding. PR tree-optimization/89317 * tree-ssa-ccp.cc (ccp_fold): Handle GIMPLE_COND via gimple_fold_stmt_to_constant_1. * match.pd ( != + c): Apply to pointer_plus with non-ADDR_EXPR base as well. * gcc.dg/tree-ssa/pr89317.c: Amend.
[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008 --- Comment #10 from Alexander Monakov --- Looks similar to PR 107323, but needs explicit -ftree-loop-distribution to trigger.
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 --- Comment #12 from rguenther at suse dot de --- On Sun, 11 Dec 2022, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 > > --- Comment #11 from Marc Glisse --- > (In reply to Richard Biener from comment #10) > > Should be fixed in GCC 13. > > If I compile the original testcase with -O3, I get for test2: > > _1 = this_6(D) + 16; > _2 = _6(D)->data1; > if (_1 != _2) > > so we should probably also handle comparisons and not just subtractions. For > this particular testcase, the relevant optimizations still happen and RTL > cleans up the comparison, so it is ok, but the pattern appears in other PRs > like PR 106677. I'll see to add those.
[Bug c++/108067] Miscompilation with friend function with parameter pack: mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108067 --- Comment #1 from danakj at orodu dot net --- Notably, this occurs with friend operator== or operator<=>.
[Bug c++/108067] New: Miscompilation with friend function with parameter pack: mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108067
Bug ID: 108067
Summary: Miscompilation with friend function with parameter
pack: mismatched argument pack lengths
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danakj at orodu dot net
Target Milestone: ---
The following code compiles in Clang and MSVC but not in GCC.
Repros in GCC 10, 11, 12, and trunk.
```
template
static constexpr bool C = true;
template
struct Foo {
template
requires((... && C))
void bar(const Foo& r) {}
template
requires((... && C))
friend void baz(const Foo& l, const Foo& r) {}
};
int main() {
Foo x;
x.bar(Foo()); // Works.
baz(x, Foo()); // Doesn't work.
}
```
godbolt: https://godbolt.org/z/3Ybofbcoc
: In instantiation of 'struct Foo':
:16:19: required from here
:12:17: error: mismatched argument pack lengths while expanding 'C'
12 | friend void baz(const Foo& l, const Foo& r) {}
| ^~~
ASM generation compiler returned: 1
: In instantiation of 'struct Foo':
:16:19: required from here
:12:17: error: mismatched argument pack lengths while expanding 'C'
12 | friend void baz(const Foo& l, const Foo& r) {}
| ^~~
Execution build compiler returned: 1
[Bug c++/108066] ICE in use_pack_expansion_extra_args_p, at cp/pt.cc:12661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108066 danakj at orodu dot net changed: What|Removed |Added Version|12.2.0 |13.0 --- Comment #1 from danakj at orodu dot net --- This does not reproduce in 12.2, but it does on trunk.
[Bug c++/108066] New: ICE in use_pack_expansion_extra_args_p, at cp/pt.cc:12661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108066
Bug ID: 108066
Summary: ICE in use_pack_expansion_extra_args_p, at
cp/pt.cc:12661
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danakj at orodu dot net
Target Milestone: ---
```
template
struct Foo;
template
concept C = true;
template
struct Foo {
template
requires ((... && C))
friend void bar(Foo, Foo) {}
};
int main() {
Foo x;
bar(x, Foo());
}
```
godbolt: https://godbolt.org/z/KozobKa1q
: In instantiation of 'struct Foo':
:15:14: required from here
:10:27: internal compiler error: in use_pack_expansion_extra_args_p, at
cp/pt.cc:12661
10 | requires ((... && C))
| ~^
0x22efc1e internal_error(char const*, ...)
???:0
0xa4af9a fancy_abort(char const*, int, char const*)
???:0
0xabf850 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
???:0
0xabf939 maybe_substitute_reqs_for(tree_node*, tree_node const*)
???:0
0xc7c12c instantiate_class_template(tree_node*)
???:0
0xafe1a3 start_decl_1(tree_node*, bool)
???:0
0xb1ffb7 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xc242c7 c_parse_file()
???:0
0xd5e809 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug analyzer/108065] New: [13 Regression] ICE in make, at analyzer/store.cc:132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108065 Bug ID: 108065 Summary: [13 Regression] ICE in make, at analyzer/store.cc:132 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 20221211 snapshot (g:8f72249ff4cbd0a5c701b99ee8aa1ca9d82df046) ICEs when compiling gcc/testsuite/gfortran.dg/bounds_check_23.f90, gcc/testsuite/gfortran.dg/pr69739.f90, gcc/testsuite/gfortran.dg/allocate_with_source_8.f08, and perhaps some other Fortran testcases w/ -fanalyzer: % aarch64-linux-gnu-gfortran-13 -fanalyzer -c gcc/testsuite/gfortran.dg/bounds_check_23.f90 during IPA pass: analyzer gcc/testsuite/gfortran.dg/bounds_check_23.f90:13:43: 13 | c = [ ( text(i:i), i = 1, len(text) ) ] | ^ internal compiler error: in make, at analyzer/store.cc:132 0x81937b ana::binding_key::make(ana::store_manager*, ana::region const*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/store.cc:132 0x144acb1 ana::binding_cluster::maybe_get_simple_value(ana::store_manager*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/store.cc:2165 0x144acb1 ana::binding_cluster::maybe_get_simple_value(ana::store_manager*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/store.cc:2155 0x144d00a ana::binding_cluster::get_any_binding(ana::store_manager*, ana::region const*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/store.cc:1613 0x144d00a ana::binding_cluster::get_any_binding(ana::store_manager*, ana::region const*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/store.cc:1601 0x13f249e ana::region_model::get_store_value(ana::region const*, ana::region_model_context*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/region-model.cc:2336 0x13f249e ana::region_model::get_store_value(ana::region const*, ana::region_model_context*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/region-model.cc:2321 0x13f4a7c ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/region-model.cc:2226 0x13f89b9 ana::region_model::on_assignment(gassign const*, ana::region_model_context*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/region-model.cc:1100 0x13ca7d7 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/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/engine.cc:1452 0x13cd695 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/engine.cc:4044 0x13ce3f2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/engine.cc:3447 0x13d0956 ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/engine.cc:6098 0x13d1a26 ana::run_checkers() /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/engine.cc:6186 0x13c08d8 execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221211/work/gcc-13-20221211/gcc/analyzer/analyzer-pass.cc:87
[Bug c++/108059] internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059 --- Comment #2 from LIU Hao --- Reconfirmed with all the following versions: * g++-10 (Ubuntu 10.4.0-4ubuntu1~22.04) 10.4.0 * g++-11 (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 * g++-12 (Ubuntu 12.2.0-3ubuntu1~22.04) 12.2.0
[Bug fortran/102180] Improve checking of assume size array spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102180 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Last reconfirmed||2022-12-11 --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058623.html
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- (In reply to sandra from comment #7) If gcc 11 had a bug that > caused it to do that incorrectly, is it necessary to retain ABI > compatibility by continuing to reproduce the bug in newer versions of > libgfortran? Maybe we should just remove the functions that are allegedly > there for compatibility so that users will get a link error instead? No, certainly not. As long as libgfortran.so keeps its SONAME (libgfortran.so.5 right now), it should remain backwards compatible (libgfortran.so.5 from newer gcc should handle programs compiled by older gcc as long as the programs were valid).
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #7 from sandra at gcc dot gnu.org --- I've swapped out just about all the details on this work after more than a year, but we shouldn't be trying to create a CFI descriptor with BT_ASSUMED at all, should we? If the compiler is generating a CFI descriptor for an assumed-type argument it's supposed to use the actual type of the argument passed, not BT_ASSUMED, right? If gcc 11 had a bug that caused it to do that incorrectly, is it necessary to retain ABI compatibility by continuing to reproduce the bug in newer versions of libgfortran? Maybe we should just remove the functions that are allegedly there for compatibility so that users will get a link error instead?
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 --- Comment #7 from Andrew Pinski --- (In reply to Eric Schmidt from comment #5) > Surely this should have been resolved as INVALID? It was marked as won't fix as I am saying we won't fix (change) the compiler to reject it (even though the code is invalid and can be rejected as we do with -flto).
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 jo.rickert at protonmail dot ch changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 --- Comment #6 from jo.rickert at protonmail dot ch --- (In reply to Andrew Pinski from comment #4) > You can read up more on the one definition rule here: > https://en.cppreference.com/w/cpp/language/definition > > It is a good summary of what the standard says. Thanks, I thought the name had to be unique per translation unit.
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 Eric Schmidt changed: What|Removed |Added CC||eric41293 at comcast dot net --- Comment #5 from Eric Schmidt --- Surely this should have been resolved as INVALID?
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 --- Comment #11 from Marc Glisse --- (In reply to Richard Biener from comment #10) > Should be fixed in GCC 13. If I compile the original testcase with -O3, I get for test2: _1 = this_6(D) + 16; _2 = _6(D)->data1; if (_1 != _2) so we should probably also handle comparisons and not just subtractions. For this particular testcase, the relevant optimizations still happen and RTL cleans up the comparison, so it is ok, but the pattern appears in other PRs like PR 106677.
[Bug tree-optimization/108064] [13 Regression] apache-arrow-cpp-9.0.0 is vectored incorrectly: arithmetic shift instead of logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108064 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-11 --- Comment #1 from Jakub Jelinek --- Started with r13-1100-gacb1e6f43dc2bbedd1248ea61c7ab537a11fe59b I'll have a look.
[Bug tree-optimization/108064] [13 Regression] apache-arrow-cpp-9.0.0 is vectored incorrectly: arithmetic shift instead of logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108064 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |13.0
[Bug tree-optimization/108064] New: [13 Regression] apache-arrow-cpp-9.0.0 is vectored incorrectly: arithmetic shift instead of logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108064
Bug ID: 108064
Summary: [13 Regression] apache-arrow-cpp-9.0.0 is vectored
incorrectly: arithmetic shift instead of logical
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed the failure as an array test failure in
apache-arrow-cpp-9.0.0:
[ FAILED ] TestSwapEndianArrayData.RandomData
There array of int16_t gets endianness shifted element by element. Minimized
example:
// $ cat a.cc
typedef short int i16;
static inline i16 ByteSwap16(i16 value) {
constexpr auto m = static_cast(0xff);
return static_cast(((value >> 8) & m) | ((value & m) << 8));
}
__attribute__((noipa))
void swab16(i16 * d, const i16* s) {
for (unsigned long i = 0; i < 4; i++) {
d[i] = ByteSwap16(s[i]);
}
}
__attribute__((noipa))
int main(void) {
/* need to alogn inputs to make sure vectized part
of the loop gets executed. */
alignas(16) i16 a[4] = {0xff, 0, 0, 0};
alignas(16) i16 b[4];
alignas(16) i16 c[4];
swab16(b, a);
swab16(c, b);
/* Contents of 'a' should be equivalent to 'c'.
But gcc bug generates invalid vectored shifts. */
if (a[0] != c[0])
__builtin_trap();
}
Weekly gcc-13 (and master branch) generate invalid code for it:
$ ./gcc-git/bin/g++ -O3 a.cc -o a && ./a
Illegal instruction (core dumped)
$ ./gcc-git/bin/g++ -O0 a.cc -o a && ./a
AFAIU swab16() gets miscompiled:
Dump of assembler code for function _Z6swab16PsPKs:
...
movq (%rsi),%xmm0
movdqa %xmm0,%xmm1
psllw $0x8,%xmm0
psraw $0x8,%xmm1 ; <<<- should be psrlw!
por%xmm1,%xmm0
movq %xmm0,(%rdi)
Here 'gcc' loads 64 bits at a time and swaps even and odd bytes
- 'psllw' moves odd bytes (zero-filling, ok)
- 'psraw' moves even bytes (sign-extending, bug)
As a result 'por' has a chance of masking even byte position with a sign bit.
$ ./gcc-git/bin/g++ -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-13.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221211 (experimental) (GCC)
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8f72249ff4cbd0a5c701b99ee8aa1ca9d82df046 commit r13-4605-g8f72249ff4cbd0a5c701b99ee8aa1ca9d82df046 Author: Steve Kargl Date: Sat Dec 10 22:17:15 2022 +0100 Fortran: fix ICE on bad use of statement function [PR107995] gcc/fortran/ChangeLog: PR fortran/107995 * interface.cc (gfc_check_dummy_characteristics): Reject statement function dummy arguments. gcc/testsuite/ChangeLog: PR fortran/107995 * gfortran.dg/pr107995.f90: New test.
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Gilles Gouaillardet from comment #2) > ubuntu does not ship libgfortran.so from gfortran-11. > > I tried on a RedHat box, and the issue only occurs when > - I compile with gfortran-11 > - *and* I force libgfortran-12 Isn't that forward compatibility? Backward compatibility would be something compiled with 12 can use libgfortran from 11. But, I suspect that is also broken, because ... > (so if i use the same gfortran and libgfortran versions, there is no issue). > > Here is a stack trace in these conditions: > > #0 0x2ba2dd70 in _exit () from /lib64/libc.so.6 > #1 0x2b9a1cab in __run_exit_handlers () from /lib64/libc.so.6 > #2 0x2b9a1d37 in exit () from /lib64/libc.so.6 > #3 0x2acf0976 in _gfortrani_exit_error (status=3) at > ../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:218 > #4 0x2acf12af in _gfortrani_internal_error (cmp=0x0, > message=0x2afdf2a5 "Invalid type in descriptor") at > ../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:534 > #5 0x2af787e2 in _gfortran_gfc_desc_to_cfi_desc > (d_ptr=0x7fffcfa8, s=0x7fffcfd0) at > ../../../../src/gcc-12.1.0/libgfortran/runtime/ISO_Fortran_binding.c:219 a lot of work went into fixing problems with ISO_Fortran_binding.[ch]. It seems that that work either was not merged into 11 or was only partially merged. Either way it appears the ABI of the library has been broken. If you're application is using ISO_Fortran_binding.h, then you'll want to use gfortran 12 or newer.
[Bug libstdc++/108062] Test spdlog c++20 std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108062 --- Comment #1 from Andrew Pinski --- I tried to test this but my cmake is not new enough: Target "example" requires the language dialect "CXX20" , but CMake does not
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Buclaw --- Fix committed and backported.
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 --- Comment #4 from Andrew Pinski --- You can read up more on the one definition rule here: https://en.cppreference.com/w/cpp/language/definition It is a good summary of what the standard says.
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:9d18a4b98d9b6bff4ba8b215f1e66e51ffba9638 commit r10-6-g9d18a4b98d9b6bff4ba8b215f1e66e51ffba9638 Author: Iain Buclaw Date: Sat Dec 10 19:12:43 2022 +0100 d: Fix internal compiler error: in visit, at d/imports.cc:72 (PR108050) The visitor for lowering IMPORTED_DECLs did not have an override for dealing with importing OverloadSet symbols. This has now been implemented in the code generator. PR d/108050 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (Import *)): Handle build_import_decl returning a TREE_LIST. * imports.cc (ImportVisitor::visit (OverloadSet *)): New override. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108050/mod1.d: New. * gdc.dg/imports/pr108050/mod2.d: New. * gdc.dg/imports/pr108050/package.d: New. * gdc.dg/pr108050.d: New test. (cherry picked from commit d9d8c9674ad3ad3aa38419d24b1aaaffe31f5d3f)
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:40b5a2354b58955aef168104c173311f062f1fa5 commit r11-10415-g40b5a2354b58955aef168104c173311f062f1fa5 Author: Iain Buclaw Date: Sat Dec 10 19:12:43 2022 +0100 d: Fix internal compiler error: in visit, at d/imports.cc:72 (PR108050) The visitor for lowering IMPORTED_DECLs did not have an override for dealing with importing OverloadSet symbols. This has now been implemented in the code generator. PR d/108050 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (Import *)): Handle build_import_decl returning a TREE_LIST. * imports.cc (ImportVisitor::visit (OverloadSet *)): New override. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108050/mod1.d: New. * gdc.dg/imports/pr108050/mod2.d: New. * gdc.dg/imports/pr108050/package.d: New. * gdc.dg/pr108050.d: New test. (cherry picked from commit d9d8c9674ad3ad3aa38419d24b1aaaffe31f5d3f)
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f12c8f93111e2fb0bd73d1bad52325001990 commit r12-8969-gf12c8f93111e2fb0bd73d1bad52325001990 Author: Iain Buclaw Date: Sat Dec 10 19:12:43 2022 +0100 d: Fix internal compiler error: in visit, at d/imports.cc:72 (PR108050) The visitor for lowering IMPORTED_DECLs did not have an override for dealing with importing OverloadSet symbols. This has now been implemented in the code generator. PR d/108050 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (Import *)): Handle build_import_decl returning a TREE_LIST. * imports.cc (ImportVisitor::visit (OverloadSet *)): New override. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108050/mod1.d: New. * gdc.dg/imports/pr108050/mod2.d: New. * gdc.dg/imports/pr108050/package.d: New. * gdc.dg/pr108050.d: New test. (cherry picked from commit d9d8c9674ad3ad3aa38419d24b1aaaffe31f5d3f)
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d9d8c9674ad3ad3aa38419d24b1aaaffe31f5d3f commit r13-4604-gd9d8c9674ad3ad3aa38419d24b1aaaffe31f5d3f Author: Iain Buclaw Date: Sat Dec 10 19:12:43 2022 +0100 d: Fix internal compiler error: in visit, at d/imports.cc:72 (PR108050) The visitor for lowering IMPORTED_DECLs did not have an override for dealing with importing OverloadSet symbols. This has now been implemented in the code generator. PR d/108050 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (Import *)): Handle build_import_decl returning a TREE_LIST. * imports.cc (ImportVisitor::visit (OverloadSet *)): New override. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108050/mod1.d: New. * gdc.dg/imports/pr108050/mod2.d: New. * gdc.dg/imports/pr108050/package.d: New. * gdc.dg/pr108050.d: New test.
[Bug tree-optimization/106904] [12 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #8 from Zebediah Figura --- Thanks!
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Andrew Pinski --- This is called a violation of the one definition rule. In c++ classes even have linkage. No diagnostic is required as it is undefined behavior ar runtime. Note using -flto and you would catch these.
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 --- Comment #2 from jo.rickert at protonmail dot ch --- The forgotten command line: g++ -o main main.cpp dummy.cpp undefined_behavior.cpp
[Bug c++/108063] push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 jo.rickert at protonmail dot ch changed: What|Removed |Added Known to fail||11.3.1, 12.2.0, 4.8.5 Target||linux / windows Build||linux / windows Host||linux / windows --- Comment #1 from jo.rickert at protonmail dot ch --- tried to compile with clang, then program outputs as expected.
[Bug c++/108063] New: push_back on std::vector allocates wrong amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108063 Bug ID: 108063 Summary: push_back on std::vector allocates wrong amount of memory Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jo.rickert at protonmail dot ch Target Milestone: --- Created attachment 54067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54067=edit Source Code with a main.cpp and additional .cpp / .h files with all the .o and .ii Files When you have two classes with the same name (in different .cpp Files), the two classes have different size, for instance one with one integer member and the other with two integer members. Then if you do a push_back of each class on a vector the second instance does not allocate the right amount of memory and undefined actions occur. The system the files are from is a manjaro Linux with a gcc Version 12.2.0 I tried it on a windows 10 with gcc 12.2.0, Fedora 35 with gcc 11.3.1-3 and a centos7 with gcc 4.8.5 the bug occured on all versions. The second instance of this pushing on the vector does not even need to be called only to be compiled. Setup in the attached code: File dummy.cpp (code in this file never gets called, but if this file is linked then the generated source code creates undefined behavior): contains a class Item with two integer members. It has an unused functions that creates a std::vector uses push_back with an Item. File undefined_behavior.cpp: Has also a class Item but only with one Integer Member. Here we also have a function that creates a std::vector but when we use push_back here the allocated memory does strange things. If emplace_back is used instead it throws an allocation error. This function also prints the content of the vector, to show that it makes no sense. File undefined_behavior.h: contains the declaration of the function in undefined_behavior.cpp File main.cpp only includes undefined_behavior.h and calls the function. The expected output of my program is: Value of 0 is: 0 Value of 1 is: 1 Value of 2 is: 2 Value of 3 is: 3 Value of 4 is: 4 Value of 5 is: 5 Value of 6 is: 6 Value of 7 is: 7 Value of 8 is: 8 Value of 9 is: 9 Actual output varies from system to system: Value of 0 is: 0 Value of 1 is: 0 Value of 2 is: 1 Value of 3 is: 0 Value of 4 is: 2 Value of 5 is: 0 Value of 6 is: 3 Value of 7 is: 0 Value of 8 is: 4 Value of 9 is: 0 or: Value of 0 is: 0 Value of 1 is: 0 Value of 2 is: 1 Value of 3 is: 29499056 Value of 4 is: 2 Value of 5 is: 29499088 Value of 6 is: 3 Value of 7 is: 29499120 Value of 8 is: 4 Value of 9 is: 29499120 When push_back is replaced with emplace_back it most of the time throws bac_alloc and crashes.
[Bug libstdc++/108062] New: Test spdlog c++20 std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108062 Bug ID: 108062 Summary: Test spdlog c++20 std::format Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lukaszcz18 at wp dot pl Target Milestone: --- /// // Uncomment to use C++20 std::format instead of fmt. // // #define SPDLOG_USE_STD_FORMAT /// I use gcc 13.0.0 20221211, spdlog 1.11.0 20221211 In file included from c:\gcc1300\x86_64-w64-mingw32\include\spdlog\fmt\fmt.h:14, from c:\gcc1300\x86_64-w64-mingw32\include\spdlog\common.h:50, from c:\gcc1300\x86_64-w64-mingw32\include\spdlog\spdlog.h:12, from common.h:40, from BMPFormat.cpp:28: c:\gcc1300\include\c++\13.0.0\format:3350:40: error: expected identifier before ',' token 3350 | __format::__do_vformat_to(_Out_, basic_string_view<_CharT_>, |^ c:\gcc1300\include\c++\13.0.0\format: In instantiation of '_Out std::__format::__do_vformat_to(_Out, std::basic_string_view<_CharT>, const std::basic_format_args<_Context>&, const std::locale*) [with _Out = _Sink_iter; _CharT = char; _Context = std::basic_format_context<_Sink_iter, char>]': c:\gcc1300\include\c++\13.0.0\format:3646:39: required from '_Out std::vformat_to(_Out, string_view, format_args) [with _Out = __format::_Sink_iter; string_view = basic_string_view; format_args = basic_format_args, char> >]' c:\gcc1300\include\c++\13.0.0\format:3673:20: required from here c:\gcc1300\include\c++\13.0.0\format:3614:24: error: 'std::basic_format_context<_Out, _CharT>::basic_format_context(std::basic_format_args >, _Out) [with _Out = std::__format::_Sink_iter; _CharT = char]' is private within this context 3614 | ? _Context(__args, __sink_out) |^~~~ c:\gcc1300\include\c++\13.0.0\format:3338:7: note: declared private here 3338 | basic_format_context(basic_format_args __args, | ^~~~ c:\gcc1300\include\c++\13.0.0\format:3615:24: error: 'std::basic_format_context<_Out, _CharT>::basic_format_context(std::basic_format_args >, _Out, const std::locale&) [with _Out = std::__format::_Sink_iter; _CharT = char]' is private within this context 3615 | : _Context(__args, __sink_out, *__loc); |^~~~ c:\gcc1300\include\c++\13.0.0\format:3343:7: note: declared private here 3343 | basic_format_context(basic_format_args __args, | ^~~~ c:\gcc1300\include\c++\13.0.0\format: In instantiation of '_Out std::__format::__do_vformat_to(_Out, std::basic_string_view<_CharT>, const std::basic_format_args<_Context>&, const std::locale*) [with _Out = _Sink_iter; _CharT = wchar_t; _Context = std::basic_format_context<_Sink_iter, wchar_t>]': c:\gcc1300\include\c++\13.0.0\format:3652:39: required from '_Out std::vformat_to(_Out, wstring_view, wformat_args) [with _Out = __format::_Sink_iter; wstring_view = basic_string_view; wformat_args = basic_format_args, wchar_t> >]' c:\gcc1300\include\c++\13.0.0\format:3682:20: required from here c:\gcc1300\include\c++\13.0.0\format:3614:24: error: 'std::basic_format_context<_Out, _CharT>::basic_format_context(std::basic_format_args >, _Out) [with _Out = std::__format::_Sink_iter; _CharT = wchar_t]' is private within this context 3614 | ? _Context(__args, __sink_out) |^~~~
[Bug c++/108058] Missed optimization with O3 and m32 when unwinding a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108058 pionere at freemail dot hu changed: What|Removed |Added Component|target |c++ --- Comment #2 from pionere at freemail dot hu --- Yes, I'm talking about the code size (missed cross-jumping). I'm not sure what do you mean by 'epilogue emission happens too late'. Do you mean it is too complicated to solve the problem? If yes, please feel free to close the issue with WONTFIX.
[Bug debug/108061] '-fcompare-debug' failure (length) w/ -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108061
--- Comment #1 from Arseny Solokha ---
Created attachment 54066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54066=edit
gkd diff #2
The following change yields the attached fiff instead:
@ -16,7 +16,7 @@ quux (int x)
int
bar (int x, int y)
{
- return sub (n < x, quux (y) + 1);
+ return sub (n < x, quux (y) + 1 + x);
}
int
[Bug debug/108061] New: '-fcompare-debug' failure (length) w/ -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108061
Bug ID: 108061
Summary: '-fcompare-debug' failure (length) w/ -m32 -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-e300c3-linux-gnu
Created attachment 54065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54065=edit
gkd diff
gcc 13.0.0 20221204 snapshot (g:24b9337d1f1b5197b6498dceb9074319be003449) fails
-fcompare-debug check when compiling the following testcase w/ -m32 -O2
-fcompare-debug:
volatile unsigned short int m;
volatile signed short int n;
int
sub (int x, int y)
{
return x - y;
}
unsigned int
quux (int x)
{
return x ? x : 1;
}
int
bar (int x, int y)
{
return sub (n < x, quux (y) + 1);
}
int
foo (int x)
{
return bar (m, quux (3));
}
% powerpc-e300c3-linux-gnu-gcc-13 -m32 -O2 -fcompare-debug -c ndat8d3d.c
powerpc-e300c3-linux-gnu-gcc-13: error: ndat8d3d.c: '-fcompare-debug' failure
(length)
gkd diff attached.
[Bug sanitizer/108060] New: UBsan missed an out-of-bound bug at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
Bug ID: 108060
Summary: UBsan missed an out-of-bound bug at -O0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, UBsan at -O0 missed reporting the out-of-bound access,
while -O1 and above caught it.
Clang could detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/Tb9Mern7M
% cat a.c
int a[8];
short b;
char c;
int main() {
b = -32768;
a[b] |= c;
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
Segmentation fault
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:6:4: runtime error: index -32768 out of bounds for type 'int [8]'
%
Interestingly, if you don't use `-fno-sanitize-recover=all`, none of opt levels
could detect it:
% gcc-tk -O1 -fsanitize=undefined a.c && ./a.out
Segmentation fault
%
[Bug tree-optimization/108051] Missing array-bounds warning when not using -ftracer flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108051 Leandro Nini changed: What|Removed |Added CC||drfiemost at email dot it --- Comment #1 from Leandro Nini --- Created attachment 54064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54064=edit test-bz108051.c Reduced testcase, it doesn't error out if the -ftracer flag is omitted $ gcc -O2 -ftracer -Wall -Werror=array-bounds test-bz108051.c
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #10 from Richard Biener --- Should be fixed in GCC 13.
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d13b86f932ff7b9d8f41483fd869c637b67d4dec commit r13-4600-gd13b86f932ff7b9d8f41483fd869c637b67d4dec Author: Richard Biener Date: Sun Dec 11 14:07:34 2022 +0100 tree-optimization/89317 - missed folding of (p + 4) - >d The PR notices we fail to simplify a_4 = _3(D)->data; b_5 = x_3(D) + 16; _1 = b_5 - a_4; together with the enabler handling ADDR_EXPR leafs in separate stmts in match.pd the suggested patterns work. PR tree-optimization/89317 * match.pd ((p + b) - >c -> b - offsetof(c)): New patterns. * gcc.dg/tree-ssa/pr89317.c: New testcase.
[Bug tree-optimization/107617] SCC-VN with len_store and big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Richard Biener --- Ping - I'm waiting for you to confirm this fixes the issue.
[Bug tree-optimization/106904] [12 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] |[12 Regression] Incorrect |Incorrect |-Wstringop-overflow with |-Wstringop-overflow with|partial memcpy() into a |partial memcpy() into a |nested structure |nested structure| Known to work||13.0 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/106904] [12/13 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f8d136e50e6f82cba793483d910a2b2643108508 commit r13-4598-gf8d136e50e6f82cba793483d910a2b2643108508 Author: Richard Biener Date: Wed Dec 7 14:42:24 2022 +0100 tree-optimization/106904 - bogus -Wstringopt-overflow with vectors The following avoids CSE of >wp to >wp.hwnd confusing -Wstringopt-overflow by making sure to produce addresses to the biggest container from vectorization. For this I introduce strip_zero_offset_components which turns >wp.hwnd into &(*ps) and use that to base the vector data references on. That will also work for addresses with variable components, alternatively emitting pointer arithmetic via calling get_inner_reference and gimplifying that would be possible but likely more intrusive. This is by no means a complete fix for all of those issues (avoiding ADDR_EXPRs in favor of pointer arithmetic might be). Other passes will have similar issues. In theory that might now cause false negatives. PR tree-optimization/106904 * tree.h (strip_zero_offset_components): Declare. * tree.cc (strip_zero_offset_components): Define. * tree-vect-data-refs.cc (vect_create_addr_base_for_vector_ref): Strip zero offset components before building the address. * gcc.dg/Wstringop-overflow-pr106904.c: New testcase.
[Bug c++/108059] internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059
LIU Hao changed:
What|Removed |Added
Known to fail||10.3.0, 11.1.0
Target||x86_64-linux-gnu
Host||x86_64-linux-gnu
--- Comment #1 from LIU Hao ---
Reduced testcase, also ICEs with GCC 10.3.0 and 11.1.0, but 9.4.0 is fine:
```
template using a = int;
template auto b() {
[](auto... c) { [](a...) {}; };
}
template using e = decltype(b);
e<1> f;
```
```
$ g++-10 -std=c++17 test.cc
test.cc: In instantiation of ‘auto b() [with int = 1]’:
test.cc:5:24: required by substitution of ‘template using e = decltype
(b) [with int d = 1]’
test.cc:6:4: required from here
test.cc:3:19: internal compiler error: in tsubst_copy, at cp/pt.c:16425
3 | [](auto... c) { [](a...) {}; };
| ^~
0x7f76079c809a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
```
[Bug c++/108059] New: internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059
Bug ID: 108059
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:16425
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This was reported on IRC by Vladimir_Kozelko:
https://godbolt.org/z/oMjTc1813
```
#include
struct unused {
template
constexpr unused(T&&) noexcept {}
};
template
using ignore_index_t = unused;
template
constexpr inline auto pack_element(Tp&&... arr) noexcept {
auto unpack = [&](auto... v){
auto impl = [](ignore_index_t..., auto&& out, auto&&) {
return out;
};
};
}
template
using pack_element_t = decltype(pack_element(std::declval()...));
void f1() { using H = pack_element_t<1, int, int&>; }
//idea (and it works):
auto test = [](auto v){
constexpr auto vv = v;
};
void f2() { test(std::integral_constant()); }
```
which ICEs:
```
: In instantiation of 'constexpr auto pack_element(Tp&& ...) [with int
index = 1; Tp = {int, int&}]':
:21:52: required by substitution of 'template using pack_element_t = decltype (pack_element((declval)()...))
[with int index = 1; Tp = {int, int&}]'
:23:50: required from here
:14:21: internal compiler error: in tsubst_copy, at cp/pt.cc:16949
14 | auto impl = [](ignore_index_t..., auto&& out, auto&&) {
| ^~
15 | return out;
| ~~~
16 | };
| ~
0x1bb069e internal_error(char const*, ...)
???:0
0x6ff396 fancy_abort(char const*, int, char const*)
???:0
0x88d46f tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x87aa08 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x87a50a tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x887353 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x87a817 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x89084a tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x890a58 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x87d4f7 instantiate_decl(tree_node*, bool, bool)
???:0
0x7a1e03 maybe_instantiate_decl(tree_node*)
???:0
0x72588e build_new_function_call(tree_node*, vec**, int)
???:0
0x8aaf0c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x87abbd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x87b097 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x891f4a instantiate_template(tree_node*, tree_node*, int)
???:0
0x87a682 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x88495f lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x8aa461 finish_template_type(tree_node*, tree_node*, int)
???:0
0x861eaa c_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/108058] Missed optimization with O3 and m32 when unwinding a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108058 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||i?86-*-* Component|c++ |target Known to work||4.7.3 Known to fail||4.8.5 --- Comment #1 from Richard Biener --- I'm not sure what you are complaining about - I see two returns with 64bit code generation as well. The code is vectorized and the epilogue is completely peeled. Are you complaining about code size here and thus the appearant missed cross-jumping of the epilogue? I think epilogue emission happens too late for this. GCC 4.7 is the last with vectorization and a single return point but it also doesn't peel the epilogue (4.8 does).
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3 Summary|backward compatibility |[12/13 Regression] backward |issue between 11 and 12 |compatibility issue between ||11 and 12 CC||burnus at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||sandra at gcc dot gnu.org Keywords||ABI --- Comment #5 from Richard Biener --- CCing folks doing the CFI work for GCC 12.
[Bug middle-end/108042] [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108042] [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-12-11
Ever confirmed|0 |1
CC||hubicka at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |10.5
Status|UNCONFIRMED |WAITING
--- Comment #2 from Richard Biener ---
t2.c:1:6: warning: 'weakref' attribute should be accompanied with an 'alias'
attribute [-Wattributes]
1 | void KNOWNNOTOBEAFUNCTION(void) __attribute__((weakref));
| ^~~~
did you want to use __attribute__((weak)) here? I think this works as
designed.
Note handle_weakref_attribute has
/* The idea here is that `weakref("name")' mutates into `weakref,
alias("name")', and weakref without arguments, in turn,
implicitly adds weak. */
if (args)
{
attr = tree_cons (get_identifier ("alias"), args, attr);
attr = tree_cons (get_identifier ("weakref"), NULL_TREE, attr);
*no_add_attrs = true;
decl_attributes (node, attr, flags);
}
else
{
if (lookup_attribute ("alias", DECL_ATTRIBUTES (*node)))
error_at (DECL_SOURCE_LOCATION (*node),
"%qE attribute must appear before %qs attribute",
name, "alias");
/* Can't call declare_weak because it wants this to be TREE_PUBLIC,
and that isn't supported; and because it wants to add it to
the list of weak decls, which isn't helpful. */
DECL_WEAK (*node) = 1;
but then process_common_attributes does
tree weakref = lookup_attribute ("weakref", DECL_ATTRIBUTES (decl));
if (weakref && !lookup_attribute ("alias", DECL_ATTRIBUTES (decl)))
{
warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wattributes,
"% attribute should be accompanied with"
" an % attribute");
DECL_WEAK (decl) = 0;
DECL_ATTRIBUTES (decl) = remove_attribute ("weakref",
DECL_ATTRIBUTES (decl));
}
this diagnostic does not match the documentation which gives the plain
'weakref' semantics of 'weak'.
[Bug tree-optimization/108041] ivopts results in extra instruction in simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-11 --- Comment #2 from Richard Biener --- Confirmed also on x86_64 btw.
[Bug tree-optimization/108041] ivopts results in extra instruction in simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- I think IVOPTs does not consider the use on the exit edge and its effect on liveness but it does consider both IVs.
[Bug tree-optimization/108023] Incorrect line number in ASAN's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023 --- Comment #2 from Richard Biener --- LIM store-motion combines possibly multiple store locations into a single one, and I agree it's possibly confusing to assign the location to the real store in this way.
[Bug c++/108058] New: Missed optimization with O3 and m32 when unwinding a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108058
Bug ID: 108058
Summary: Missed optimization with O3 and m32 when unwinding a
loop
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pionere at freemail dot hu
Target Milestone: ---
An unwinded loop produces a suboptimal code with O3 and m32 flags.
Example:
#include
void copyFunc(uint8_t* dst, uint8_t* src, int n)
{
while (n > 0) {
*(uint32_t*)dst = *(uint32_t*)src;
dst += 4;
src += 4;
n--;
}
}
Since v 4.9.4 the loop is unwinded and produces two return points:
...
.L1:
pop ebx
pop esi
pop edi
ret
...
pop ebx
pop esi
pop edi
ret
Apparently this does not seem to happen if m32 is not set (probably there are
enough registers to use).
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317 Richard Biener changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- I have a patch in testing for the missed optimization on GIMPLE.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #13 from cqwrteur --- (In reply to cqwrteur from comment #12) > (In reply to LIU Hao from comment #11) > > It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la > > files are not necessary and should not be installed. > > but your build scripts do that. I would even argue cmake would be better than autotool for you mcfgthread
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #12 from cqwrteur --- (In reply to LIU Hao from comment #11) > It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la > files are not necessary and should not be installed. but your build scripts do that.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #11 from LIU Hao --- It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la files are not necessary and should not be installed.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Rimvydas (RJ) changed: What|Removed |Added CC||rimvydas.jas at gmail dot com --- Comment #16 from Rimvydas (RJ) --- Created attachment 54063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54063=edit rename intermediate extensions to .fi or .fii Emitting intermediate files using plain foo.f90 form is a very annoying issue when trying to modernize archaic codebases to be used in current projects and it really helps when intermediate files could be saved without disturbing used native build system habitat. Consider the following: $ cat bar.F SUBROUTINEABINIT PART 2( ARGU x MENT) E N D S U B R O U T I N E $ gfortran --save-temps -c bar.F $ gfortran -c bar.s $ gfortran -c bar.f90 bar.F:1:8: 1 | SUBROUTINEABINIT PART 2( ARGU | 1 Error: Unclassifiable statement at (1) This shows that intermediate Fortran source produced cannot be used again because of fixed/free form differences while assembly file is fine. There are N+K build system variants that do crazy and wonderful things like filtering/substituting flags, redirecting STDERR/STDOUT for cleaner warning messages, silently moving sources and objects with strange rules, hiding compilation lines in python scripts, substituting symbol names in assembly files and even substituting names in source code on the fly to solve symbol conflicts between contrib codebases using sed(1) or heavy cpp(1). So sometimes it is simply easier to modify the compiler and recompile (after all it does not take long for gcc). Attached is a simple diff variant that uses F77/F90+ to emit .fi/.fii intermediate source files accordingly (inspired by what ObjC/ObjC++ do with intermediates .mi/.mii files). Such small change really helped to double/triple crosscheck very complicated project with mixed F77/F90 using sometimes crazy cpp(1) macros for the "hooks". Using .fii extension for all sources of .F90/.F95/.F03/.F08/.Fyz seems like a logical solution.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #10 from cqwrteur --- (In reply to LIU Hao from comment #9) > (In reply to cqwrteur from comment #8) > > if I delete them by hand, then gcc could not build anymore since build > > scripts of libstdc++ would complain .la do not exist > > No library in MSYS2 has been installed with .la files because they are never > necessary. i do not even understand why you are talking about msys2. I do Canadian compilation on linux. Cross compiling mcfgthread on Linux. This has nothing to do with msys2. I do not use msys2.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #9 from LIU Hao --- (In reply to cqwrteur from comment #8) > if I delete them by hand, then gcc could not build anymore since build > scripts of libstdc++ would complain .la do not exist No library in MSYS2 has been installed with .la files because they are never necessary.
[Bug go/108057] [13 Regression] libgo21 not ABI compatible gcc12 vs gcc13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057 --- Comment #1 from Richard Biener --- Forcing libgo.so.21 from the GCC 12 build makes the build of golang 1.9 succeed here.
[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 David Binderman changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from David Binderman --- 09c91caeb84e7c36 worked fine. The remaining interval seems to be [09c91caeb84e7c36..7410032a772a9e77], which is six revisions, four of which are by Jason and two unrelated non-C++. Jason's best opinion sought.
[Bug go/108057] [13 Regression] libgo21 not ABI compatible gcc12 vs gcc13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057 Richard Biener changed: What|Removed |Added Keywords||ABI Priority|P3 |P1 Target Milestone|--- |13.0 Summary|libgo21 not ABI compatible |[13 Regression] libgo21 not |gcc12 vs gcc13? |ABI compatible gcc12 vs ||gcc13?
[Bug go/108057] New: libgo21 not ABI compatible gcc12 vs gcc13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108057 Bug ID: 108057 Summary: libgo21 not ABI compatible gcc12 vs gcc13? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: rguenth at gcc dot gnu.org Target Milestone: --- libgo didn't bump the SONAME for GCC 13. When building golang 1.9 with GCC go from GCC 12 but the libgo.so.21 from GCC 13 I get [8s] # Building Go bootstrap tool. [8s] cmd/dist [8s] /usr/bin/go: Symbol `syscall..types' has different size in shared object, consider re-linking [8s] /usr/bin/go: Symbol `runtime..types' has different size in shared object, consider re-linking [8s] go: no such tool "cgo" [8s] error: Bad exit status from /var/tmp/rpm-tmp.WRcxJv (%build)
[Bug sanitizer/108021] sanitizer used with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108021 laurent.alfonsi at linaro dot org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from laurent.alfonsi at linaro dot org --- I have tested with future merged branch of qemu https://gitlab.com/stsquad/qemu/-/commits/review/linux-user-vma-v2 and it fail properly $ qemu-aarch64 -L sysroot-with-libasan-from-master-branch ./a.out AddressSanitizer: CHECK failed: asan_poisoning.cpp:38 "((AddrIsInMem(addr))) != (0)" (0x0, 0x0) (tid=16754) The RAM memory doesn't grow continuously anymore. >From my pov, it is fair. This issue that will be fixed when merging the qemu branch.
[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 --- Comment #2 from David Binderman --- That worked fine, so trying 09c91caeb84e7c36.
[Bug libfortran/108056] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Comment #4 from Rimvydas (RJ) ---
$ gfortran11 -g -fno-backtrace pr108056.f90
$ ./a.out && echo works
works
<--copy executable to system with gcc-13 trunk-->
$ ./a.out
Internal Error: Invalid type in descriptor
$ gdb ./a.out
(gdb) b _gfortrani_internal_error
(gdb) b ISO_Fortran_binding.c:219
(gdb) r
_gfortran_gfc_desc_to_cfi_desc(d_ptr=0x7fffe948, s=0x7fffe970) at
/gcc_trunk/libgfortran/runtime/ISO_Fortran_binding.c:219
219 internal_error (NULL, "Invalid type in descriptor");
(gdb) where
#0 _gfortran_gfc_desc_to_cfi_desc (d_ptr=0x7fffe948, s=0x7fffe970) at
/gcc_trunk/libgfortran/runtime/ISO_Fortran_binding.c:219
#1 0x524b in pub_f08ts (a=, b=) at pr108056.f90:29
#2 0x51f0 in bugsub (a=1, b=-3.08878791e-13) at pr108056.f90:35
#3 0x5313 in bug () at pr108056.f90:43
(gdb) p d->type
$1 = 11
(gdb) p type
$2 = 11 '\v'
(gdb) p *s
$3 = {base_addr = 0x7fffe9ec, offset = 0, dtype = {elem_len = 4, version =
0, rank = 0 '\000', type = 11 '\v', attribute = 2}, span = 4, dim =
0x7fffe998}
(gdb) p/d BT_ASSUMED
$4 = 11
/* NOTE: Since GCC 12, the FE generates code to do the conversion
directly without calling this function. */
void
gfc_desc_to_cfi_desc (CFI_cdesc_t **d_ptr, const gfc_array_void *s)
{
Looks to be backwards compatibility issue, BT_ASSUMED not handled?
[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 --- Comment #1 from David Binderman --- I am having a go at a git bisect. Trying 892e8c520be37d0a.
