[Bug target/91598] [9 regression] 60% speed drop on neon intrinsic loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #11 from Tamar Christina --- Can this issue be closed? all inline assembly have been removed from arm_neon.h but backporting these are extremely unlikely.. (some are intrusive)
[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9b7ab853bf33106fd0539e36d6ce7730269026e1 commit r12-2873-g9b7ab853bf33106fd0539e36d6ce7730269026e1 Author: Jakub Jelinek Date: Thu Aug 12 09:16:13 2021 +0200 c++: Fix ICE on defaulted spaceship with pointer return type [PR94162] The spaceship-synth-neg6.C testcase ICEs because we call cat_tag_for on the explicit return type, but pointer types don't have TYPE_LINKAGE_IDENTIFIER. The patch fixes that by checking for CLASS_TYPE_P only and also adds verification that it is in std namespace, so we don't return non-cc_last for my_namespace::partial_ordering. The g++.dg/cpp2a/spaceship-synth11.C testcase is from a PR that has been fixed with r12-619-gfc178519771db508c03611cff4a1466cf67fce1d (but not backported to 11). 2021-08-12 Jakub Jelinek gcc/cp/ PR c++/94162 * method.c (cat_tag_for): Return cc_last for !CLASS_TYPE_P or for classes not in std namespace. gcc/testsuite/ PR c++/99429 * g++.dg/cpp2a/spaceship-synth11.C: New test. PR c++/94162 * g++.dg/cpp2a/spaceship-synth-neg6.C: New test.
[Bug c++/94162] ICE [neg] bad return type in defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9b7ab853bf33106fd0539e36d6ce7730269026e1 commit r12-2873-g9b7ab853bf33106fd0539e36d6ce7730269026e1 Author: Jakub Jelinek Date: Thu Aug 12 09:16:13 2021 +0200 c++: Fix ICE on defaulted spaceship with pointer return type [PR94162] The spaceship-synth-neg6.C testcase ICEs because we call cat_tag_for on the explicit return type, but pointer types don't have TYPE_LINKAGE_IDENTIFIER. The patch fixes that by checking for CLASS_TYPE_P only and also adds verification that it is in std namespace, so we don't return non-cc_last for my_namespace::partial_ordering. The g++.dg/cpp2a/spaceship-synth11.C testcase is from a PR that has been fixed with r12-619-gfc178519771db508c03611cff4a1466cf67fce1d (but not backported to 11). 2021-08-12 Jakub Jelinek gcc/cp/ PR c++/94162 * method.c (cat_tag_for): Return cc_last for !CLASS_TYPE_P or for classes not in std namespace. gcc/testsuite/ PR c++/99429 * g++.dg/cpp2a/spaceship-synth11.C: New test. PR c++/94162 * g++.dg/cpp2a/spaceship-synth-neg6.C: New test.
[Bug libstdc++/101870] std::lerp is missing Arithmetic overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101870 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-08-12 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment #6 from Tamar Christina ---
f3 and g3 no longer use the stack:
f3:
ins v0.s[1], v1.s[0]
sub sp, sp, #16
add sp, sp, 16
ins v0.s[2], v2.s[0]
ins v0.s[3], v3.s[0]
ret
g3:
ldr s0, [x0]
sub sp, sp, #16
ld1 {v0.s}[1], [x1]
ld1 {v0.s}[2], [x2]
ld1 {v0.s}[3], [x3]
add sp, sp, 16
ret
Though we still allocate the space for it (but that's a general AArch64 issue).
for the other cases the only thing left is the initializations.
[Bug target/91598] [9 regression] 60% speed drop on neon intrinsic loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598 --- Comment #12 from Maxim Kuvyrkov --- (In reply to Tamar Christina from comment #11) > Can this issue be closed? all inline assembly have been removed from > arm_neon.h but backporting these are extremely unlikely.. (some are > intrusive) Hi Tamar, Looking at this I now remember that I have a couple of minor patches approved, but which I forgot to commit. Let me retest and commit those, and we can close this.
[Bug target/91598] [9 regression] 60% speed drop on neon intrinsic loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598 --- Comment #13 from Tamar Christina --- (In reply to Maxim Kuvyrkov from comment #12) > (In reply to Tamar Christina from comment #11) > > Can this issue be closed? all inline assembly have been removed from > > arm_neon.h but backporting these are extremely unlikely.. (some are > > intrusive) > > Hi Tamar, > > Looking at this I now remember that I have a couple of minor patches > approved, but which I forgot to commit. > > Let me retest and commit those, and we can close this. Hi Maxim, Thanks!
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474
Enrico Seiler changed:
What|Removed |Added
CC||enrico.seiler at hotmail dot de
--- Comment #2 from Enrico Seiler ---
Here is a version not dependent on range-v3:
https://godbolt.org/z/PvdhxGo5c
```
template
concept foo = __is_constructible(T, Args...);
class S
{
public:
S() = delete;
S(S const &) = default;
S(S &&) = default;
S & operator=(S const &) = default;
S & operator=(S &&) = default;
~S() = default;
};
int main()
{
// static_assert(!__is_constructible(S)); // OK
// static_assert(!foo); // OK
// static_assert(__is_constructible(S)); // FAILS
static_assert(foo); // ICE
}
```
The parameter pack is not necessary for the ICE to occur, however, it is what
META_IS_CONSTRUCTIBLE is expanded to in range-v3.
Using `concept foo = static_cast(__is_constructible(T, Args...));` will
remove the ICE, even though `__is_constructible` should already return a bool.
[Bug target/95964] AArch64 arm_neon.h arithmetic functions lack appropriate attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #4 from Tamar Christina --- (In reply to ktkachov from comment #3) > In GCC 11 these builtins have do get a fnspec attribute and the start > pointer is hoisted. But this happens only with -fno-trapping-math (part of > -Ofast) because the operation can raise FP exceptions and therefore is > considered to modify global state unless -fnop-trapping-math. > > Is that good enough for this PR or do we want more something more > fine-grained? This behavior seems reasonable to me given the default trapping math behavior. Is the current behavior good for you Richard S?
[Bug target/95962] Inefficient code for simple arm_neon.h iota operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2021-08-12
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||tnfchris at gcc dot gnu.org
--- Comment #1 from Tamar Christina ---
We generate the correct code at -O3 but not -O2.
At -O3 we generate
foo:
adrpx0, .LC0
sub sp, sp, #16
ldr q0, [x0, #:lo12:.LC0]
add sp, sp, 16
ret
where the problem seems to be at at -O2 store merging has broken up the
construction of `array` into two separate memory accesses:
MEM [(int *)&array] = 4294967296;
MEM [(int *)&array + 8B] = 12884901890;
whereas at -O3 we still have a single assignment:
MEM [(int *)&array] = { 0, 1, 2, 3 };
I'm not sure even if we made these loads gimple level if that would help. we'd
still have the explicit MEMs created by store merging.
Perhaps we should just make store-merging allow TImode merges and split them in
the backend if needed.
[Bug target/91753] Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||tnfchris at gcc dot gnu.org
Resolution|--- |FIXED
Target Milestone|--- |12.0
--- Comment #9 from Tamar Christina ---
Fixed in GCC 12 where we generate at -O1/2/3
neon_transform_nada(uint8x16x4_t, unsigned char*, int):
ldp q7, q6, [x0]
ldp q5, q4, [x0, 32]
cmp w1, 0
ble .L2
mov w2, 0
.L3:
add w2, w2, 1
tbx v7.16b, {v0.16b - v3.16b}, v7.16b
tbx v6.16b, {v0.16b - v3.16b}, v6.16b
tbx v5.16b, {v0.16b - v3.16b}, v5.16b
tbx v4.16b, {v0.16b - v3.16b}, v4.16b
cmp w1, w2
bne .L3
.L2:
stp q7, q6, [x0]
stp q5, q4, [x0, 32]
ret
[Bug target/47562] [meta-bug] keep track of Neon Intrinsics enhancements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562 Bug 47562 depends on bug 91753, which changed state. Bug 91753 Summary: Bad register allocation of multi-register types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958 Bug 95958 depends on bug 91753, which changed state. Bug 91753 Summary: Bad register allocation of multi-register types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877 Bug 98877 depends on bug 91753, which changed state. Bug 91753 Summary: Bad register allocation of multi-register types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/101872] New: static_cast succeeds in CRTP with incorrect type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101872 Bug ID: 101872 Summary: static_cast succeeds in CRTP with incorrect type Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vpervouchine at gmail dot com Target Milestone: --- Created attachment 51296 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51296&action=edit Preprocessor output. See the actual code from line 11011 onwards static_cast of *this to an incorrect "Derived" class inside a CRTP base succeeds when Derived itself is a variadic template, leading to invalid addressing of member variables of the derived class. Since the preprocessed file doesn't include comments, please see them in the source file here: https://godbolt.org/z/oKv1xeK9G
[Bug c++/100474] ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100474
--- Comment #3 from 康桓瑋 ---
(In reply to Enrico Seiler from comment #2)
> Here is a version not dependent on range-v3:
>
> https://godbolt.org/z/PvdhxGo5c
>
> ```
> template
> concept foo = __is_constructible(T, Args...);
>
> class S
> {
> public:
> S() = delete;
> S(S const &) = default;
> S(S &&) = default;
> S & operator=(S const &) = default;
> S & operator=(S &&) = default;
> ~S() = default;
> };
>
> int main()
> {
> // static_assert(!__is_constructible(S)); // OK
> // static_assert(!foo); // OK
> // static_assert(__is_constructible(S)); // FAILS
> static_assert(foo); // ICE
> }
> ```
>
> The parameter pack is not necessary for the ICE to occur, however, it is
> what META_IS_CONSTRUCTIBLE is expanded to in range-v3.
>
> Using `concept foo = static_cast(__is_constructible(T, Args...));`
> will remove the ICE, even though `__is_constructible` should already return
> a bool.
I can't imagine you can reduce it, thank you very much!
[Bug tree-optimization/101868] Incorrect reordering in -O2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101868 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Martin Liška --- (In reply to Andrew Pinski from comment #2) > (In reply to Andrew Pinski from comment #1) > > Works for me on the trunk: > > I almost want to say this was fixed by PR 101373. Yes, I can confirm that it was fixed with r12-2254-gfedcf3c476aff753. @Richi: Can we close it as dup?
[Bug tree-optimization/101868] Incorrect reordering in -O2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101868 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-08-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/101873] New: Compilation error of valid code with return local variable in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101873
Bug ID: 101873
Summary: Compilation error of valid code with return local
variable in C++20 mode
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The program as follows fails to compile in C++20 mode:
```
struct U {
U(int) {}
U(int&&) {}
};
U foo(int a = 0) { return a; }
int main() { foo(); }
```
But it is a valid program and other compilers accept it:
https://gcc.godbolt.org/z/fMvEPMGhq
[Bug c++/101873] Compilation error of valid code with return local variable in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101873 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is rejected since r11-2412-g1722e2013f05f1f1f99379dbaa0c0df356da731f aka PR91427 fix. Do the other compilers implement wg21.link/p1825 ? Whether your testcase is valid or not I'll defer to others.
[Bug c++/101874] New: [12 Regression] ICE with auto specifier for arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874
Bug ID: 101874
Summary: [12 Regression] ICE with auto specifier for arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
The two testcases from PR 60628 and PR 60629 (originally fixed in GCC 4.8.3)
started triggering ICEs again on trunk.
PR 60628:
===
#include
void foo(int i)
{
auto x[i] = { 0 };
}
===
PR 60629:
===
void foo(int i)
{
auto(*p)[i] = (int(*)[i])0;
}
===
They also crash in the same functions as before:
tsubst_copy and unify_array_domain
which are eventually called from do_auto_deduction:
PR60628.cc: In function 'void foo(int)':
PR60628.cc:5:11: internal compiler error: in tsubst_copy, at cp/pt.c:17243
5 | auto x[i] = { 0 };
| ^
0x6e7512 tsubst_copy
../../gcc/gcc/cp/pt.c:17243
0xaf1eb4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:20870
0xaf3651 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19639
0xaf46d9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19815
0xafd357 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19092
0xb0f64f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:15475
0xb0f6d3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:15920
0xaedaff do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:29561
[etc.]
PR60629.cc: In function 'void foo(int)':
PR60629.cc:3:28: internal compiler error: in unify_array_domain, at
cp/pt.c:23278
3 | auto(*p)[i] = (int(*)[i])0;
|^
0x6f380d unify_array_domain
../../gcc/gcc/cp/pt.c:23278
0xb0b138 unify
../../gcc/gcc/cp/pt.c:23848
0xb0abc9 unify
../../gcc/gcc/cp/pt.c:23829
0xb081f0 unify_one_argument
../../gcc/gcc/cp/pt.c:22107
0xb154da type_unification_real
../../gcc/gcc/cp/pt.c:6
0xaecaff do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:29637
[etc.]
I suspect that the regression was caused by Marek's commit r12-1933.
Marek, could you please have a look?
Unfortunately, the testsuite did not show the regression because it doesn't
contain the original tescases. The second one wasn't added because it was
deemed a duplicate (which makes sense as both ICEs reappered together).
The first testcase was added as g++.dg/cpp0x/auto42.C, but with a subtle
change:
auto x[1] = { 0 };
instead of
auto x[i] = { 0 };
The version in the testsuite actually never showed the ICE.
So we should probably add the original version to the test.
[Bug c++/101874] [12 Regression] ICE with auto specifier for arrays since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-08-12 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Summary|[12 Regression] ICE with|[12 Regression] ICE with |auto specifier for arrays |auto specifier for arrays ||since ||r12-1933-ge66d0b7b87d105d2 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it really started with r12-1933-ge66d0b7b87d105d2.
[Bug analyzer/101875] New: [12 Regression] ICE: Segmentation fault (in c_tree_printer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101875
Bug ID: 101875
Summary: [12 Regression] ICE: Segmentation fault (in
c_tree_printer)
Product: gcc
Version: 12.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-12.0.0-alpha20210808 snapshot (g:5f564fd013327977a4d04aa520237d17f641f01a)
ICEs when compiling the following testcase w/ -fanalyzer:
char *
fopen (const char *restrict, const char *restrict);
void
err (void);
void
k2 (void)
{
char *setfiles[1];
int i;
setfiles[i] = fopen("", "");
if (!setfiles[i])
err ();
}
% gcc-12.0.0 -fanalyzer -c bmx5okgd.c
during IPA pass: analyzer
bmx5okgd.c:14:6: internal compiler error: Segmentation fault
14 | if (!setfiles[i])
| ^
0xe510cf crash_signal
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/toplev.c:328
0x867960 c_tree_printer
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/c/c-objc-common.c:305
0x867960 c_tree_printer
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/c/c-objc-common.c:258
0x1adbf8d pp_format(pretty_printer*, text_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/pretty-print.c:1475
0x120e53b ana::evdesc::event_desc::formatted_print(char const*, ...) const
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/pending-diagnostic.cc:64
0x124b658 describe_state_change
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/sm-file.cc:128
0x124b658 describe_state_change
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/sm-file.cc:119
0x124b658 describe_state_change
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/sm-file.cc:213
0x1a689b6 ana::state_change_event::get_desc(bool) const
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/checker-path.cc:259
0x1a685c2 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/checker-path.cc:149
0x1a7b895 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/checker-path.h:571
0x1a7b895 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/diagnostic-manager.cc:1225
0x1a7f1b7 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/diagnostic-manager.cc:1128
0x1a7be31 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/diagnostic-manager.cc:1179
0x120528d ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/engine.cc:4988
0x120605c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/engine.cc:5045
0x11f7058 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210808/work/gcc-12-20210808/gcc/analyzer/analyzer-pass.cc:87
[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101860 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:04b4f3152593f85b05974528d1607619dd77d702 commit r12-2876-g04b4f3152593f85b05974528d1607619dd77d702 Author: Jakub Jelinek Date: Thu Aug 12 11:26:57 2021 +0200 i386: Fix up V32HImode permutations with -mno-avx512bw [PR101860] My patch from yesterday apparently broke some V32HImode permutations as the testcase shows. The first function assumed it would never be called in d->testing_p mode and so went right away into emitting the code. And the second one assumed V32HImode would never reach it, which now can for the !TARGET_AVX512BW case. We don't have a instruction in that case though. 2021-08-12 Jakub Jelinek PR target/101860 * config/i386/i386-expand.c (ix86_expand_vec_one_operand_perm_avx512): If d->testing_p, return true after performing checks instead of actually expanding the insn. (expand_vec_perm_broadcast_1): Handle V32HImode - assert !TARGET_AVX512BW and return false. * gcc.target/i386/avx512f-pr101860.c: New test.
[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101860 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/101873] Compilation error of valid code with return local variable in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101873 --- Comment #2 from Fedor Chelnokov --- Thanks, I assumed that the code is valid based on stackoverflow answer: https://stackoverflow.com/questions/68747489/is-the-local-variable-returned-by-a-function-automatically-moved-in-c20
[Bug c++/101873] Compilation error of valid code with return local variable in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101873 --- Comment #3 from Jakub Jelinek --- So questionable based on the status of https://wg21.link/p2266 and whether it will be a DR or not?
[Bug middle-end/101876] New: [290x] vector builtin vec_permi fails to resolve with #pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876
Bug ID: 101876
Summary: [290x] vector builtin vec_permi fails to resolve with
#pragma GCC target
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mhillen at linux dot ibm.com
Target Milestone: ---
When using #pragma GCC target("arch=z13,vx") to enable vectorization extensions
on s390x, __builtin_s390_vec_permi fails to resolve.
Example code:
#pragma GCC target("arch=z13,vx")
#include
typedef unsigned long long v2di __attribute__((vector_size(16)));
v2di foo(char *ptr) {
v2di v = *(v2di *)ptr;
v = vec_permi(v, v, 0);
return v;
}
Fails when compiled with gcc -c -march=zEC12, but compiles as expected with gcc
-march=z13
[Bug target/101743] [12 Regression] Error: insn does not satisfy its constraints since r12-2640-gf7bf03cf69ccb7dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101743 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- I can confirm it's fixed now.
[Bug middle-end/101876] [290x] vector builtin vec_permi fails to resolve with #pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101876 --- Comment #1 from Marius Hillenbrand --- Comparing results with -mdebug, the variant that should match is ignored with -march=z13: ... s390_resolve_overloaded_builtin, code = 606, __builtin_s390_vec_permi - overloaded checking variant number: 187 mismatch in operand: 1 incoming: v2di expected: vector(2) long long int checking variant number: 188 mismatch in operand: 1 incoming: v2di expected: vector(2) long long unsigned int checking variant number: 189 perfect match score: 0 ... with -march=zEC12: ... s390_resolve_overloaded_builtin, code = 606, __builtin_s390_vec_permi - overloaded checking variant number: 187 mismatch in operand: 1 incoming: v2di expected: vector(2) long long int checking variant number: 188 mismatch in operand: 1 incoming: v2di expected: vector(2) long long unsigned int checking variant number: 189 mismatch in operand: 1 incoming: v2di expected: vector(2) long long unsigned int checking variant number: 190 mismatch in operand: 1 incoming: v2di expected: vector(2) double In file included from tests/target-pragma-vector-builtins.c:13: tests/target-pragma-vector-builtins.c: In function 'foo': tests/target-pragma-vector-builtins.c:23:9: error: invalid parameter combination for intrinsic '__builtin_s390_vec_permi' 23 | v = vec_permi(v, v, 0); | ^ ...
[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2021-08-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #10 from Martin Liška --- > Ha :-) Too bad we can only warn "invalid sum of incoming frequencies", it > still > happens too often (read: at all) to actually error on it... that would > perhaps > grab people's attention :-) I can confirm switch lowering is not updating BB counts and I see some other issues related to edge probabilities. I have a partial fix, but I'm going to return to it once stage1 is gone.
[Bug analyzer/101875] [12 Regression] ICE: Segmentation fault (in c_tree_printer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101875 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-08-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r12-2337-g33255ad3ac14e395.
[Bug c++/57014] pretty-printer prints anonymous for template-parameter with a name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57014
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #3 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #0)
> /home/manuel/test3/src/gcc/testsuite/g++.dg/other/default5.C:47:22: error:
> default argument missing for parameter 2 of ‘void B< >::F2(int,
> int, int)’
> template void B::F2(int = 0, int, int) {} // { dg-error
> "default" }
> ^
>
> It should say 'void B::F2(int,int,int)
That is PR 20313
> The location is wrong, it should point to parameter 2.
That part is fixed (see comment 2).
*** This bug has been marked as a duplicate of bug 20313 ***
[Bug c++/20313] in diagnostic is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313 --- Comment #6 from Jonathan Wakely --- *** Bug 57014 has been marked as a duplicate of this bug. ***
[Bug c++/20313] in diagnostic is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313 --- Comment #7 from Jonathan Wakely --- As I said in PR 57014 comment 2: It would be nice if later declarations that name a template parameter could be used to "fill in" any unnamed template parameters from the original declaration, so that pretty printing isn't so ugly. That would mean we use "N" instead of "".
[Bug c++/20313] in diagnostic is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > That would mean we use "N" instead of "". Oops, sorry, in this PR it would be "i" not "N".
[Bug libstdc++/101867] avr libc build error for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #11 from Jonathan Wakely --- (In reply to cqwrteur from comment #9) > How to use stdio_pure as implementation? Since avrlibc does not provide > posix fd. --enable-cstdio=stdio_pure There is *lots* of work needed to build a hosted libstdc++ for AVR, this is a known problem (and is why libstdc++ is usually not built for AVR).
[Bug c++/101663] [11/12 Regression] GCC crashes when assigning one single_view to another.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101663
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:f65ae298d43b2dd280b6f3761d6f3ea8e572be61
commit r11-8857-gf65ae298d43b2dd280b6f3761d6f3ea8e572be61
Author: Patrick Palka
Date: Wed Aug 11 20:59:53 2021 -0400
c++: constexpr std::construct_at on empty field [PR101663]
Here during constexpr evaluation of
std::construct_at(&a._M_value)
we find ourselves in cxx_eval_store_expression where the target object
is 'a._M_value' and the initializer is {}. Since _M_value is an empty
[[no_unique_address]] member we don't create a sub-CONSTRUCTOR for it,
so we end up in the early exit code path for empty stores with mismatched
types and trip over the assert therein
gcc_assert (is_empty_class (TREE_TYPE (init)) && !lval);
because lval is true. The reason it's true is because the INIT_EXPR in
question is the LHS of a COMPOUND_EXPR, and evaluation of the LHS is
always performed with lval=true (to indicate there's no lvalue-to-rvalue
conversion).
This patch makes the code path in question handle the lval=true case
appropriately rather than asserting. In passing, it also consolidates
the duplicate implementations of std::construct_at/destroy_at in some
of the C++20 constexpr tests into a common header file.
PR c++/101663
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_store_expression): Handle the lval=true
case in the early exit code path for empty stores with mismatched
types.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/construct_at.h: New convenience header file that
defines minimal implementations of std::construct_at/destroy_at,
split out from ...
* g++.dg/cpp2a/constexpr-new5.C: ... here.
* g++.dg/cpp2a/constexpr-new6.C: Use the header.
* g++.dg/cpp2a/constexpr-new14.C: Likewise.
* g++.dg/cpp2a/constexpr-new20.C: New test.
(cherry picked from commit 21fd62e5ca9967bba8f97fd6244a8c6a564c2146)
[Bug libstdc++/101867] avr libc build error for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867
--- Comment #12 from Jonathan Wakely ---
(In reply to cqwrteur from comment #8)
> But it is not documented.
It is: https://gcc.gnu.org/install/configure.html#avr
>
> in the /src/c++11/system_error.cc
>
> #ifdef __AVR__
> return std::error_condition(ev, std::system_category());
> #else
> switch (ev)
> {
>
> #endif
>
> i feel this switch is pointless.
Why do you feel that?
Have you read [syserr.errcat.objects] p4?
How do you think your suggestion for __AVR__ conforms to that requirement?
> https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc/include/
> errno.h
>
> If you look at the errno.h here, it is pretty bad.
I don't know what you're saying here.
> I think this switch should just be removed.
How would you implement the requirement then?
[Bug c++/101663] [11/12 Regression] GCC crashes when assigning one single_view to another.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101663 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 11.3 and 12.
[Bug libstdc++/101867] avr libc build error for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement Keywords||build --- Comment #13 from Jonathan Wakely --- Marking as enhancement, since this is not a supported target for libstdc++ today, so is not expected to build.
[Bug other/101877] New: [s390x] ICE: canonical types differ for identical types when #pragma GCC target enables vector support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101877
Bug ID: 101877
Summary: [s390x] ICE: canonical types differ for identical
types when #pragma GCC target enables vector support
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mhillen at linux dot ibm.com
Target Milestone: ---
When compiling C++ code on s390x where the command line arguments select an
architecture level without vectorization support (e.g., -march=zEC12) but a
#pragma GCC target upgrades to an architecture level with -mvx (e.g., pragma
GCC target("arch=z13,vx") ), I observed the following ICE:
Example code:
#include
#pragma GCC target("arch=z13,vx")
typedef unsigned long long v2di __attribute__((vector_size(16)));
v2di bar() {
v2di v = vec_splat_u64(0);
return v;
}
g++ -march=zEC12 -c ~/pragma-vec2.cc
/home/mhillen/pragma-vec2.cc: In function ‘v2di bar()’:
/home/mhillen/pragma-vec2.cc:9:29: internal compiler error: canonical types
differ for identical types ‘v2di’ {aka ‘__vector(2) long long unsigned int’}
and ‘__vector(2) long long unsigned int’
9 | v2di v = vec_splat_u64(0);
| ^
0x155da39 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1558
0x12b58dd ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:749
0x12b7fdf convert(tree_node*, tree_node*)
../../gcc/cp/cvt.c:1683
0x15778ed convert_for_assignment
../../gcc/cp/typeck.c:9480
0x1578581 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.c:9722
0x1582407 digest_init_r
../../gcc/cp/typeck2.c:1251
0x15853a9 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/typeck2.c:1267
0x15853a9 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:742
0x12d4a23 check_initializer
../../gcc/cp/decl.c:7185
0x1308b57 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:8119
0x144af25 cp_parser_init_declarator
../../gcc/cp/parser.c:22556
0x141cef5 cp_parser_simple_declaration
../../gcc/cp/parser.c:15088
0x141f261 cp_parser_declaration_statement
../../gcc/cp/parser.c:14182
0x141fb5f cp_parser_statement
../../gcc/cp/parser.c:12273
0x1420bbf cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12679
0x1420d33 cp_parser_compound_statement
../../gcc/cp/parser.c:12628
0x14490c5 cp_parser_function_body
../../gcc/cp/parser.c:24762
0x14490c5 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24813
0x1449f05 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:30898
0x144b34f cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30814
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/101878] New: ICE with invalid lambda definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101878
Bug ID: 101878
Summary: ICE with invalid lambda definition
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 4.9.0
(where generic lambdas were introduced):
===
void foo()
{
[](auto) [ []{}; ];
}
===
bug.cc: In function 'void foo()':
bug.cc:3:16: error: expected ']' before '{' token
3 | [](auto) [ []{}; ];
|^
|]
bug.cc:3:17: internal compiler error: in dependent_type_p, at cp/pt.c:26774
3 | [](auto) [ []{}; ];
| ^
0x6e03a4 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:26774
0x9b9fcf require_complete_types_for_parms
../../gcc/gcc/cp/decl.c:14232
0x9b9fcf check_function_type
../../gcc/gcc/cp/decl.c:16449
0x9b9fcf start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:16648
0xa17325 start_lambda_function(tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:1428
0xaa4ad9 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:11637
0xaa4ad9 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10965
0xaa5593 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5666
0xaa82ed cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7563
0xa91a2a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9893
0xa9233c cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:10197
0xa938b2 cp_parser_expression
../../gcc/gcc/cp/parser.c:10367
0xa96f58 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:12531
0xaa2dff cp_parser_statement
../../gcc/gcc/cp/parser.c:12327
0xaa3e9d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:12679
0xaa3f78 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:12628
0xac35c0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:24762
0xac35c0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:24813
0xac428a cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:30898
0xac56c4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:30814
Please submit a full bug report, [etc.]
[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 --- Comment #5 from Martin Liška --- (In reply to Stefan Kneifel from comment #4) > Yes, but a programmer might choose to implement target clones for a shared > library using another language, e.g. hand-optimized assembler code (this was > the actual problem I had). Ah, I hadn't thought about such a use case. > Forbidding target_clone declarations would make that solution impossible, > which should IMHO not be the case. To my opinion, the original solution (if > the target_clone function declaration is public, then it should be regarded > as public) is the most consequent one. All right, I'm going to send such a patch.
[Bug driver/48083] DEPENDENCIES_OUTPUT + -no-integrated-cpp produces bad dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48083 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-12 --- Comment #1 from Andrew Pinski --- Confirmed, though I don't know why anyone would use -no-integrated-cpp these days anyways.
[Bug c++/101879] New: Broken diagnostic: 'vec_perm_expr' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101879
Bug ID: 101879
Summary: Broken diagnostic: 'vec_perm_expr' not supported by
dump_expr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet produces a garbled diagnostic
('vec_perm_expr' not supported by dump_expr):
template
auto foo(const T& x) -> decltype(__builtin_shuffle(x,x)) { return }
bug.cc: In function 'decltype ('vec_perm_expr' not supported by
dump_expr) foo(const T&)':
bug.cc:6:67: error: expected primary-expression before '}' token
6 | auto foo(const T& x) -> decltype(__builtin_shuffle(x,x)) { return }
| ^
bug.cc:6:66: error: expected ';' before '}' token
6 | auto foo(const T& x) -> decltype(__builtin_shuffle(x,x)) { return }
| ^~
| ;
[Bug tree-optimization/101451] Incorrect -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101451 --- Comment #2 from Quentin Armitage --- Created attachment 51297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51297&action=edit ipvswrapper.i for strncpy truncated warning The following warning is generated: gcc -c -o ipvswrapper.o1 -O2 -Wstringop-truncation ipvswrapper.i In file included from /usr/include/string.h:519, from ../../lib/timer.h:28, from ../../keepalived/include/vrrp.h:40, from ../../keepalived/include/ipvswrapper.h:29, from ipvswrapper.c:34: In function ‘strncpy’, inlined from ‘ipvs_set_srule’ at ipvswrapper.c:494:7: /usr/include/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’ output may be truncated copying 15 bytes from a string of length 15 [-Wstringop-truncation] 95 | return __builtin___strncpy_chk (__dest, __src, __len, | ^~ 96 | __glibc_objsize (__dest)); | ~~
[Bug testsuite/50198] New test gcc.c-torture/execute/scal-to-vec1.c fails on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50198 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0 Component|c |testsuite Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by r0-114701.
[Bug tree-optimization/101451] Incorrect -Wstringop-truncation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101451
--- Comment #3 from Quentin Armitage ---
According to the man page for strncat:
As with strcat(), the resulting string in dest is always null-terminated.
If src contains n or more bytes, strncat() writes n+1 bytes to dest
(n from src plus the terminating null byte). Therefore, the size of dest must
be at least strlen(dest)+n+1.
Based on the above, in the test case strncat should copy 15 bytes (sizeof(dest)
- 1), and then add a terminating null byte.
I think the following code snippet demonstrates that:
#include
#include
int main(__attribute__((unused)) int argc, __attribute__((unused)) char **argv)
{
char dst[16] = "012345678901234";
unsigned char *p = dst;
dst[5] = '\0';
strncat(dst, "abcdefg", 5);
for (int i = 0; i < 16; i++)
printf("0x%2.2x ", *p++);
printf("\n");
}
>Do you have a full testcase that you can share, we will try to reduce it and
>see why it is still failing.
I have attached ipvswrapper.i, which when compiled with -O2
--Wstringop-truncation produces:
/usr/include/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’ output
may be truncated copying 15 bytes from a string of length 15
[-Wstringop-truncation]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ^~
96 | __glibc_objsize (__dest));
[Bug tree-optimization/95176] Failure to optimize division followed by multiplication to modulo followed by subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95176 Arjun Shankar changed: What|Removed |Added CC||arjun.is at lostca dot se --- Comment #2 from Arjun Shankar --- This appears to have been fixed as bug 96696 via the following commit: https://gcc.gnu.org/g:3dcd1334b4f522352b80814513fdca902fc2a207
[Bug c++/101879] Broken diagnostic: 'vec_perm_expr' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101879 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/101880] New: mangling vec_perm_expr is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101880
Bug ID: 101880
Summary: mangling vec_perm_expr is not implemented
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
template
auto foo(const T& x) -> decltype(__builtin_shuffle(x,x)) { return x; }
#define vector(x,y) x __attribute__((vector_size(y*sizeof(x
vector(int,16) y(vector(int,16) x)
{
return foo(x);
}
CUT
We produce currently:
: In instantiation of 'decltype ('vec_perm_expr' not supported by
dump_expr) foo(const T&) [with T = __vector(16) int]':
:3:6: sorry, unimplemented: mangling vec_perm_expr
3 | auto foo(const T& x) -> decltype(__builtin_shuffle(x,x)) { return x; }
| ^~~
[Bug target/101696] Function multiversioning not usable with new x86-64-v*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696 Martin Liška changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED --- Comment #9 from Martin Liška --- I've just sent patch to ML: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577275.html
[Bug c++/101881] New: [9/10/11/12 Regression] ICE with vector type in template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101881
Bug ID: 101881
Summary: [9/10/11/12 Regression] ICE with vector type in
template alias
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet triggers an ICE since GCC 7.1.0:
=
template using A = int __attribute__((vector_size(N)))*;
void foo(A<4>) {}
=
bug.cc:3:6: internal compiler error: in add_substitution, at cp/mangle.c:462
void foo(A<4>) {}
^~~
0x8014a5 add_substitution
../../gcc-7.5.0/gcc/cp/mangle.c:461
0x7fa97b write_type
../../gcc-7.5.0/gcc/cp/mangle.c:2413
0x7fd114 write_method_parms
../../gcc-7.5.0/gcc/cp/mangle.c:2828
0x7fd3f6 write_bare_function_type
../../gcc-7.5.0/gcc/cp/mangle.c:2764
0x80505c mangle_decl_string
../../gcc-7.5.0/gcc/cp/mangle.c:3821
0x8053c3 get_mangled_id
../../gcc-7.5.0/gcc/cp/mangle.c:3843
0x8053c3 mangle_decl(tree_node*)
../../gcc-7.5.0/gcc/cp/mangle.c:3913
0x102833e decl_assembler_name(tree_node*)
../../gcc-7.5.0/gcc/tree.c:671
0x1077ac7 notice_global_symbol(tree_node*)
../../gcc-7.5.0/gcc/varasm.c:1656
0x96fdd9 cgraph_node::finalize_function(tree_node*, bool)
../../gcc-7.5.0/gcc/cgraphunit.c:442
0x7b5e9f expand_or_defer_fn(tree_node*)
../../gcc-7.5.0/gcc/cp/semantics.c:4321
0x74a3a9 cp_parser_function_definition_after_declarator
../../gcc-7.5.0/gcc/cp/parser.c:26468
0x74b07e cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-7.5.0/gcc/cp/parser.c:26371
0x74b07e cp_parser_init_declarator
../../gcc-7.5.0/gcc/cp/parser.c:19353
0x745e3c cp_parser_simple_declaration
../../gcc-7.5.0/gcc/cp/parser.c:12886
0x746d77 cp_parser_block_declaration
../../gcc-7.5.0/gcc/cp/parser.c:12711
0x7511e4 cp_parser_declaration
../../gcc-7.5.0/gcc/cp/parser.c:12609
0x75161b cp_parser_declaration_seq_opt
../../gcc-7.5.0/gcc/cp/parser.c:12485
0x751902 cp_parser_translation_unit
../../gcc-7.5.0/gcc/cp/parser.c:4368
0x751902 c_parse_file()
../../gcc-7.5.0/gcc/cp/parser.c:38643
Please submit a full bug report, [etc.]
This is related to PR 83997, but without -flto. And we have a regression.
[Bug c++/101881] [9/10/11/12 Regression] ICE with vector type in template alias since r7-2549-gf3365c1201908df5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101881 Martin Liška changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |with vector type in |with vector type in |template alias |template alias since ||r7-2549-gf3365c1201908df5 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-12 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r7-2549-gf3365c1201908df5.
[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Known to work||4.8.1 Ever confirmed|0 |1 Known to fail||4.6.4, 4.7.4 Last reconfirmed||2021-08-12 --- Comment #5 from Andrew Pinski --- The C part of this bug was fixed with r0-120559. I don't know what fixed the C++ side of things though because it was before 4.7.x. A testcase for this should definitely be put in.
[Bug c++/57572] vector operators don't participate in overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/27433] vector template argument is not fully supported in function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27433 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- The original issue was fixed, the other issue is similar to PR 57572 so closing this one.
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 27433, which changed state. Bug 27433 Summary: vector template argument is not fully supported in function arguments https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27433 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/100766] Template type deduction fails with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100766 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 100765. *** This bug has been marked as a duplicate of bug 100765 ***
[Bug c++/100765] attribute incorrectly applied during type alias deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100765 --- Comment #1 from Andrew Pinski --- *** Bug 100766 has been marked as a duplicate of this bug. ***
[Bug c++/100765] attribute incorrectly applied during type alias deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100765 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/100765] attribute incorrectly applied during type alias deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100765
--- Comment #3 from Andrew Pinski ---
GNU++98 version:
#define vec __attribute__((vector_size(4)))
template
vec T f(vec T);
vec int ff(vec int t)
{
return f(t);
}
- CUT
And one which rejects a different way:
#define vec __attribute__((vector_size(4)))
template
vec T f(T a, vec T);
vec int ff(int a, vec int t)
{
return f(a, t);
}
[Bug middle-end/85320] Segmentation fault when building XKAAPI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85320 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- No feedback/testcase in over 3 years so closing
[Bug middle-end/86156] ffmpeg clean clone fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86156 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback/testcase in over 3 years so closing.
[Bug c++/101878] ICE with invalid lambda definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101878 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-12 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/101878] ICE with invalid lambda definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101878 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is definitely a dup of bug 95931. I am not all 100% sure PR 95931 is a dup of bug 96097 but that is just me. *** This bug has been marked as a duplicate of bug 95931 ***
[Bug c++/95931] ICE in dependent_type_p, at cp/pt.c:26326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931 Andrew Pinski changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 101878 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101868] [9/10/11 Regression] Incorrect reordering in -O2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101868 Andrew Pinski changed: What|Removed |Added Known to fail||11.2.0 Target Milestone|--- |9.5 Summary|Incorrect reordering in -O2 |[9/10/11 Regression] |with LTO|Incorrect reordering in -O2 ||with LTO Known to work||12.0 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > (In reply to Andrew Pinski from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > Works for me on the trunk: > > > > I almost want to say this was fixed by PR 101373. > > Yes, I can confirm that it was fixed with r12-2254-gfedcf3c476aff753. > @Richi: Can we close it as dup? We should at least put this as a testcase. I suspect it is a regression from when -fcode-hoisting was added to GCC too.
[Bug c++/101872] static_cast succeeds in CRTP with incorrect type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101872
--- Comment #1 from Andrew Pinski ---
Original testcase (since we won't know if godbolt will be around in 10-20 years
...):
#include
template typename ContainerImpl, typename Policy>
struct BaseContainer {
using Impl = ContainerImpl; // this isn't our actual Impl (missing
Handlers template args...)...
Impl & impl() { return static_cast(*this); } // this shouldn't
compile
int start() {
return impl().on_start(); // ... so impl() casts this to incorrect
value
}
};
template
struct BaseUiContainer : BaseContainer {
int on_start() {
return m_x * 2; // ... and because of the wrong cast this->m_x is
pointing elsewhere
}
private:
std::tuple m_handlers; // comment this out to get the correct
output of 4
int m_x = 2;
};
struct Handler {
char a[128];
};
template
struct MyUiContainer : BaseUiContainer {
};
int main() {
struct P {};
MyUiContainer container;
return container.start();
}
[Bug c++/101344] braced-init-list not supported in an aggregate deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101344
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
CC||ppalka at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=101803
Status|NEW |ASSIGNED
--- Comment #2 from Patrick Palka ---
Another rejects-valid example (I think):
template
struct C { int m; int t[2]; };
C b{1, {2, 3}};
The relevant wording seems to be
https://eel.is/c++draft/over.match.class.deduct#1.5. Rather than only
"considering" brace elision for int[2] (and other non-dependent aggregate
type), we seem to require it.
[Bug target/101882] New: modulus with input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
Bug ID: 101882
Summary: modulus with input and output set to a hard register
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: willschm at gcc dot gnu.org
Target Milestone: ---
Noted on powerpc using recent GCC.
gcc version 12.0.0 20210812 (experimental) (GCC)
foofoo9.c:
register a __asm__("r20");
b() { a = a % 9 ; }
# does not occur with -O0, or with -mcpu=power8.
$ gcc -O -mcpu=power9 foofoo9.c
foofoo9.c: In function ‘b’:
foofoo9.c:2:19: error: unable to generate reloads for impossible constraints:
2 | b() { a = a % 9 ; }
| ^
(insn 7 9 12 2 (set (reg/v:SI 20 20 [ a ])
(mod:SI (reg/v:SI 20 20 [ a ])
(reg:SI 120))) "foofoo9.c":2:13 183 {*modsi3}
(expr_list:REG_DEAD (reg:SI 120)
(nil)))
during RTL pass: reload
foofoo9.c:2:19: internal compiler error: in process_alt_operands, at
lra-constraints.c:3108
0x101d9597 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/willschm/gcc/gcc-baseline/gcc/rtl-error.c:108
0x10912b4f process_alt_operands
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:3108
0x10912b4f curr_insn_transform
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:4102
0x10916dbb lra_constraints(bool)
/home/willschm/gcc/gcc-baseline/gcc/lra-constraints.c:5168
0x108fc46f lra(_IO_FILE*)
/home/willschm/gcc/gcc-baseline/gcc/lra.c:2336
0x1089be8b do_reload
/home/willschm/gcc/gcc-baseline/gcc/ira.c:5932
0x1089be8b execute
/home/willschm/gcc/gcc-baseline/gcc/ira.c:6118
Please submit a full bug report,
[Bug c++/101344] [11/12 Regression] braced-init-list not supported in an aggregate deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101344 Patrick Palka changed: What|Removed |Added Known to work||10.1.0, 10.2.0, 10.3.0 Known to fail||11.1.0, 11.2.0, 12.0 Summary|braced-init-list not|[11/12 Regression] |supported in an aggregate |braced-init-list not |deduction |supported in an aggregate ||deduction --- Comment #3 from Patrick Palka --- We started rejecting the comment #2 example after r11-1615
[Bug target/101882] modulus with input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-08-12 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. I'll take it.
[Bug c++/101883] New: class template argument deduction in non-type template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101883
Bug ID: 101883
Summary: class template argument deduction in non-type template
parameter allows explicit deduction guide
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced example:
template struct C { constexpr C(int) {} };
explicit C(int) -> C;
template struct X { };
X<1> x;
This should fail to compile, because the deduction guide is explicit and so
should not be a candidate, but gcc accepts this example.
gcc does correctly reject:
C y = 1;
Which is the same kind of thing.
[Bug ipa/101726] target_clone resolver does not generate PIC despite -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Liška --- I've just sent a patch to ML: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577287.html
[Bug fortran/101871] Array of strings of different length passed as an argument produces invalid result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101871 kargl at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-12 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to David Sagan from comment #0) > > call out_io_lines2 ([character(80):: & > 'Beam parameters not computed at: ' // trim(name), & > 'Singular sigma matrix is:', & > ' \6es15.7\', ' \6es15.7\', ' \6es15.7\', ' \6es15.7\', ' > \6es15.7\', ' \6es15.7\', & > 'Will not print any more singular sigma matrices']) For some reason, gfortran is ignoring the type-spec in the array constructor of the actual argument if one uses the concatenation operator in the first element of the constructor. The length is set to that of the first element. This is going to be entertaining for whomever takes on the challenge. Here's a modified test to consider program tao_program implicit none integer i character(80) abc(9) character(40) name name = 'H' abc = [character(80) :: 'a'//trim(name), 'ab', 'abc', 'd', 'def', 'g', & & 'ghi', 'z', 'zy'] call io([character(80) :: 'a'//trim(name), 'ab', 'abc', 'd', & & 'def', 'g', 'ghi', 'z', 'zyxwvut']) print * abc = [character(80) :: 'a', 'ab', 'abc', 'd'//trim(name), 'def', 'g', & & 'ghi', 'z', 'zy'] call io([character(80) :: 'a', 'ab', 'abc', 'd'//trim(name), & & 'def', 'g', 'ghi', 'z', 'zyxwvut']) contains subroutine io (lines) implicit none character(*) lines(:) integer i do i = 1, size(lines) write(*,'(I0,A)') i, ' ' // trim(abc(i)) // ' ' // trim(lines(i)) end do end subroutine io end program
[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589
Mathieu Desnoyers changed:
What|Removed |Added
CC||mathieu.desnoyers@efficios.
||com
--- Comment #13 from Mathieu Desnoyers
---
So I reproduced this hang with pgrep on my Ubuntu 18.04.1 LTS.
LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/{8,9,10,11}/libasan.so pgrep something
[ hang ]
but
LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/7/libasan.so pgrep something [ does
not hang ]
So I focus my investigation on gcc 8's libasan which is the first to introduce
this issue.
The version of glibc on this x86-64 machine is 2.27-3ubuntu1.4.
I added breakpoints on all rwlock read lock, write lock, and unlock operations
(__GI___pthread_rwlock_rdlock, __GI___pthread_rwlock_wrlock,
__GI___pthread_rwlock_unlock). Looking at what happens to the _nl_state_lock
which protects glibc's i18n handling data structures is quite enlightening.
This lock is _not_ a recursive lock. AFAIU what happens here is that:
1. intl/bindtextdom.c:set_binding_values() locks the _nl_state_lock write lock.
2. it calls malloc, but this symbol is overridden by libasan.
3. asan's malloc handler ReplaceSystemMalloc looks up "__libc_malloc_dispatch"
and if that fails it looks up "__libc_malloc_default_dispatch".
4. The dlsym lookup failure calls __dlerror, which performs a i18n lookup, thus
taking the _nl_state_lock read lock. This should not happen, as it is not a
nestable lock.
5. The _nl_state_lock is unlocked once after the i18n lookup is done.
6. The _nl_state lock is unlocked again in set_binding_values(), which corrupts
the lock state because it is not a nestable lock.
7. The next unlucky caller trying to take the lock hangs forever on futex.
Based on an IRC discussion with Carlos O'Donell, it appears to be a defect in
glibc that a malloc interposer fails during i18n translation. There was a
discussion back in 2014
(https://sourceware.org/legacy-ml/libc-alpha/2014-12/msg00954.html) regarding
reentrancy of dlopen and other libdl interfaces.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Martin Liška ---
Heh, another example of __attribute__((optimize("..."))) problem:
__attribute__ ((__optimize__ ("-fno-tree-loop-distribute-patterns")))
__memmove_ppc ( void *dest, const void *src, size_t len)
{
...
}
-mrop-protect is dropped when optimize attribute is parsed, for more
information see:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577113.html
[Bug c++/101884] New: Generic lambda with auto in template parameter list rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101884 Bug ID: 101884 Summary: Generic lambda with auto in template parameter list rejected Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: johelegp at gmail dot com CC: johelegp at gmail dot com Target Milestone: --- See https://godbolt.org/z/Go36onYGc. ```C++ templateint i; ``` ``` :1:18: error: 'auto' parameter not permitted in this context 1 | templateint i; | ^~~~ Compiler returned: 1 ```
[Bug c/65403] -Wno-error= is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 --- Comment #15 from Alex Henrie --- Nicholas Guriev also sent a patch for this issue: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573774.html
[Bug libstdc++/101867] avr libc build error for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867 --- Comment #14 from cqwrteur --- (In reply to Jonathan Wakely from comment #13) > Marking as enhancement, since this is not a supported target for libstdc++ > today, so is not expected to build. Whatever. i have successfully built that. It works very well tbh. Thank you! We need to resign none standard implementation of libstdc++ forks tbh. https://github.com/modm-io/avr-libstdcpp/tree/master/include
[Bug tree-optimization/101885] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
Bug ID: 101885
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It appears a regression in gcc-10. gcc-9 works fine.
$ gcc-trunk -v
gcc version 12.0.0 20210812 (experimental) [master revision
01f8a8b48e5:0eb7800d242:04b4f3152593f85b05974528d1607619dd77d702] (GCC)
$ gcc-trunk abc.c ; ./a.out
0
$ gcc-trunk -O3 abc.c ; ./a.out
3
$ cat abc.c
int a = 3, c;
short b = 5, d, f;
volatile short e;
int main() {
f = 29;
for (; f != 33; f++) {
int g = a;
if (b)
if (a) {
a = b = 0;
for (; b <= 8; b++)
;
}
e;
e;
c = 0;
for (; c != 14; ++c)
e;
}
b = d;
printf("", 8);
printf("%d\n", a);
}
[Bug tree-optimization/101885] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885 --- Comment #1 from Qirun Zhang --- My bisection points to g:529ea7d9596b26ba103578eeab448e9862a2d2c5
[Bug c++/101886] New: [11/12 Regression][concepts] ICE with auto as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886
Bug ID: 101886
Summary: [11/12 Regression][concepts] ICE with auto as template
parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet (compiled with "-fconcepts")
triggers an ICE since GCC 11.1.0:
template struct A { };
A a;
A b1 = a;
A b2 = a;
bug.cc:5:13: internal compiler error: same canonical type node for different
types 'auto' and 'auto'
5 | A b2 = a;
| ^
0xb4eb9d comptypes(tree_node*, tree_node*, int)
../../gcc-11.1.0/gcc/cp/typeck.c:1565
0xab322f template_args_equal(tree_node*, tree_node*, bool)
../../gcc-11.1.0/gcc/cp/pt.c:9231
0xb42e41 cp_tree_equal(tree_node*, tree_node*)
../../gcc-11.1.0/gcc/cp/tree.c:4079
0xab305a template_args_equal(tree_node*, tree_node*, bool)
../../gcc-11.1.0/gcc/cp/pt.c:9249
0xab2d88 template_args_equal(tree_node*, tree_node*, bool)
../../gcc-11.1.0/gcc/cp/pt.c:9194
0xab2d88 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc-11.1.0/gcc/cp/pt.c:9278
0xab2d88 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
../../gcc-11.1.0/gcc/cp/pt.c:9258
0xabc9f3 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc-11.1.0/gcc/cp/pt.c:1727
0xb02944 hash_table::find_with_hash(spec_entry* const&, unsigned int)
../../gcc-11.1.0/gcc/hash-table.h:923
0xaeef47 lookup_template_class_1
../../gcc-11.1.0/gcc/cp/pt.c:9889
0xaf0bfc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-11.1.0/gcc/cp/pt.c:10244
0xb1914b finish_template_type(tree_node*, tree_node*, int)
../../gcc-11.1.0/gcc/cp/semantics.c:3581
0xa8a8eb cp_parser_template_id
../../gcc-11.1.0/gcc/cp/parser.c:17486
0xa8aadb cp_parser_class_name
../../gcc-11.1.0/gcc/cp/parser.c:24722
0xa81fda cp_parser_qualifying_entity
../../gcc-11.1.0/gcc/cp/parser.c:7002
0xa81fda cp_parser_nested_name_specifier_opt
../../gcc-11.1.0/gcc/cp/parser.c:6684
0xaa2e18 cp_parser_template_introduction
../../gcc-11.1.0/gcc/cp/parser.c:30254
0xaa50c3 cp_parser_declaration
../../gcc-11.1.0/gcc/cp/parser.c:14149
0xaa5e4c cp_parser_toplevel_declaration
../../gcc-11.1.0/gcc/cp/parser.c:14183
0xaa5e4c cp_parser_translation_unit
../../gcc-11.1.0/gcc/cp/parser.c:4942
Please submit a full bug report, [etc.]
[Bug libstdc++/67112] [MinGW64] build failure due to name conflict with system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67112 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Jonathan Wakely --- Apparently nobody in the mingw-w64 community has seen this or can reproduce it, so I'm closing as WORKSFORME. If you are still seeing this with current GCC releases, please reopen and provide more details.
[Bug libstdc++/101867] avr libc build error for libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101867 --- Comment #15 from Jonathan Wakely --- (In reply to cqwrteur from comment #14) > Whatever. i have successfully built that. It works very well tbh. Excellent!
[Bug c++/101887] New: [9/10/11/12 Regression] ICE with invalid declaration of 'operator delete'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101887
Bug ID: 101887
Summary: [9/10/11/12 Regression] ICE with invalid declaration
of 'operator delete'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 4.9.0:
struct A
{
A();
auto operator delete(void*, __SIZE_TYPE__);
};
void foo()
{
new A;
}
bug.cc:4:3: error: non-static data member declared with placeholder 'auto'
4 | auto operator delete(void*, __SIZE_TYPE__);
| ^~~~
bug.cc: In function 'void foo()':
bug.cc:9:7: internal compiler error: tree check: expected function_type or
method_type, have error_mark in usual_deallocation_fn_p, at cp/call.c:6935
9 | new A;
| ^
0x85a540 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:8686
0x6544a6 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/gcc/tree.h:3392
0x6544a6 usual_deallocation_fn_p
../../gcc/gcc/cp/call.c:6935
0x9229e0 build_op_delete_call(tree_code, tree_node*, tree_node*, bool,
tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6926
0xa0c128 build_new_1
../../gcc/gcc/cp/init.c:3539
0xa0cf98 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
../../gcc/gcc/cp/init.c:3826
0xabf7d2 cp_parser_new_expression
../../gcc/gcc/cp/parser.c:9157
0xabfdff cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8745
0xa91a2a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9893
0xa9233c cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:10197
0xa938b2 cp_parser_expression
../../gcc/gcc/cp/parser.c:10367
0xa96f58 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:12531
0xaa2dff cp_parser_statement
../../gcc/gcc/cp/parser.c:12327
0xaa3e9d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:12679
0xaa3f78 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:12628
0xac35c0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:24762
0xac35c0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:24813
0xac428a cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:30898
0xac56c4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:30814
0xac56c4 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:22318
Please submit a full bug report, [etc.]
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #6 from Martin Sebor --- I've only looked at the first warning so far. It's issued for the access in bb 8: [local count: 4057510040]: pos.80_31 = pos; if (pos.80_31 <= 1023) goto ; [96.34%] else goto ; [3.66%] [local count: 256307115]: # pos.80_21 = PHI _1 = linebuf[pos.80_21]; <<< -Warray-bounds ... The index is in the range [1024, INT_MAX] so the warning is correct given the IL. There isn't much I see that could be improved about the diagnostic except mentioning the range of the subscript rather than just its lower bound. This instance of the warning or its phrasing also haven't changed in years. It's not the result of a recent enhancement or a questionable heuristic but simply reflects a change in the IL, and it's always been phrased as "is out of bounds". No "may be out of bounds" form exists, never has, and adding one wouldn't help in this instance. That said, since pos is a global variable, the test in safe_inc_pos() that would otherwise constrain its value only has that effect in the absence of intervening statements that might overwrite it. You might get a better result with a pair of "setter" and "getter" functions where the latter asserted the range via __builtin_unreachable() before returning the variable. Otherwise, the test is what likely is used by the backward threader to introduce the unreachable branch which isn't eliminated because GCC can't prove the variable isn't incremented beyond its upper limit. (Aldy is in a much better position to explain this.)
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #7 from Bill Schmidt --- Sorry, but that IL looks very strange to me. BB 5 should be going directly to BB 8, and the value of interest along that path is pos.80_31. But BB 8 says that it only gets pos.80 from BB 36, and the value along that path is pos.80_81. For the index to be in the range [1024, INT_MAX] is absurd on its face, coming from BB 5 where it is clearly constrained to be within [INT_MIN, 1023]. Can you please explain? I don't understand this at all.
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #8 from Martin Sebor --- Created attachment 51298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51298&action=edit Change to test case that avoids -Warray-bounds. The attached change to test case avoids all -Warray-bounds instances.
[Bug c++/101883] class template argument deduction in non-type template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101883 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-08-12 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/101888] New: constexpr default comparison member function disregards the base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101888
Bug ID: 101888
Summary: constexpr default comparison member function
disregards the base class
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: myosotis at mail dot ustc.edu.cn
Target Milestone: ---
This issue only occurs when the default operator== in the derived class is a
constexpr member function (non-constexpr or friend operator== won't trigger
this issue). Whether the operator== function in the base class is constexpr
member or not does not matter. I tested on gcc 11.1 and 11.2, and this issue
persists whatever the optimization level is. Repro:
struct S
{
int s = 0;
S(int s) : s(s) {}
bool operator==(const S&) const = default;
};
struct T : S
{
T(int s) : S(s) {}
constexpr bool operator==(const T&) const = default;
};
int main() { return T(0) == T(1); } // Expected 0, but returns 1
[Bug target/101849] MMA built-in dies with a verify_gimple failed error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101849 --- Comment #5 from Peter Bergner --- (In reply to Peter Bergner from comment #4) > Is there a benefit of one over the other? ...other than the build2 code > being simpler since we'd just pass in the type we want. So the following seems to work which seems a little simpler than what I submitted. I'll test this along with a little beefier test case with multiple offsets, with some not constant. tree ptr_t = build_pointer_type (vector_pair_type_node); tree mem = build2 (MEM_REF, vector_pair_type_node, build2 (POINTER_PLUS_EXPR, ptr_t, ptr, offset), build_int_cst (ptr_t, 0));
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #9 from Bill Schmidt --- But it doesn't explain the bogus IL in the previous message.
[Bug c++/101889] New: [11/12 Regression] ICE with template argument deduction of broken template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101889
Bug ID: 101889
Summary: [11/12 Regression] ICE with template argument
deduction of broken template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet triggers an ICE since GCC 11:
==
template struct A {};
template struct B
{
enum { E = 0 };
B(A) {}
};
B b = A<0>();
==
bug.cc:3:10: error: 'T' has not been declared
3 | template struct B
| ^
bug.cc:9:12: internal compiler error: tree check: expected enumeral_type, have
error_mark in tsubst_copy, at cp/pt.c:16588
9 | B b = A<0>();
|^
0x85a540 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:8686
0x6e74ea tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3373
0x6e74ea tsubst_copy
../../gcc/gcc/cp/pt.c:16588
0xaf1eb4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:20870
0xafd357 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19092
0xb12264 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13355
0xb1b763 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13559
0xb1be34 tsubst_arg_types
../../gcc/gcc/cp/pt.c:14958
0xb1ed5a tsubst_arg_types
../../gcc/gcc/cp/pt.c:14935
0xb1ed5a build_deduction_guide
../../gcc/gcc/cp/pt.c:28776
0xaec0b6 ctor_deduction_guides_for
../../gcc/gcc/cp/pt.c:29184
0xaec0b6 deduction_guides_for
../../gcc/gcc/cp/pt.c:29257
0xaec576 do_class_deduction
../../gcc/gcc/cp/pt.c:29378
0xaec576 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:29535
0x9d9608 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7856
0xac5174 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:22556
0xaa0773 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:15088
0xacfdb5 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14787
0xad078e cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14808
0xad078e cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4978
Please submit a full bug report, [etc.]
[Bug c++/101888] constexpr default comparison member function disregards the base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101888 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report, this looks like a dup of PR98712 *** This bug has been marked as a duplicate of bug 98712 ***
[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98712 Patrick Palka changed: What|Removed |Added CC||myosotis at mail dot ustc.edu.cn --- Comment #4 from Patrick Palka --- *** Bug 101888 has been marked as a duplicate of this bug. ***
[Bug c/29970] mixing ({...}) with VLA leads to massive breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:d2ba65ab6010f0d507bf5512a0223692e6653b23 commit r12-2882-gd2ba65ab6010f0d507bf5512a0223692e6653b23 Author: Martin Uecker Date: Thu Aug 12 20:32:16 2021 +0200 Evaluate type arguments of sizeof that are structs of variable size [PR101838] Evaluate type arguments of sizeof for all types of variable size and not just for VLAs. This fixes PR101838 and some issues related to PR29970 where statement expressions need to be evaluated so that the size is well defined. 2021-08-12 Martin Uecker gcc/c/ PR c/101838 PR c/29970 * c-typeck.c (c_expr_sizeof_type): Evaluate size expressions for structs of variable size. gcc/testsuite/ PR c/101838 * gcc.dg/vla-stexp-2.c: New test.
[Bug c/101838] sizeof of struct with array of unspecified bound folded to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101838 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:d2ba65ab6010f0d507bf5512a0223692e6653b23 commit r12-2882-gd2ba65ab6010f0d507bf5512a0223692e6653b23 Author: Martin Uecker Date: Thu Aug 12 20:32:16 2021 +0200 Evaluate type arguments of sizeof that are structs of variable size [PR101838] Evaluate type arguments of sizeof for all types of variable size and not just for VLAs. This fixes PR101838 and some issues related to PR29970 where statement expressions need to be evaluated so that the size is well defined. 2021-08-12 Martin Uecker gcc/c/ PR c/101838 PR c/29970 * c-typeck.c (c_expr_sizeof_type): Evaluate size expressions for structs of variable size. gcc/testsuite/ PR c/101838 * gcc.dg/vla-stexp-2.c: New test.
