[Bug libstdc++/102573] optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573
--- Comment #2 from wjf <13508417 at qq dot com> ---
(In reply to Andrew Pinski from comment #1)
> GCC warns:
> : In function 'int main()':
> :9:19: warning: assignment from temporary 'initializer_list' does
> not extend the lifetime of the underlying array [-Winit-list-lifetime]
> 9 | il = {111, 222};
> | ^
>
> Plus at runtime with -fsanitize=address:
>
> =
> ==1==ERROR: AddressSanitizer: stack-use-after-scope on address
> 0x7ffcff6b4e10 at pc 0x0040147d bp 0x7ffcff6b4dc0 sp 0x7ffcff6b4db8
> READ of size 4 at 0x7ffcff6b4e10 thread T0
> #0 0x40147c in main /app/example.cpp:13
> #1 0x7f5915fc70b2 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
> #2 0x40118d in _start (/app/output.s+0x40118d)
>
> Address 0x7ffcff6b4e10 is located in stack of thread T0 at offset 32 in frame
> #0 0x401255 in main /app/example.cpp:7
>
> This frame has 2 object(s):
> [32, 40) '' <== Memory access at offset 32 is inside this
> variable
> [64, 80) 'il' (line 8)
> HINT: this may be a false positive if your program uses some custom stack
> unwind mechanism, swapcontext or vfork
> (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.cpp:13 in main
> Shadow bytes around the buggy address:
> 0x10001fece970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> =>0x10001fece9c0: f1 f1[f8]f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00
> 0x10001fece9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fece9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fecea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001fecea10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user:f7
> Container overflow: fc
> Array cookie:ac
> Intra object redzone:bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone:cb
> ==1==ABORTING
> initializer_list size: 2
> initializer_list underlying elements:
>
>
> clang also errors out the same way.
Hi Andrew,
I know that adding "-fsanitize=address" could detect the stack-use-after-scope
in runtime. But why not just delete the copy member in std::initializer_list
implementation? I don't see much sense to permit the copy operation.
[Bug libstdc++/102573] optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
GCC warns:
: In function 'int main()':
:9:19: warning: assignment from temporary 'initializer_list' does not
extend the lifetime of the underlying array [-Winit-list-lifetime]
9 | il = {111, 222};
| ^
Plus at runtime with -fsanitize=address:
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffcff6b4e10
at pc 0x0040147d bp 0x7ffcff6b4dc0 sp 0x7ffcff6b4db8
READ of size 4 at 0x7ffcff6b4e10 thread T0
#0 0x40147c in main /app/example.cpp:13
#1 0x7f5915fc70b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x40118d in _start (/app/output.s+0x40118d)
Address 0x7ffcff6b4e10 is located in stack of thread T0 at offset 32 in frame
#0 0x401255 in main /app/example.cpp:7
This frame has 2 object(s):
[32, 40) '' <== Memory access at offset 32 is inside this variable
[64, 80) 'il' (line 8)
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.cpp:13 in main
Shadow bytes around the buggy address:
0x10001fece970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
=>0x10001fece9c0: f1 f1[f8]f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00
0x10001fece9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fece9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fecea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001fecea10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==1==ABORTING
initializer_list size: 2
initializer_list underlying elements:
clang also errors out the same way.
[Bug libstdc++/102573] New: optimized code removes the underlying elements of the std::initializer_list being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102573
Bug ID: 102573
Summary: optimized code removes the underlying elements of the
std::initializer_list being copied
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: 13508417 at qq dot com
Target Milestone: ---
Using clang++ compiler with libstdc++, the output of below program differs
whether use -O option.
code:
#include
#include
using namespace std;
int main()
{
initializer_list il;
il = {111, 222};
cout << "initializer_list size: " << il.size() << endl;
cout << "initializer_list underlying elements: " << endl;
for (auto i : il)
cout << i << endl;
return 0;
}
command:
➜ clang++ test_2.cpp -std=c++11 -O1 -v
clang version 10.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
...
output without -O:
initializer_list size: 2
initializer_list underlying elements:
111
222
output with -O1:
initializer_list size: 2
initializer_list underlying elements:
1402476368
32767
Question:
>From https://timsong-cpp.github.io/cppwp/n4659/dcl.init.list, I know that the
reason is because the lifetime of the underlying array should be same as the
temporary initializer_list constructed directly from the "{111, 222}", and the
variable "il" only copy the address and length of the underlying array using
the default copy member, but cannot affect the lifetime of the underlying
array.
But my question is, since the copied initializer_list can't affect the lifetime
of the underlying array bound to the original initializer_list, can we just
prohibit the copy member in the library implementation of
std::initializer_list? It seems to me that the copy member makes not much
sense, but probably lures the user to make mistakes.
[Bug tree-optimization/102572] New: ICE for skx in vect_build_gather_load_calls, at tree-vect-stmts.c:2835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102572
Bug ID: 102572
Summary: ICE for skx in vect_build_gather_load_calls, at
tree-vect-stmts.c:2835
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Reproducer:
int a, b, c, f;
void g(bool h, int d[][5]) {
for (short i = f; i; i += 1) {
a = h && d[0][i];
for (int j = 0; j < 4; j += c)
b = 0;
}
}
Error:
>$ g++ -O3 -march=skylake-avx512 -c func.cpp
during GIMPLE pass: vect
func.cpp: In function 'void g(bool, int (*)[5])':
func.cpp:2:6: internal compiler error: in vect_build_gather_load_calls, at
tree-vect-stmts.c:2835
2 | void g(bool h, int d[][5]) {
| ^
0x906a36 vect_build_gather_load_calls
/testing/gcc/gcc_src/gcc/tree-vect-stmts.c:2835
0x906a36 vectorizable_load
/testing/gcc/gcc_src/gcc/tree-vect-stmts.c:8785
0x1500240 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/testing/gcc/gcc_src/gcc/tree-vect-stmts.c:11060
0x1503e6a vect_transform_loop_stmt
/testing/gcc/gcc_src/gcc/tree-vect-loop.c:9362
0x151fd67 vect_transform_loop(_loop_vec_info*, gimple*)
/testing/gcc/gcc_src/gcc/tree-vect-loop.c:9798
0x1553a8f try_vectorize_loop_1
/testing/gcc/gcc_src/gcc/tree-vectorizer.c:1109
0x1554591 vectorize_loops()
/testing/gcc/gcc_src/gcc/tree-vectorizer.c:1248
GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/testing/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /testing/gcc/gcc_src/configure --enable-multilib
--prefix=/testing/gcc/bin --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211002 (d7705b0ada9e9852b580ca25a45570c82152f287) (GCC)
[Bug middle-end/43476] -ffixed-xxx etc processed too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43476
--- Comment #2 from Andrew Pinski ---
Code has changed slightly but it still seems to apply today:
/* After switches have been processed, which perhaps alter
`fixed_regs' and `call_used_regs', convert them to HARD_REG_SETs. */
static void
init_reg_sets_1 (void)
{
unsigned int i, j;
unsigned int /* machine_mode */ m;
restore_register_info ();
#ifdef REG_ALLOC_ORDER
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
inv_reg_alloc_order[reg_alloc_order[i]] = i;
#endif
/* Let the target tweak things if necessary. */
targetm.conditional_register_usage ();
[Bug middle-end/44690] -fzero-initialized-in-bss does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44690 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from Andrew Pinski --- Fixed by r8-2857-g2ec399d8a6c9c26 (there was a few followups patches which fix problems with this patch too).
[Bug c++/101764] ICE for constexpr if within fold expression within lambda expression within a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101764 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 101595 has been marked as a duplicate of this bug. ***
[Bug c++/101595] ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- (In reply to Andrew Pinski from comment #2) > This seems to be fixed on the trunk. I suspect > r12-3488-gc8b2b89358481d36755. Indeed it's fixed by that commit, and the testcase is very similar to PR101764. I suppose I'll mark this one as a dup then. *** This bug has been marked as a duplicate of bug 101764 ***
[Bug target/101716] lea does not have a zero_extend version of it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101716 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed.
[Bug testsuite/93216] [10 regression] gcc.dg/optimize-bswaphi-1.c fails starting with r280034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93216 Bug 93216 depends on bug 92979, which changed state. Bug 92979 Summary: bswap not finding a bswap with a memory load at the beginging of the instruction stream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949 Bug 92949 depends on bug 92979, which changed state. Bug 92979 Summary: bswap not finding a bswap with a memory load at the beginging of the instruction stream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/93040] gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040 --- Comment #7 from Andrew Pinski --- *** Bug 92979 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/92979] bswap not finding a bswap with a memory load at the beginging of the instruction stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 93040. *** This bug has been marked as a duplicate of bug 93040 ***
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 --- Comment #4 from H.J. Lu --- spawn -ignore SIGHUP /export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/gcc/testsuite/g++8/../../xg++ -B/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/gcc/testsuite/g++8/../../ /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-header-3_a.H -fdiagnostics-plain-output -nostdinc++ -I/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/i686-linux/libstdc++-v3/include/i686-linux -I/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodule-header -S -o xtreme-header-3_a.s /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-header-3_a.H: internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have namespace_decl in get_merge_kind, at cp/module.cc:10072 0x8475867 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /export/gnu/import/git/gitlab/x86-gcc/gcc/tree.c:8689 0x82e6ccc template_info_decl_check(tree_node const*, char const*, int, char const*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/cp-tree.h:651 0x82e8183 template_info_decl_check(tree_node const*, char const*, int, char const*) /export/gnu/import/git/gitlab/x86-gcc/gcc/tree.h:3433 0x82e8183 trees_out::get_merge_kind(tree_node*, depset*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:10070 0x86609a8 trees_out::decl_value(tree_node*, depset*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:7501 0x8661b44 trees_out::decl_node(tree_node*, walk_kind) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:8536 0x8662b8a trees_out::tree_node(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:9091 0x8662ed9 trees_out::chained_decls(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:4840 0x8663cf1 trees_out::core_vals(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:6060 0x86669ba trees_out::tree_node_vals(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:7062 0x86669ba trees_out::tree_value(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:8898 0x86629fd trees_out::tree_node(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:9096 0x8666ad6 trees_out::write_function_def(tree_node*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:11352 0x8668bad depset::hash::find_dependencies(module_state*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:13128 0x8668fc0 module_state::write(elf_out*, cpp_reader*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:17615 0x866a5fa finish_module_processing(cpp_reader*) /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/module.cc:19871 0x85fea25 c_parse_final_cleanups() /export/gnu/import/git/gitlab/x86-gcc/gcc/cp/decl2.c:5222 Please submit a full bug report, with preprocessed source if appropriate.
[Bug libgomp/102571] New: FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102571 Bug ID: 102571 Summary: FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Target: i686,x86-64 libgomp.c-c++-common/atomic-21.c always fails with -m32 -mfpmath=sse
[Bug tree-optimization/102570] New: missed fully redudant with internal function of add_overflow in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102570
Bug ID: 102570
Summary: missed fully redudant with internal function of
add_overflow in FRE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
bool f1(unsigned x, unsigned y, unsigned *res)
{
bool t = __builtin_add_overflow(x, y, res);
unsigned res1;
bool t1 = __builtin_add_overflow(x, y, );
*res -= res1;
return t==t1;
}
This should be optimized at fre1 but currently takes into DOM to optimize it to
just *res = 0; return 1;
FRE does not handle some of the internal functions.
Note this is different from PR 102569 but related.
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 fink at snaggledworks dot com changed: What|Removed |Added CC||fink at snaggledworks dot com --- Comment #26 from fink at snaggledworks dot com --- Current gcc-11.2 builds with Xcode 13 w/out having to use `--without-build-config`. Exact same setup failed w/ Xcode 12.5.1.
[Bug tree-optimization/96397] GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/102569] New: Missed redudant add with add_overflow on the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102569
Bug ID: 102569
Summary: Missed redudant add with add_overflow on the tree
level
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
bool f1(unsigned x, unsigned y, unsigned *res)
{
bool t = __builtin_add_overflow(x, y, res);
*res -= (x+y);
return t;
}
- CUT
We currently get:
_7 = .ADD_OVERFLOW (x_5(D), y_6(D));
_1 = REALPART_EXPR <_7>;
_2 = IMAGPART_EXPR <_7>;
t_10 = (bool) _2;
_3 = x_5(D) + y_6(D);
_4 = _1 - _3;
But _3 and _1 are the same _4 should be optimized to 0 as it is on the RTL
level.
The way I see this being done is during the late fre add x+y in the table for
REALPART_EXPR<_7> and it will be done correctly.
[Bug tree-optimization/98703] Failure to optimize out non-zero check after multiplication overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed. Note the released version of GCC 11, f2 does not produce the extra compare.
[Bug middle-end/98649] Trivial jump table not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98649 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #3 from Andrew Pinski --- Confirmed. Interesting LLVM does not do the optimization either ...
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #5 from Jonathan Wakely --- (In reply to Florian Weimer from comment #3) > Neither paper seems to cover a polymorphic function type that takes > ownership, though, so I don't quite see how these replace std::function. To be clear, std::move_only_function is exactly a polymorphic function type that takes ownership. Without the constraint that the target type it takes ownership of needs to be copy-constructible.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #4 from Jonathan Wakely --- (In reply to Florian Weimer from comment #3) > (In reply to Jonathan Wakely from comment #1) > > This is not a libstdc++ bug, we implement what the standard says. > > > > Maybe it used to compile, but it was meaningless. You could say it was a > > function of void() noexcept, but you could still store a target function > > that throwed, and its operator() could still throw. > > Sure, but in my code, I did not do this. The call operator was invoked in a > noexcept context, and the type was expected to match (but of course the > compiler did not check this). Then you need to stop doing it, the C++17 changes make it no longer possible to use that extra annotation in the type to signify something that wasn't checked, or even necessarily true. > Neither paper seems to cover a polymorphic function type that takes > ownership, though, so I don't quite see how these replace std::function. They're not supposed to replace it, they supplement it for additional scenarios (non-owning, or owning a movable but non-copyable target). My point is just that the newer facilities being added do allow you to use noexcept the way you want to, but std::function doesn't. And I doubt anybody is going to propose extending it that way. Either way, it's not a libstdc++ bug.
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99496 --- Comment #3 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #2) > I think the library code is correct but I'll check it My bet is some latent bug in the C++ front-end exposing this.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #3 from Florian Weimer --- (In reply to Jonathan Wakely from comment #1) > This is not a libstdc++ bug, we implement what the standard says. > > Maybe it used to compile, but it was meaningless. You could say it was a > function of void() noexcept, but you could still store a target function > that throwed, and its operator() could still throw. Sure, but in my code, I did not do this. The call operator was invoked in a noexcept context, and the type was expected to match (but of course the compiler did not check this). > Both std::move_only_function (P0288) and std::function_ref (P0792) support > using a function type that is optionally const-qualified and optionally > noexcept, and it actually means something (it affects what you can store in > there, and whether they can modify a stateful target object, and whether > their operator() is noexcept or not). std::function is not going to get > updated though. Neither paper seems to cover a polymorphic function type that takes ownership, though, so I don't quite see how these replace std::function. Or is std::function semi-deprecated because it poorly matches capture-by-reference in lambdas?
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #2 from Jonathan Wakely --- (In reply to Florian Weimer from comment #0) > In earlier language versions, code like this used to compile because > noexcept was not part of the type system. This also used to compile: void f() noexcept(false); void (*p)() noexcept = But it was meaningless, p() could still throw. In C++17 it doesn't work.
[Bug libstdc++/102567] Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- This is not a libstdc++ bug, we implement what the standard says. Maybe it used to compile, but it was meaningless. You could say it was a function of void() noexcept, but you could still store a target function that throwed, and its operator() could still throw. Both std::move_only_function (P0288) and std::function_ref (P0792) support using a function type that is optionally const-qualified and optionally noexcept, and it actually means something (it affects what you can store in there, and whether they can modify a stateful target object, and whether their operator() is noexcept or not). std::function is not going to get updated though.
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed at r12-4096, thanks again.
[Bug target/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug target/94174] Missed ccmp optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug target/92061] build of gencondmd fails with clang-9.0 (trunk, gcc 9.2.1, probably other older versions of gcc as yet untested) with undefined symbols for ix86_binary_operator_ok and related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92061 fink at snaggledworks dot com changed: What|Removed |Added CC||fink at snaggledworks dot com --- Comment #7 from fink at snaggledworks dot com --- For the record, Apple-clang-13.0.0 from Xcode13 fails to build gcc-9.4 and gcc-10.3 (gcc-11.2 builds) getting this error. The patch to gcc/genconditions.c in comment #5 fixes the missing symbol failure.
[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 Andrew Pinski changed: What|Removed |Added CC||kamkaz at windowslive dot com --- Comment #3 from Andrew Pinski --- *** Bug 102568 has been marked as a duplicate of this bug. ***
[Bug c++/102568] "taking address of temporary array" error when passing temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102568 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 94264. *** This bug has been marked as a duplicate of bug 94264 ***
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 --- Comment #3 from Aldy Hernandez --- Probably needs GTY markers, and possibly putting it invalid_range in file scope.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- fixed
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:6c0dd02964a624c65859808f9a40721c3796319a commit r12-4095-g6c0dd02964a624c65859808f9a40721c3796319a Author: Aldy Hernandez Date: Sat Oct 2 16:59:26 2021 +0200 [PR102563] Do not clobber range in operator_lshift::op1_range. We're clobbering the final range before we're done calculating it. Tested on x86-64 Linux. gcc/ChangeLog: PR tree-optimization/102563 * range-op.cc (operator_lshift::op1_range): Do not clobber range. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr102563.c: New test.
[Bug c++/102568] New: "taking address of temporary array" error when passing temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102568
Bug ID: 102568
Summary: "taking address of temporary array" error when passing
temporary array
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kamkaz at windowslive dot com
Target Milestone: ---
void foo(int* arr);
int main() {
using array = int[5];
foo((array{1, 2, 3, 4, 5}));
}
Gives an error:
: In function 'int main()':
:6:31: error: taking address of temporary array
Problem occurs on all GCC versions 4.7.1 up.
[Bug libstdc++/102567] New: Missing noexcept specialization of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 Bug ID: 102567 Summary: Missing noexcept specialization of std::function Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- When C++17 made noexcept part of the type system, std::function was not updated accordingly. As a result, this program fails to compile: #include std::function f; t.cc:2:32: error: aggregate ‘std::function f’ has incomplete type and cannot be defined 2 | std::function f; |^ In earlier language versions, code like this used to compile because noexcept was not part of the type system. Seen with: gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521
--- Comment #4 from anlauf at gcc dot gnu.org ---
Tentative patch:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index b3c65b7175b..cebc59e4ab5 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2228,12 +2228,15 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
gfc_expr *array;
int n;
if (sym->attr.flavor == FL_PARAMETER
- && init->expr_type == EXPR_CONSTANT
- && spec_size (sym->as, )
- && mpz_cmp_si (size, 0) > 0)
+ && (init->expr_type == EXPR_CONSTANT
+ || init->expr_type == EXPR_STRUCTURE)
+ && spec_size (sym->as, )
+ && mpz_cmp_si (size, 0) > 0)
{
array = gfc_get_array_expr (init->ts.type, init->ts.kind,
>where);
+ if (init->ts.type == BT_DERIVED)
+ array->ts.u.derived = init->ts.u.derived;
for (n = 0; n < (int)mpz_get_si (size); n++)
gfc_constructor_append_expr (>value.constructor,
n == 0
[Bug rtl-optimization/93455] aarch64: Q constraint address is recomputed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93455 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Known to fail||5.4.0 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug middle-end/86145] Inefficient homogeneous struct return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86145 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-02 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed, might be a dup of a few others.
[Bug middle-end/65410] "Short local string array" optimization doesn't happen if string has NULs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65410 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed for GCC 9 by r9-2897-gd01b568a78351beb6b6.
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug c++/101133] [coroutines] co_await doesn't accept a valid awaitable object if await_resume()'s return type is not a built-in type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 --- Comment #7 from TC --- (In reply to Jonathan Wakely from comment #6) > I have looked in detail (I have the 3rd, 4th and 5th editions here) but my > brain started oozing out of my ears. > > 15.10.2.15 NonemptyClassRanges and 15.10.2.16 NonemptyClassRangesNoDash are > the relevant sections of the 1999 3rd edition. The former defines: > > The internal helper function CharacterRange takes two CharSet parameters > A and B and performs the following: > 1. If A does not contain exactly one character or B does not contain > exactly > one character then throw a SyntaxError exception. > > And the latter has this note: > > Informative comments: ClassRanges can expand into single ClassAtoms and/or > ranges of two ClassAtoms separated by dashes. In the latter case the > ClassRanges includes all characters between the first ClassAtom and the > second ClassAtom, inclusive; an error occurs if either ClassAtom does not > represent a single character (for example, if one is \w) or if the first > ClassAtom's code point value is greater than the second ClassAtom's code > point value. > > > > The ClassAtom \w does not contain exactly one character, so I think it's a > syntax error. > > The 3rd edition doesn't mention any legacy features of RegExp, but it does > seem to require the strict behaviour. I've looked at the 1999 spec now, and agree with your reading.
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #2 from Aldy Hernandez ---
Going up the backtrace we see:
(gdb)
#3 0x01b43aff in irange::intersect (this=0x7fffc8e0,
other=0x3c7aa40 )
at /home/aldyh/src/gcc/gcc/value-range.cc:1514
(gdb)
#4 0x01b3e1e8 in irange::intersect (this=0x7fffc8e0, r=...)
at /home/aldyh/src/gcc/gcc/value-range.h:549
(gdb)
#5 0x02a78c33 in alloca_call_type (stmt=,
is_vla=false)
at /home/aldyh/src/gcc/gcc/gimple-ssa-warn-alloca.c:229
We're intersecting with invalid_range which is a static member:
static int_range<2> invalid_range (build_int_cst (size_type_node, 0),
build_int_cst (size_type_node,
max_size),
VR_ANTI_RANGE);
It looks like it has members that have been GC freed:
(gdb) print invalid_range
$9 = { = {m_num_ranges = 1 '\001', m_max_ranges = 2 '\002', m_kind =
VR_RANGE,
m_base = 0x3c7aa50 },
m_ranges = {
, , , }}
(gdb)
The m_ranges bits are trees in int_range, which live in GC, and trees are
inherently GC'ish.
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #1 from Aldy Hernandez --- confirmed
[Bug target/102566] New: [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
Bug ID: 102566
Summary: [i386] GCC should emit LOCK BTS for simple
bit-test-and-set operations with std::atomic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Simple test:
$ cat test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_or(1, std::memory_order_relaxed) & 1;
}
The sequence x.fetch_or(singlebit_constant) & singlebit_constant can be
implemented by a LOCK BTS sequence. The above should emit:
lock bts $1, (%rdi)
setb %al
ret
But instead it emits a cmpxchg loop - see https://gcc.godbolt.org/z/99enKaffa.
This was found reviewing MariaDB lightweight-mutex code, which uses the sign
bit to indicate a contended mutex. See this commit[1] by one of their
maintainers for the removal of fetch_or because it emits an extra loop.
Bonus: LOCK BTR can be used in the sequence x.fetch_and(~single_bit_constant) &
single_bit_constant
[1]
https://github.com/dr-m/atomic_sync/commit/d5e22b2d42cdbac7a15d242bf1446377555c4041
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #4 from Iain Sandoe ---
(In reply to Riccardo Brugo from comment #0)
> Created attachment 50621 [details]
Of course, we should not ICE - but ...
> struct promise_type {
> std::optional _value = std::nullopt;
>
> future get_return_object() {
> return future{handle_type::from_promise(*this)};
> }
> void return_value(value_type val) {
> _value = static_cast(val);
> }
> auto initial_suspend() noexcept {
> class awaiter {
> std::optional & value;
> public:
> explicit awaiter(std::optional & val) noexcept :
> value{val} {}
> bool await_ready() noexcept { return value.has_value(); }
> void await_suspend(handle_type) noexcept { }
> value_type & await_resume() noexcept { return *value; }
> };
>
> return awaiter{_value};
> }
The ICE is caused by the code handling a reference from the co_await - where it
was not expecting any value to be returned from the initial or final
await_resume() functions.
---
How do you expect to use the value returned by value_type & await_resume()
noexcept { return *value; } in this?
see: https://eel.is/c++draft/dcl.fct.def.coroutine#5
essentially the value(s) of the initial and final co_await expressions are
discarded. So of course, you can have any side-effect you like from the
evaluation of the expressions - but there is no way for you to see the result
of the await_resume().
Ergo it might as well be void...
however, let's fix the ICE anyway.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Attachment #51534|0 |1 is obsolete|| --- Comment #4 from Aldy Hernandez --- Created attachment 51535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51535=edit untested 2
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #3 from Aldy Hernandez --- mine. we're clobbering the final range while calculating the intermediate range.
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Aldy Hernandez changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #2 from Aldy Hernandez --- *** Bug 102561 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102561] [12 Regression] ICE Segmentation fault during GIMPLE pass: evrp (on -O2 and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102561 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Aldy Hernandez --- duplicate *** This bug has been marked as a duplicate of bug 102563 ***
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 --- Comment #1 from Aldy Hernandez --- Created attachment 51534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51534=edit untested patch
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Jonathan Wakely --- Indeed, thanks.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #3 from Jonathan Wakely --- See PR 102562
[Bug tree-optimization/102560] [12 Regression] g++.dg/Walloca1.C ICE with aggressive GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560 Andrew Pinski changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com Target Milestone|--- |12.0
[Bug tree-optimization/102563] [12 Regression] ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||ice-on-valid-code Component|c |tree-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102561 Summary|ice during GIMPLE pass: |[12 Regression] ice during |vrp-thread |GIMPLE pass: vrp-thread
[Bug tree-optimization/102564] Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Blocks||53947 Keywords||alias, missed-optimization --- Comment #1 from Andrew Pinski --- I suspect the vectorizer is not adding an alias check in the case of reduction. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #2 from Dominique d'Humieres --- New failures between r12-4031 and r12-4090: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2021-10-02
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Iain Sandoe ---
For the record, general VLAs are not supported by clang coroutines either.
the following coroutine fails to compile there as well.
//using test-suite convenience headers.
#include "coro.h"
#include "coro1-ret-int-yield-int.h"
struct coro1
foo (int arg) noexcept
{
PRINTF ("foo arg = %d\n", arg);
char arr[arg];
if (arg < 4)
co_return -6174;
else
for (int i = 0; i < arg; ++i) arr[i] = (char) i;
co_yield (int) arr[2];
co_return (int) arr[3];
}
[Bug c++/84898] Fix-it hints for '.' vs '->'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to David Malcolm from comment #4) > Candidate patch: > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01909.html > which implements the fix-it hints for C++, but doesn't change the wording. Does this patch still apply/work?
[Bug c/53871] Please warn about endless loops if they are obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org, ||kuq03132 at qoika dot com --- Comment #10 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #3) > (In reply to Tim Ruehsen from comment #2) > > Maybe it's time for a gcc static analyzer... > > In terms of technology, never has been a better time than now: GCC internals > have never been as clean and re-usable, there is some interest in > modularization, there is now the possibility of creating powerful plugins, > etc. However, in terms of human resources, there is simply no one interested > in working on this, for the reasons given above. Hence, someone new will > need to appear: either a new company, a new group of developers, or a > charismatic and committed developer that can rally existing developers > around him/her. So, David Malcolm has contributed a static analyzer to GCC now; cc-ing him...
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #5 from m.cencora at gmail dot com --- code review comment: the change in file 'fs_ops.cc', func: 'fs::create_directory' to use 'function_function_not_supported' looks like a typo, isn't it?
[Bug tree-optimization/102565] New: ICE: in upper_bound, at value-range.h:531 under -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102565
Bug ID: 102565
Summary: ICE: in upper_bound, at value-range.h:531 under -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: suochenyao at 163 dot com
Target Milestone: ---
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core).0, x86_64 GNU/Linux
***
Program:
struct a {
signed b;
};
char c;
short d;
int e;
long(f)() { return 0; }
void g() {
struct a h = {1};
short *i =
*i = 0;
e = c << h.b;
f(e == 1 || d) == c;
}
void main() {}
***
version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev/ --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211002 (experimental) (GCC)
git ver: 9d116bcc5556c7df32803f7bf8e6e238ea1c13fb
***
Command Lines:
$ gcc -O2 a.c
during GIMPLE pass: evrp
a.c: In function ‘g’:
a.c:15:1: internal compiler error: in upper_bound, at value-range.h:531
15 | void main() {}
| ^~~~
0xbc9939 irange::upper_bound() const
../../gcc/value-range.h:531
0x1be6f03 operator_lshift::op1_range(irange&, tree_node*, irange const&, irange
const&, tree_code) const
../../gcc/range-op.cc:2131
0x1ae0b0b gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
../../gcc/gimple-range-gori.cc:1011
0x1ae0b9e gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
../../gcc/gimple-range-gori.cc:689
0x1ae0b9e gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
../../gcc/gimple-range-gori.cc:1064
0x1ae1bc1 gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
../../gcc/gimple-range-gori.cc:689
0x1ae1bc1 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*,
range_query&)
../../gcc/gimple-range-gori.cc:1245
0x1ad5b93 ranger_cache::range_on_edge(irange&, edge_def*, tree_node*)
../../gcc/gimple-range-cache.cc:979
0x1ad62f5 ranger_cache::range_on_edge(irange&, edge_def*, tree_node*)
../../gcc/gimple-range-fold.h:97
0x1ad62f5 ranger_cache::propagate_cache(tree_node*)
../../gcc/gimple-range-cache.cc:1078
0x1ad6c6d ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
../../gcc/gimple-range-cache.cc:1290
0x1ad6dcf ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
../../gcc/gimple-range-cache.cc:1022
0x1ad2b39 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
../../gcc/gimple-range.cc:131
0x1ad32a8 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc/gimple-range.cc:105
0x1adc712 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../gcc/gimple-range-fold.cc:604
0x1addc09 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
../../gcc/gimple-range-fold.cc:556
0x1ad290d gimple_ranger::fold_range_internal(irange&, gimple*, tree_node*)
../../gcc/gimple-range.cc:226
0x1ad290d gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc/gimple-range.cc:269
0x1ad33ff gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc/gimple-range.cc:100
0x11abbdf range_query::value_of_expr(tree_node*, gimple*)
../../gcc/value-query.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug tree-optimization/102564] New: Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564
Bug ID: 102564
Summary: Missed loop vectorization with reduction and ptr
load/store inside loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void test1(int *p, int *t, int N) {
for (int i = 0; i != N; i++) *t += p[i];
}
void test2(int *p, int *t, int N) {
if (N > 1024) // hint, N is not small
for (int i = 0; i != N; i++) *t += p[i];
}
void test3(int *p, int *t, int N) {
if (N > 1024) { // hint, N is not small
int s = 0;
for (int i = 0; i != N; i++) s += p[i];
*t += s;
}
}
test3 is successfully vectorized with LLVM, GCC, ICC. Sadly, only ICC can catch
test1 and test2.
https://godbolt.org/z/PzoYd4eEK
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 --- Comment #2 from Jonathan Wakely --- Oh,I saw these failures but thought they were already happening. I guess I made it worse. I think the library code is correct but I'll check it
[Bug c/102563] New: ice during GIMPLE pass: vrp-thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Bug ID: 102563
Summary: ice during GIMPLE pass: vrp-thread
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
int _bdf_parse_glyphs_bp;
long _bdf_parse_glyphs_nibbles;
void _bdf_parse_glyphs_p()
{
long p_2;
_bdf_parse_glyphs_nibbles = p_2 << 1;
for (; 0 < _bdf_parse_glyphs_nibbles;)
if (1 < _bdf_parse_glyphs_nibbles)
_bdf_parse_glyphs_bp = _bdf_parse_glyphs_p;
}
compiled by recent gcc trunk and compiler flag -O2, does this:
$ /home/dcb/gcc/results/bin/gcc -c -O2 bug762.c
bug762.c: In function ‘_bdf_parse_glyphs_p’:
bug762.c:12:28: warning: assignment to ‘int’ from ‘void (*)()’ makes integer
from pointer without a cast [-Wint-conversion]
12 | _bdf_parse_glyphs_bp = _bdf_parse_glyphs_p;
|^
during GIMPLE pass: vrp-thread
bug762.c:4:6: internal compiler error: in upper_bound, at value-range.h:531
4 | void _bdf_parse_glyphs_p()
| ^~~
0x1b7a732 irange::upper_bound() const
../../trunk.git/gcc/value-range.h:531
The bug first seems to occur sometime between git hash
6de9f0c13b27c343 and 5f02854189405771.
[Bug c/102103] missing warning comparing array address to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- This should probably get a note in gcc-12/changes.html IMO
[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-02 --- Comment #1 from Martin Liška --- Started likely with r12-4067-gc46ecb0112e91c8.
[Bug c++/102562] New: [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562 Bug ID: 102562 Summary: [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Likely since I see the following failures on x86_64-linux-gnu: g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors) g++.log: FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.log: FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
[Bug bootstrap/57683] Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.3 Resolution|--- |FIXED Keywords||build Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed so closing.
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Target Milestone|--- |9.4
[Bug gcov-profile/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636 Andrew Pinski changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #20 from Andrew Pinski --- *** Bug 72848 has been marked as a duplicate of this bug. ***
[Bug bootstrap/72848] profiledbootstrap: internal compiler error: in streamer_write_gcov_count_stream, at data-streamer-out.c:366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72848 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 64636 which is fixed in GCC 9.4.0 *** This bug has been marked as a duplicate of bug 64636 ***
[Bug c++/101073] [9/10/11/12 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/101071] [9/10/11/12 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Andrew Pinski changed: What|Removed |Added Target Milestone|10.4|9.5 Summary|[10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in |in |gimplify_init_constructor, |gimplify_init_constructor, |at gimplify.c:5228 |at gimplify.c:5228 Known to work||9.3.0 Known to fail||10.1.0, 9.4.0 Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, also started to ICE in GCC 9.4.0. Note the full command line needed to get the ICE is: -fno-elide-constructors -O2 -std=c++14 using -std=c++11 the code does not ICE. Also note in GCC 9.3 and before -fno-elide-constructors -std=c++14 rejects the code.
[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 Andrew Pinski changed: What|Removed |Added CC||tilin97 at yandex dot ru --- Comment #12 from Andrew Pinski --- *** Bug 95292 has been marked as a duplicate of this bug. ***
[Bug c++/95292] ICE in expand_expr_real_2, at expr.c:8538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95292 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed in GCC 8.5.0, 9.4.0, 10.3.0 and 11+. Dup of bug 99790. *** This bug has been marked as a duplicate of bug 99790 ***
[Bug c++/101099] [9/10/11/12 Regression] ICE in type_unification_real, at cp/pt.c:22173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101099 Andrew Pinski changed: What|Removed |Added CC||nwentzell@flatironinstitute ||.org --- Comment #2 from Andrew Pinski --- *** Bug 91867 has been marked as a duplicate of this bug. ***
[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91867 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- This is a dup of bug 101099. *** This bug has been marked as a duplicate of bug 101099 ***
[Bug c++/101595] ICE: in tsubst_pack_expansion, at cp/pt.c:13124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101595 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101764 --- Comment #2 from Andrew Pinski --- This seems to be fixed on the trunk. I suspect r12-3488-gc8b2b89358481d36755.
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 --- Comment #6 from Jonathan Wakely --- I have looked in detail (I have the 3rd, 4th and 5th editions here) but my brain started oozing out of my ears. 15.10.2.15 NonemptyClassRanges and 15.10.2.16 NonemptyClassRangesNoDash are the relevant sections of the 1999 3rd edition. The former defines: The internal helper function CharacterRange takes two CharSet parameters A and B and performs the following: 1. If A does not contain exactly one character or B does not contain exactly one character then throw a SyntaxError exception. And the latter has this note: Informative comments: ClassRanges can expand into single ClassAtoms and/or ranges of two ClassAtoms separated by dashes. In the latter case the ClassRanges includes all characters between the first ClassAtom and the second ClassAtom, inclusive; an error occurs if either ClassAtom does not represent a single character (for example, if one is \w) or if the first ClassAtom's code point value is greater than the second ClassAtom's code point value. The ClassAtom \w does not contain exactly one character, so I think it's a syntax error. The 3rd edition doesn't mention any legacy features of RegExp, but it does seem to require the strict behaviour.
[Bug c++/98930] ICE with static variable in template function used as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98930
Andrew Pinski changed:
What|Removed |Added
Summary|ICE when using function |ICE with static variable in
|local static constexpr |template function used as
|variable at runtime |template argument
--- Comment #3 from Andrew Pinski ---
Shortest testcase:
template
struct g { g() { *format =1; } };
template
void impl() {
static int i=1;
static g<> h{};
}
int main() {
impl<0>();
return 0;
}
[Bug c++/98930] ICE when using function local static constexpr variable at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98930 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/98930] ICE when using function local static constexpr variable at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98930 --- Comment #1 from Andrew Pinski --- *** Bug 98288 has been marked as a duplicate of this bug. ***
[Bug c++/98288] Accidental equality of classes templated by pointer to local static constant of templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98288 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 98930. *** This bug has been marked as a duplicate of bug 98930 ***
[Bug c++/95968] error: 'args#0' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95968 --- Comment #1 from Andrew Pinski --- Hmm, clang also rejects this (even with libc++).
[Bug ipa/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95264 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog CC||marxin at gcc dot gnu.org Component|c++ |ipa Status|WAITING |NEW
