[Bug libstdc++/106612] New: ranges::iter_move does not consider iterator's value categories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106612
Bug ID: 106612
Summary: ranges::iter_move does not consider iterator's value
categories
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following case should be a constraint not satisfied rather than a hard
error since we cannot dereference the I of an rvalue.
#include
struct I {
using difference_type = std::ptrdiff_t;
using value_type = int;
value_type& operator*() const &;
void operator*() && = delete;
I& operator++();
I operator++(int);
bool operator==(const I&) const;
};
int main() {
return std::ranges::iter_move(I{});
}
https://godbolt.org/z/xP4GWT3qv
[Bug libstdc++/106608] [12 Regression] std::optional requires unavailable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608 --- Comment #3 from Egor Pugin --- Small repro https://godbolt.org/z/WKc7arxMs Probably clang issue.
[Bug c++/106613] New: GCC rejects valid program involving std::invariant saying incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106613
Bug ID: 106613
Summary: GCC rejects valid program involving std::invariant
saying incomplete type
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following valid(afaik) program is rejected by gcc.
https://godbolt.org/z/e73Yf4s47
```
#include
struct LiteralExpr
{
int value;
};
template
struct BaseSpace
{
struct AddExpr;
struct AddExprBox
{
const AddExpr &_impl;
public:
AddExprBox(const AddExpr &obj) {}
};
using Expr = std::variant;
struct AddExpr
{
std::variant lhs; // error:
'BaseSpace::AddExpr::lhs' has incomplete type
};
};
auto main() -> int
{
auto expr = BaseSpace::Expr(LiteralExpr{2});
}
```
The error says:
```
error: 'BaseSpace::AddExpr::lhs' has incomplete type
22 | std::variant lhs;
| ^~~
In file included from :1:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/variant:1336:11: note:
declaration of 'class std::variant::AddExprBox, LiteralExpr>'
1336 | class variant
| ^~~
```
[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 --- Comment #6 from Tamar Christina --- Hi Roger, before you spend too much time on this, I just wanted to clarify. If you're saying this is a target issue where we lack some symmetry on patterns I would be happy to fix it up and don't really expect you to! My confusion here is that I am wondering whether combine will match the and form with zero extend as well.
[Bug c++/106614] New: GCC skips using copy constructor when creating object using direct initialization in A a({A{}});
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106614
Bug ID: 106614
Summary: GCC skips using copy constructor when creating object
using direct initialization in A a({A{}});
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program prints `0` instead of `1` with gcc.
https://gcc.godbolt.org/z/WEz336E3r
```
#include
struct A {
int v = 0;
A() {}
A(const A &) : v(1) {}
};
int main() {
A a({A{}});
std::cout << a.v; //this prints 0 in gcc instead of 1
}
```
The above program should print `0` as per dcl.init#17.6. The same program is
discussed here: https://stackoverflow.com/q/73345030/12002570
[Bug rtl-optimization/106615] New: redundant load and store introduced in if-true-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106615
Bug ID: 106615
Summary: redundant load and store introduced in if-true-branch
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
Given the code:
int g_36 = 0x0B137D37L;
int *g_35 = &g_36;
int g_44[2] = {0x964071C1L,0x964071C1L};
unsigned char func_1(void);
int * func_16(int * p_17, unsigned long int p_18);
int * func_19(int * p_20);
unsigned char func_1() { func_16(func_19(g_35), g_44[1]); }
int* func_16(int *a, unsigned long int b) {
unsigned int c=1;
*a = g_44;
if ((g_44[0] = c) <= b)
;
else
*a = 0;
}
int* func_19(int32_t *d) {
g_44[1] |= g_36 ;
return d;
}
when it's compiled on gcc-12.1 with option -O1, the generated asm code of
func_16 will be:
00401186 :
401186: b8 60 40 40 00 mov$0x404060,%eax
40118b: 89 07 mov%eax,(%rdi)
40118d: c7 05 c9 2e 00 00 01movl $0x1,0x2ec9(%rip)#
404060
401194: 00 00 00
401197: b8 00 00 00 00 mov$0x0,%eax
40119c: 48 85 f6test %rsi,%rsi
40119f: 74 02 je 4011a3
4011a1: 8b 07 mov(%rdi),%eax
# rdi keep the address of g_36
4011a3: 89 07 mov%eax,(%rdi)
4011a5: c3 retq
We can see g_36 will be loaded to %eax and stored back as is when the
if-condition is true. This operation should be redundant?
[Bug tree-optimization/106615] redundant load and store introduced in if-true-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106615
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed||2022-08-14
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
int g_44;
void func_16(int *a, unsigned long int b) {
*a = 5;
if ((g_44 = 1) <= b)
;
else
*a = 0;
}
CUT
So CSElim on the gimple level goes from:
*a_3(D) = 5;
g_44 = 1;
if (b_6(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
*a_3(D) = 0;
[local count: 1073741824]:
return;
to:
*a_3(D) = 5;
g_44 = 1;
if (b_6(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
cstore_8 = MEM [(void *)a_3(D)];
[local count: 1073741824]:
# cstore_9 = PHI
MEM [(void *)a_3(D)] = cstore_9;
Thinking it might be able to remove the load inside the if branch (for an
example at -O2 with 1 instead of 5, GCC can remove the load).
And then nothing afterwards will undo that transformation.
[Bug c++/106613] GCC rejects valid program involving std::invariant saying incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106613 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- clang rejects it with the same error message. Both GCC and clang are correct because the inner types are not complete until after the outer type is complete.
[Bug libstdc++/106608] [12 Regression] std::optional requires unavailable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608 --- Comment #4 from Andrew Pinski --- Created attachment 53453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53453&action=edit small testcase
[Bug target/106616] New: ia64: ICE during RTL pass: mach: error: qsort comparator non-negative on sorted output: 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106616
Bug ID: 106616
Summary: ia64: ICE during RTL pass: mach: error: qsort
comparator non-negative on sorted output: 3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Target: ia64-unknown-linux-gnu
Observed this ICE on this week's ia64-gcc when was building linux4.19 for ia64
target. Here is extracted reproducer:
// $ cat feat.c.c
//
/nix/store/pmvcr7vxqwi1jsykn0p9xw9446linswp-ia64-unknown-linux-gnu-stage-final-gcc-wrapper-13.0.0/bin/ia64-unknown-linux-gnu-gcc
-O2 -c feat.c.c -o bug.o
int inet_csk_schedule_ack(int);
int dccp_feat_nn_get(int, int);
struct sock_common;
struct list_head {
struct list_head *next;
};
enum { DCCPF_SEQUENCE_WINDOW, DCCPF_ACK_RATIO };
struct dccp_sock {
int dccps_inet_connection;
struct list_head dccps_featneg;
struct list_head node;
} * dccp_feat_signal_nn_change_feat_entry;
int dccp_feat_list_lookup_feat_num, dccp_feat_list_lookup_is_local,
dccp_feat_is_valid_nn_val_feat_num, dccp_feat_is_valid_nn_val_val,
dccp_feat_signal_nn_change_feat___trans_tmp_1;
int dccp_feat_is_valid_nn_val(void) {
switch (dccp_feat_is_valid_nn_val_feat_num) {
case DCCPF_ACK_RATIO:
return dccp_feat_is_valid_nn_val_val <= 5;
case DCCPF_SEQUENCE_WINDOW:
return dccp_feat_is_valid_nn_val_val <= 5ull;
}
return 0;
}
int dccp_feat_signal_nn_change_feat(struct sock_common *sk) {
struct list_head *fn = &((struct dccp_sock *)sk)->dccps_featneg;
if (!dccp_feat_is_valid_nn_val())
return 2;
if (dccp_feat_nn_get((int)(long)sk,
(int)(long)dccp_feat_signal_nn_change_feat))
return 0;
char entry_0;
dccp_feat_signal_nn_change_feat_entry = ({ (struct dccp_sock*)fn->next; });
for (; &dccp_feat_signal_nn_change_feat_entry->node == fn;
dccp_feat_signal_nn_change_feat_entry = 0)
if (entry_0 == dccp_feat_list_lookup_feat_num &&
dccp_feat_list_lookup_is_local)
;
else if (entry_0 > dccp_feat_list_lookup_feat_num)
dccp_feat_signal_nn_change_feat___trans_tmp_1 = 0;
inet_csk_schedule_ack((int)(long)sk);
return (int)(long)fn;
}
Crashing:
$ ia64-unknown-linux-gnu-gcc -O2 -c feat.c.c -o bug.o -Wall
feat.c.c: In function 'dccp_feat_signal_nn_change_feat':
feat.c.c:41:17: warning: 'entry_0' may be used uninitialized
[-Wmaybe-uninitialized]
41 | if (entry_0 == dccp_feat_list_lookup_feat_num &&
| ^
feat.c.c:37:8: note: 'entry_0' was declared here
37 | char entry_0;
|^~~
feat.c.c:48:1: error: qsort comparator non-negative on sorted output: 3
48 | }
| ^
during RTL pass: mach
feat.c.c:48:1: internal compiler error: qsort checking failed
0x187ff57 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1880da7 internal_error(char const*, ...)
???:0
0x7be301 qsort_chk_error(void const*, void const*, void const*, int (*)(void
const*, void const*, void*), void*)
???:0
0x7be429 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*, void*), void*) [clone .cold]
???:0
0x18b46e8 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
???:0
0x16c6a27 ready_sort_real(ready_list*) [clone .constprop.0]
???:0
0x16ceb64 schedule_block(basic_block_def**, void*)
???:0
0x17a8b58 schedule_ebb(rtx_insn*, rtx_insn*, bool)
???:0
0x17a9149 schedule_ebbs()
???:0
0x1191baf ia64_reorg()
???:0
0xda5e49 (anonymous namespace)::pass_machine_reorg::execute(function*)
???:0
$ ia64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/<>/ia64-unknown-linux-gnu-stage-final-gcc-13.0.0/bin/ia64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/<>/ia64-unknown-linux-gnu-stage-final-gcc-13.0.0/libexec/gcc/ia64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220807 (experimental) (GCC)
[Bug target/106616] ia64: ICE during RTL pass: mach: error: qsort comparator non-negative on sorted output: 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106616 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 87281 *** This bug has been marked as a duplicate of bug 87281 ***
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 Andrew Pinski changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #11 from Andrew Pinski --- *** Bug 106616 has been marked as a duplicate of this bug. ***
[Bug c++/106604] Fully-specified deduction guide in anonymous namespace warns as-if a function? Unsuppressably?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106604 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-14 Status|UNCONFIRMED |NEW Known to fail||7.1.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 --- Comment #12 from Sergei Trofimovich --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106616#c0 provides hopefully reproducible test.
[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 Tim Lange changed: What|Removed |Added CC||tlange at gcc dot gnu.org --- Comment #4 from Tim Lange --- Hi Immad, while testing my patch on coreutils [1], I encountered another ICE at the same line. I'm using the newest commit on the master at the time of writing this [2] (I've double-checked that I indeed have your fix included). during IPA pass: analyzer ../lib/freopen.c: In function 'rpl_freopen': ../lib/freopen.c:82:19: internal compiler error: in valid_to_unchecked_state, at analyzer/sm-fd.cc:751 82 | if (dup2 (nullfd, fd) < 0) | ^ 0x7bc106 valid_to_unchecked_state ../../gcc/analyzer/sm-fd.cc:751 0x7bc106 valid_to_unchecked_state ../../gcc/analyzer/sm-fd.cc:742 0x7bc106 check_for_dup ../../gcc/analyzer/sm-fd.cc:990 0x12a5e8c on_stmt ../../gcc/analyzer/sm-fd.cc:805 0x124f4e4 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::uncertainty_t*, ana::path_context*) ../../gcc/analyzer/engine.cc:1449 0x1251f1b ana::exploded_graph::process_node(ana::exploded_node*) ../../gcc/analyzer/engine.cc:3868 0x1252dba ana::exploded_graph::process_worklist() ../../gcc/analyzer/engine.cc:3271 0x125514d ana::impl_run_checkers(ana::logger*) ../../gcc/analyzer/engine.cc:5912 0x125614e ana::run_checkers() ../../gcc/analyzer/engine.cc:5986 0x1245ee8 execute ../../gcc/analyzer/analyzer-pass.cc:87 [1] compiling coreutils commit: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=9f71f478ec6929d323c17f0482db8791de87b4fd [2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fe4dc4f553d8639b0ce3465e5e6dcf61c1ae9752
[Bug tree-optimization/106617] New: [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617
Bug ID: 106617
Summary: [13 Regression] gcc is very slow at ternary
expressions,
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: ---
Created attachment 53454
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53454&action=edit
fc_exch.c.c.orig.gz
Initially I observed slowness on ia64 trying to compile linux-4.19 using this
week's gcc snapshot. x86_64 also seems to be affected.
Original (ia64-specific) example is attached as fc_exch.c.c.orig.gz. It shows
the origin of this construct.
I reduced the example with 4s timeout and got the following reproducer:
// $ cat fc_exch.c.c
int nr_cpu_ids;
void fc_setup_exch_mgr() {
(((1UL << (((0, 0)
? ((1)
? (((nr_cpu_ids)) ? 0
: ((nr_cpu_ids)) & (21) ? 21
: ((nr_cpu_ids)) ? 20
: ((nr_cpu_ids)) & (19) ? 19
: ((nr_cpu_ids)) ? 18
: ((nr_cpu_ids)) & (17) ? 17
: ((nr_cpu_ids)) ? 16
: ((nr_cpu_ids)) & (15) ? 15
: ((nr_cpu_ids)) ? 14
: ((nr_cpu_ids)) & (13) ? 13
: ((nr_cpu_ids)) ? 12
: ((nr_cpu_ids)) & (11) ? 11
: ((nr_cpu_ids)) ? 10
: ((nr_cpu_ids)) & (9) ? 9
: ((nr_cpu_ids)) ? 8
: ((nr_cpu_ids)) & (7) ? 7
: ((nr_cpu_ids)) ? 6
: ((nr_cpu_ids)) & (5) ? 5
: ((nr_cpu_ids)) ? 4
: ((nr_cpu_ids)) & (3)
? 3
: ((nr_cpu_ids)-1) & 1)
: 1)
: 0) +
1) &
(1ULL << 2)
? 2
: 1))
);
}
$ time gcc-13.0.0 -Wno-address-of-packed-member -c fc_exch.c.c -o bug.o -O1
real0m4,821s
user0m4,726s
sys 0m0,077s
Almost 5s!
$ time gcc-12.1.0 -Wno-address-of-packed-member -c fc_exch.c.c -o bug.o -O1
real0m0,019s
user0m0,013s
sys 0m0,006s
$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-13.0.0/bin/gcc
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 20220807 (experimental) (GCC)
On this example perf shows the following output:
8.63% cc1 cc1 [.] operand_compare::operand_equal_p
4.39% cc1 cc1 [.]
operand_compare::verify_hash_value
4.29% cc1 cc1 [.] wide_int_to_tree_1
3.67% cc1 cc1 [.] fold_binary_loc
3.17% cc1 cc1 [.] generic_simplify_NE_EXPR
2.67% cc1 cc1 [.] tree_strip_nop_conversions
2.64% cc1 cc1 [.] generic_simplify_EQ_EXPR
2.47% cc1 cc1 [.] tree_operand_check
2.39% cc1 cc1 [.] get_inner_reference
2.37% cc1 cc1 [.] integer_zerop
2.25% cc1 cc1 [.] wide_int_binop
2.11% cc1 cc1 [.] tree_nop_convert
1.84% cc1 cc1 [.] int_const_binop
1.81% cc1 cc1 [.] int_cst_hasher::hash
1.78% cc1 cc1 [.] ggc_internal_alloc
1.70% cc1 cc1 [.] element_precision
1.44% cc1 cc1 [.] wi::fits_to_tree_p > > >
1.36% cc1 cc1 [.] contains_struct_check
1.08% cc1 cc1 [.] build2
1.05% cc1 cc1 [.] hash_table::find_slot_with_hash
1.04% cc1 cc1 [.] generic_simplify
1.03% cc1 cc1 [.] cache_wide_int_in_type_cache
0.97% cc1 cc1 [.] get_int_cst_ext_nunits
0.91% cc1 cc1 [.] bitmask_inv_cst_vector_p
0.87% cc1 cc1 [.] tree_strip_sign_nop_conversions
0.86% cc1 libc.so.6 [.] __
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog --- Comment #1 from Andrew Pinski --- I doubt this is a regression. I suspect if you compile the trunk with --enable-checking=release you would see the same compile time as 12.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #2 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #1) > I doubt this is a regression. I suspect if you compile the trunk with > --enable-checking=release you would see the same compile time as 12. I think both my gcc-12.1.0 and gcc-13.0.0 are compiled with the same options (both are without --enable-checking= option). My unsubstantiated guess would be on recently added rules to fold & (or similar) which does not scale too well on long strings of ternary operators.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #3 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #2) > (In reply to Andrew Pinski from comment #1) > > I doubt this is a regression. I suspect if you compile the trunk with > > --enable-checking=release you would see the same compile time as 12. > > I think both my gcc-12.1.0 and gcc-13.0.0 are compiled with the same options > (both are without --enable-checking= option). My unsubstantiated guess would > be on recently added rules to fold & (or similar) which does not scale too > well on long strings of ternary operators. Oh, only now I realized snapshots have a different default compared to releases proper. I'll add --enable-checking=release and re-test.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #4 from Andrew Pinski --- Gcc releases are always defaults to --enable-checking=release while the git trunk is =yes.
[Bug c++/106613] GCC rejects valid program involving std::invariant saying incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106613
--- Comment #2 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> clang rejects it with the same error message.
>
> Both GCC and clang are correct because the inner types are not complete
> until after the outer type is complete.
I don't think what you said about " inner types are not complete until after
the outer type is complete" is true.
In particular, the following program is well-formed. Note in the below program
the nested type named `A` is complete when its `};` is encountered and not when
the containing class `C`'s `};` is encountered as opposed to your claim.
```
struct C
{
struct A
{
};
static constexpr A a{}; //this is fine because A is complete here as
opposed to Andrew's claim
};
```
[Bug c++/106613] GCC rejects valid program involving std::invariant saying incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106613 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 96645. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/96645] [10/11/12/13 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #29 from Andrew Pinski --- *** Bug 106613 has been marked as a duplicate of this bug. ***
[Bug c++/106613] GCC rejects valid program involving std::invariant saying incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106613 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102199 --- Comment #4 from Andrew Pinski --- Also see PR 102199. Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88165#c10 (which references when the inner class type is complete). This is one of the dark corners of C++ which have issues with many things.
[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #45 from Kewen Lin ---
One reduced C test case:
#define N 64
typedef unsigned short int uh;
typedef unsigned short int uw;
uh a[N];
uh b[N];
uh c[N];
uh e[N];
__attribute__ ((noipa)) void
foo ()
{
for (int i = 0; i < N; i++)
c[i] = ((uw) b[i] * (uw) a[i]) >> 16;
}
__attribute__ ((optimize ("-O0"))) void
init ()
{
for (int i = 0; i < N; i++)
{
a[i] = (uh) (0x7ABC - 0x5 * i);
b[i] = (uh) (0xEAB + 0xF * i);
e[i] = ((uw) b[i] * (uw) a[i]) >> 16;
}
}
__attribute__ ((optimize ("-O0"))) void
check ()
{
for (int i = 0; i < N; i++)
{
if (c[i] != e[i])
__builtin_abort ();
}
}
int
main ()
{
init ();
foo ();
check ();
return 0;
}
