[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bbdf59fdbc2ce41ccfac807b15cf3fac7b465a56 commit r11-7656-gbbdf59fdbc2ce41ccfac807b15cf3fac7b465a56 Author: Jakub Jelinek Date: Sat Mar 13 08:56:15 2021 +0100 match.pd: Don't optimize vector X + (X << C) -> X * (1 + (1 << C)) if there is no mult support [PR99544] E.g. on aarch64, the target has V2DImode addition and shift by scalar optabs, but doesn't have V2DImode multiply. The following testcase ICEs because this simplification is done after last lowering, but generally, even if it is done before that, turning it into a multiplication will not be an improvement because that means scalarization, while the former can be done in vectors. It would be nice if we added expansion support for vector multiplication by uniform constants using shifts and additions like we have for scalar multiplication, but that is something that can be done in stage1. 2021-03-13 Jakub Jelinek PR tree-optimization/99544 * match.pd (X + (X << C) -> X * (1 + (1 << C))): Don't simplify if for vector types multiplication can't be done in type's mode. * gcc.dg/gomp/pr99544.c: New test.
[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug libstdc++/99572] New: std::counting_semaphore coalescing wakes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99572 Bug ID: 99572 Summary: std::counting_semaphore coalescing wakes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: michaelkuc6 at gmail dot com Target Milestone: --- Created attachment 50379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50379&action=edit Non-waking semaphores source code When repeatedly calling `std::counting_semaphore::release()`, only a single thread is woken, unless the releasing thread is made to sleep. A minimal example of the error is at https://github.com/Crystalix007/GCC-Semaphores, or as the attached file (compiled with `g++ --std=c++20 -o Sem -lpthread source.cpp`). Inspecting with GDB myself, the semaphore release function calls `std::__atomic_semaphore::_M_release()`, implemented https://github.com/gcc-mirror/gcc/blob/5987d8a79cda1069c774e5c302d5597310270026/libstdc%2B%2B-v3/include/bits/semaphore_base.h#L270. Notably the semaphore release only wakes a single thread, which would be OK if a different thread were woken each time. Eventually the call chain ends up performing a futex syscall https://github.com/gcc-mirror/gcc/blob/5987d8a79cda1069c774e5c302d5597310270026/libstdc%2B%2B-v3/include/bits/atomic_wait.h#L112. As far as I can tell, this doesn't correctly handle repeated wake-ups. Testing against the POSIX semaphore implementation, GCC's implementation seems to wake up only a single thread (i.e. coalescing all wakeup events into one). By sleeping the thread between semaphore releases, the program can actually finish. If the delay is too short, sometimes only some of the threads are woken, but with a sufficient delay, all threads are woken correctly. Unless I'm misunderstanding, is it possible that the woken thread is not marked as woken, or the futex wake just doesn't care that the woken thread is already awake? GCC Version (compiled from commit a18ebd6c439): Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/michaelkuc6/.cache/yay/gcc-git/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210307 (experimental) (GCC) System Type: Linux (x86_64) (specifically Arch Linux kernel 5.11.2)
[Bug fortran/99125] [9/10/11 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 --- Comment #6 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:7987beec679898cfa75839551d55ae5234a216bd commit r11-7657-g7987beec679898cfa75839551d55ae5234a216bd Author: Paul Thomas Date: Sat Mar 13 11:39:57 2021 + Fortran: Fix for class defined operators [PR99125]. 2021-03-13 Paul Thomas gcc/fortran PR fortran/99125 * trans-array.c (gfc_conv_expr_descriptor): For deferred length length components use the ss_info string length instead of gfc_get_expr_charlen. Make sure that the deferred string length is a variable before assigning to it. Otherwise use the expr. * trans-expr.c (gfc_conv_string_length): Make sure that the deferred string length is a variable before assigning to it. gcc/testsuite/ PR fortran/99125 * gfortran.dg/alloc_deferred_comp_1.f90: New test.
[Bug c++/99573] New: ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573
Bug ID: 99573
Summary: ICE in module: internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark)
in start_enum, at cp/decl.c:15663
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: niancw29 at 163 dot com
Target Milestone: ---
Created attachment 50380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50380&action=edit
obj-some-std.ii and obj-main.ii
There are two files:
// some-std.cc
export module A;
#include
// main.cpp
import A;
int main(){}
I know it won't compile, but it introduces an ICE. Compiling with
--
g++ -fmodules-ts -std=c++20 some-std.cc main.cpp -o obj
--
then I reproduce it.
Here is the total output using "g++ -v":
--
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210308 (experimental) (GCC)
--
In file included from /usr/local/include/c++/11.0.1/string:38,
from some-std.cc:3:
/usr/local/include/c++/11.0.1/bits/stl_iterator_base_funcs.h: In function
‘constexpr void std::__advance(_InputIterator&, _Distance,
std::input_iterator_tag)’:
/usr/local/include/c++/11.0.1/bits/stl_iterator_base_funcs.h:151:7: error:
block-scope extern declaration ‘void std::__failed_assertion()’ not permitted
in module purview
151 | __glibcxx_assert(__n >= 0);
| ^~~~
In file included from /usr/local/include/c++/11.0.1/bits/stl_iterator.h:81,
from /usr/local/include/c++/11.0.1/bits/stl_algobase.h:67,
from /usr/local/include/c++/11.0.1/bits/char_traits.h:39,
from /usr/local/include/c++/11.0.1/string:40,
from some-std.cc:3:
/usr/local/include/c++/11.0.1/new: At global scope:
/usr/local/include/c++/11.0.1/new:89:27: error: cannot define ‘enum class
std::align_val_t’ in different module
89 | enum class align_val_t: size_t {};
| ^~
: note: declared here
/usr/local/include/c++/11.0.1/new:89:27: internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at
cp/decl.c:15663
0x833681 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9864
0x66bb45 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3476
0x66bb45 start_enum(tree_node*, tree_node*, tree_node*, tree_node*, bool,
bool*)
../../gcc/gcc/cp/decl.c:15663
0xa63207 cp_parser_enum_specifier
../../gcc/gcc/cp/parser.c:19965
0xa63207 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18391
0xa63ef9 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15041
0xa64cd1 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:14298
0xa919d5 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14116
0xa91309 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14145
0xa91309 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13933
0xa917a2 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20433
0xa917a2 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20411
0xa91ef8 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14096
0xa91309 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14145
0xa91309 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13933
0xa92c85 cp_parser_linkage_specification
../../gcc/gcc/cp/parser.c:15309
0xa91aea cp_parser_declaration
../../gcc/gcc/cp/parser.c:14035
0xa9274c cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14145
0xa9274c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4936
0xa9274c c_parse_file()
../../gcc/gcc/cp/parser.c:45231
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/96318] FAIL: c-c++-common/asan/strncpy-overflow-1.c * output pattern test with C on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96318 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres --- > It's probable related to fact how are these routines internally > implemented on Darwin. You can add optional scan for the extra lines you see. What is "optional scan"?
[Bug c++/98118] [coroutines] ICE with coroutine with parameter with non-trivial destructor since r10-6876-gdc192bbdd0442f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98118 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.3
[Bug target/99574] New: gcc-11 unrecognizable insn in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99574
Bug ID: 99574
Summary: gcc-11 unrecognizable insn in extract_constrain_insn,
at recog.c:2670
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Another internal compiler error from building a linux kernel, this time on
x86-32, reduced to:
$ cat sem.c
struct {
short a;
} * b;
struct {
int c;
} * d;
int e;
short f;
void g(void) {
for (;;) {
asm("" : "=r"(e) : "g"(d->c));
int h = f - b->a;
if (h > 7)
f = h;
}
}
$ x86_64-linux-gnu-gcc-11 --version
x86_64-linux-gnu-gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306
(experimental) [master revision
574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]
$ x86_64-linux-gnu-gcc-11 -m32 -fno-omit-frame-pointer -fno-strict-overflow
-O2 -c sem.c -Wall
sem.c: In function ‘g’:
sem.c:16:1: error: unrecognizable insn:
16 | }
| ^
(insn 9 6 7 4 (parallel [
(set (reg:SI 1 dx [92])
(asm_operands:SI ("") ("=r") 0 [
(mem:SI (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7
%sfp+-8 S4 A32]) [1 d.0_1->c+0 S4 A32])
]
[
(asm_input:SI ("g") sem.c:11)
]
[] sem.c:11))
(clobber (reg:CC 17 flags))
]) "sem.c":11:5 -1
(expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg:SI 2 cx [82])
(const:SI (unspec:SI [
(symbol_ref:SI ("e") [flags 0x2] )
] UNSPEC_GOTOFF))) [1 e+0 S4 A32])
(nil)))
during RTL pass: reload
sem.c:16:1: internal compiler error: in extract_constrain_insn, at recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/99570] internal error in extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570 --- Comment #1 from Arnd Bergmann --- I suppose this is a duplicate of #99567 and #99574, these happen with different compiler flags, but the backtrace is always the same.
[Bug c++/99575] New: [coroutines] unexpected move when co_awaiting a nonmoveable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575
Bug ID: 99575
Summary: [coroutines] unexpected move when co_awaiting a
nonmoveable object
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lemourin at gmail dot com
Target Milestone: ---
```
#if __has_include()
#include
namespace stdx {
using std::coroutine_handle;
using std::noop_coroutine;
using std::suspend_always;
using std::suspend_never;
} // namespace stdx
#elif __has_include()
#include
namespace stdx {
using std::experimental::coroutine_handle;
using std::experimental::noop_coroutine;
using std::experimental::suspend_always;
using std::experimental::suspend_never;
} // namespace stdx
#else
#error "coroutines unsupported"
#endif
class Task {
public:
struct promise_type {
Task get_return_object() { return Task{}; }
stdx::suspend_always initial_suspend() { return {}; }
stdx::suspend_always final_suspend() noexcept { return {}; }
void unhandled_exception() {}
void return_void() {}
};
bool await_ready() const { return false; }
void await_suspend(stdx::coroutine_handle continuation) {}
void await_resume() {}
};
class NonMoveableTask {
public:
NonMoveableTask() = default;
NonMoveableTask(const NonMoveableTask&) = delete;
NonMoveableTask(NonMoveableTask&&) = delete;
NonMoveableTask& operator=(const NonMoveableTask&) = delete;
NonMoveableTask& operator=(NonMoveableTask&& other) = delete;
bool await_ready() const { return false; }
void await_suspend(stdx::coroutine_handle) {}
void await_resume() {}
};
Task Foo(NonMoveableTask* task) { co_await* task; }
int main() {}
```
The above code snippet does not compile with gcc with the following error log:
`
move.cc: In function ‘Task Foo(NonMoveableTask*)’:
move.cc:50:45: error: use of deleted function
‘NonMoveableTask::NonMoveableTask(NonMoveableTask&&)’
50 | Task Foo(NonMoveableTask* task) { co_await* task; }
| ^~~~
move.cc:40:3: note: declared here
40 | NonMoveableTask(NonMoveableTask&&) = delete;
| ^~~
make: *** [: move] Error 1
`
clang and msvc accept it. If the move constructor is available code compiled
with gcc uses it and leaves `task` in a moved from state.
[Bug c++/99576] New: [coroutines] desctructor of a temporary called too early within co_await expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
Bug ID: 99576
Summary: [coroutines] desctructor of a temporary called too
early within co_await expression
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lemourin at gmail dot com
Target Milestone: ---
```
#if __has_include()
#include
namespace stdx {
using std::coroutine_handle;
using std::noop_coroutine;
using std::suspend_always;
using std::suspend_never;
} // namespace stdx
#elif __has_include()
#include
namespace stdx {
using std::experimental::coroutine_handle;
using std::experimental::noop_coroutine;
using std::experimental::suspend_always;
using std::experimental::suspend_never;
} // namespace stdx
#else
#error "coroutines unsupported"
#endif
#include
#include
#include
class Task {
public:
struct promise_type {
struct final_awaitable {
bool await_ready() noexcept { return false; }
auto await_suspend(stdx::coroutine_handle coro) noexcept {
return coro.promise().continuation;
}
void await_resume() noexcept {}
};
Task get_return_object() {
return Task(stdx::coroutine_handle::from_promise(*this));
}
stdx::suspend_always initial_suspend() { return {}; }
final_awaitable final_suspend() noexcept { return {}; }
void unhandled_exception() { std::terminate(); }
void return_void() {}
stdx::coroutine_handle continuation = stdx::noop_coroutine();
};
Task(const Task&) = delete;
Task(Task&& other) noexcept
: handle_(std::exchange(other.handle_, nullptr)) {}
Task& operator=(const Task&) = delete;
Task& operator=(Task&& other) noexcept {
handle_ = std::exchange(other.handle_, nullptr);
return *this;
}
~Task() {
if (handle_) {
handle_.destroy();
}
}
bool await_ready() const { return false; }
auto await_suspend(stdx::coroutine_handle continuation) {
handle_.promise().continuation = continuation;
return handle_;
}
void await_resume() {}
private:
explicit Task(stdx::coroutine_handle handle)
: handle_(handle) {}
stdx::coroutine_handle handle_;
};
struct RunTask {
struct promise_type {
RunTask get_return_object() { return {}; }
stdx::suspend_never initial_suspend() { return {}; }
stdx::suspend_never final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() { std::terminate(); }
};
};
struct Foo {
Foo() { std::cerr << "Foo()\n"; }
~Foo() { std::cerr << "~Foo()\n"; }
};
Task DoAsync() {
std::cerr << "START TASK\n";
co_return co_await [foo = Foo{}]() -> Task {
std::cerr << "IN LAMBDA\n";
co_return;
}();
}
RunTask Main() { co_await DoAsync(); }
int main() { Main(); }
```
gcc outputs:
`
START TASK
Foo()
~Foo()
IN LAMBDA
`
while clang and msvc output:
`
START TASK
Foo()
IN LAMBDA
~Foo()
`
Is this code undefined behavior? Or is clang and msvc wrong?
[Bug c/99577] New: Non-constant (but actually constant) initializers referencing other constants no longer diagnosed as of GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99577 Bug ID: 99577 Summary: Non-constant (but actually constant) initializers referencing other constants no longer diagnosed as of GCC 8 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: harald at gigawatt dot nl Target Milestone: --- GCC 8 and newer no longer issue an error for const int i = 0; const int j = i; Up until GCC 7, this resulted in test.c:2:15: error: initializer element is not constant const int j = i; ^ As in the similar (and perhaps related?) bug #66618, the standard does not require a diagnostic for this code, but this code is not portable, it gets rejected by some other compilers, so an option in GCC to diagnose this would be useful. This bug is the opposite of bug #53091, which asks for this to be accepted and was never updated after GCC started to accept it. As noted in that bug, clang accepts this as well without any diagnostic. I will report it as an issue to them too, if it has not been reported already.
[Bug c/99578] New: gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Bug ID: 99578
Summary: gcc-11 -Warray-bounds or -Wstringop-overread warning
when accessing a pointer from integer literal
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This snippet from the Linux kernel reads a data structure from an
architecturally defined location in memory into a local copy:
struct sharpsl_param_info {
unsigned int comadj_keyword;
};
extern struct sharpsl_param_info sharpsl_param;
typedef unsigned long __kernel_size_t;
extern void * memcpy(void *, const void *, __kernel_size_t);
void sharpsl_save_param(void)
{
memcpy(&sharpsl_param, (void *)(0xe8ffc000), sizeof(struct
sharpsl_param_info));
}
With gcc-11, this now triggers a -Wstringop-overread warning on x86:
arch/arm/common/sharpsl_param.i: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.i:11:2: warning: ‘memcpy’ reading 4 bytes from a
region of size 0 [-Wstringop-overread]
11 | memcpy(&sharpsl_param, (void *)(0xe8ffc000), sizeof(struct
sharpsl_param_info));
I tried to reproduce this on godbolt.org, which apparently has a slightly
different snapshot version and instead produces -Warray-bounds warning for the
same input: https://godbolt.org/z/ve6h6b
I could not find a way to avoid this warning, other than turning off the entire
warning option globally or with a pragma. Accessing a pointer from a literal
integer value is not too unusual in the kernel and should not cause a warning.
[Bug target/99574] gcc-11 unrecognizable insn in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99574 Arnd Bergmann changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Arnd Bergmann --- This was fixed at the same time as #99567, which has the same backtrace. *** This bug has been marked as a duplicate of bug 99567 ***
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 --- Comment #1 from Arnd Bergmann --- *** Bug 99574 has been marked as a duplicate of this bug. ***
[Bug target/99570] internal error in extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570 Arnd Bergmann changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Arnd Bergmann --- This was fixed at the same time as #99567, which has the same backtrace. *** This bug has been marked as a duplicate of bug 99567 ***
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 --- Comment #2 from Arnd Bergmann --- *** Bug 99570 has been marked as a duplicate of this bug. ***
[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99530 H.J. Lu changed: What|Removed |Added Attachment #50369|0 |1 is obsolete|| --- Comment #14 from H.J. Lu --- Created attachment 50381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50381&action=edit The v3 patch
[Bug c++/99579] New: gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 Bug ID: 99579 Summary: gmon.out not created with -O0 but otherwise is Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wsnyder at wsnyder dot org Target Milestone: --- Created attachment 50382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50382&action=edit Testcase == Description Type "make" in this tarball's directory. This will show (extra lines omitted): g++ -pg -O0 -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main.ii @ Did we get a gmon? make: [Makefile:15: x] Error 1 (ignored) g++ -pg -Os -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main.ii @ Did we get a gmon? 4554816 28 -rw-rw-r-- 1 user user 26943 Mar 13 11:33 ./gmon.out g++ -pg -O0 -c -o Vt_case_huge_prof__main.o Vt_case_huge_prof__main__ok.ii @ Did we get a gmon? 4554816884 -rw-rw-r-- 1 user user897414 Mar 13 11:33 ./gmon.out In short gcc -pg with -O0 is not creating a gmon. The problem goes away using -Os. The problem goes away if line 60549 of ~/d/case/Vt_case_huge_prof__main.ii std::array __Vtablechg1; is changed into CData __Vtablechg1[16384]; (The original program requires a unique class, not a std::array, so using C-style arrays is unfortunately not a workaround in my application.) While this "feels" like a memory corruption sort of bug, the program is sanitizer and warning clean. == gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == cat /etc/*release DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCC is emitting the mcount call correctly for each function. Glibc is the library where the mcount is located and enabling of the timer (SIGPROF) is enabled and it controls the outputting of the gmon.out. >From what I can tell if the timer does not happen, then there will be no gmon.out outputted. With a slower/older machine (AMD Athlon(tm) II X4 640 Processor), I sometimes get gmon.out and sometimes don't.
[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 --- Comment #2 from Wilson Snyder --- So glibc where to report this then?
[Bug middle-end/99579] gmon.out not created with -O0 but otherwise is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99579 Wilson Snyder changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Wilson Snyder --- Thanks. Filed glibc bug here https://sourceware.org/bugzilla/show_bug.cgi?id=27576
[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258 Johel Ernesto Guerrero Peña changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #9 from Johel Ernesto Guerrero Peña --- I think Bug 97700 is also a duplicate of this.
[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
The warning is by design. Its purpose is to detect invalid accesses at
non-zero offsets to null pointers, like in the memset call below:
struct S { int a, b[4]; };
void f (struct S *p)
{
if (p) return;
memset (p->b, 0, 4 * sizeof p->b);
}
For now, I recommend suppressing the warning either by #pragma GCC diagnostic
or by making the pointer volatile. In the future, providing an attribute to
annotate constant addresses with (or extending the io() attribute supported by
some targets to all targets) might be another way to avoid it.
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 Arnd Bergmann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Arnd Bergmann --- No longer reproducible with latest snapshot, I assume it was fixed.
[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:77643ac4bbd0ff758edc182a12cb622b74a3c38a commit r11-7658-g77643ac4bbd0ff758edc182a12cb622b74a3c38a Author: Martin Sebor Date: Tue Mar 9 15:02:35 2021 -0700 PR tree-optimization/99489 - ICE calling strncat after strcat gcc/ChangeLog: PR tree-optimization/99489 * builtins.c (gimple_call_alloc_size): Fail gracefully when argument is not a call statement. gcc/testsuite/ChangeLog: PR tree-optimization/99489 * gcc.dg/Wstringop-truncation-9.c: New test.
[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Sebor --- Fixed in r11-7658.
[Bug middle-end/88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 Bug 88781 depends on bug 99489, which changed state. Bug 99489 Summary: [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name() https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/99580] New: False positive -Warray-bounds with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99580
Bug ID: 99580
Summary: False positive -Warray-bounds with -O2
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sventeam at yandex dot ru
Target Milestone: ---
Created attachment 50383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50383&action=edit
Source to reproduce the issue
Using default GCC from Ubuntu 20.10.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.2.0-13ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1)
$ g++ -Warray-bounds -Werror -O2 qef_solver.cpp
qef_solver.cpp: In function ‘glm::mat3 jacobi(glm::mat3)’:
qef_solver.cpp:43:19: error: array subscript 3 is above array bounds of
‘glm::mat<3, 3, float>::col_type [3]’ {aka ‘glm::vec<3, float> [3]’}
[-Werror=array-bounds]
43 | return col[i];
|~~~^
qef_solver.cpp:52:14: note: while referencing ‘glm::mat<3, 3, float>::col’
52 | col_type col[3];
| ^~~
qef_solver.cpp:43:19: error: array subscript 3 is above array bounds of
‘glm::mat<3, 3, float>::col_type [3]’ {aka ‘glm::vec<3, float> [3]’}
[-Werror=array-bounds]
43 | return col[i];
|~~~^
qef_solver.cpp:52:14: note: while referencing ‘glm::mat<3, 3, float>::col’
52 | col_type col[3];
| ^~~
cc1plus: all warnings being treated as errors
This warning disappears if we change -O2 to -O1, or change `int j = i + 1` in
line 77 to `int j = i`, or comment out line 82 `max_j = j`.
[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #2 from Arnd Bergmann --- Ok, I see. Thanks for the explanation! I found a couple other instances (so far all false positive) and will see if any of them have a sane workaround. I'll probably just turn off both flags globally for the kernel otherwise.
[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700 --- Comment #3 from Johel Ernesto Guerrero Peña --- This seems to be a duplicate of Bug 83258.
[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258
--- Comment #10 from Johel Ernesto Guerrero Peña ---
Another workaround, extended from Bug 92320's example. See
https://godbolt.org/z/69onWf.
You can wrap the closure object in a template function which itself invokes the
closure object and converts to a function pointer that GCC accepts.
```C++
template
void templ() {}
void dummy(){}
template
void fn(){F();}
void foo() {
constexpr int a = 7 + 3;
templ();
templ();
typedef void(FPtr)();
constexpr FPtr * b = &dummy;
templ();
constexpr auto l = []{};
constexpr void (*d)()=fn;
templ();
constexpr FPtr * c = [](){};
templ();
}
```
[Bug rtl-optimization/99581] New: internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 Bug ID: 99581 Summary: internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 50384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50384&action=edit testcase when building the attached source for ppc64 target GCC is ICE'ing $ powerpc64le-yoe-linux-musl-g++ a.cpp -O2 -c during RTL pass: final a.cpp: In member function 'void QTWTF::TCMalloc_PageHeap::scavengerThread()': a.cpp:15583:1: internal compiler error: in print_operand_address, at config/rs6000/rs6000.c:14082 15583 | } | ^ 0x1532d58 internal_error(char const*, ...) ???:0 0x5e46b7 fancy_abort(char const*, int, char const*) ???:0 0x991823 output_address(machine_mode, rtx_def*) ???:0 0x991771 output_operand(rtx_def*, int) ???:0 0x99241c output_asm_insn(char const*, rtx_def**) ???:0 0x996228 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ???:0
[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #3 from Arnd Bergmann --- After some more analysis, I found that the -Wstringop-overread warning only happens here (and presumably in all the other cases I found) because I disabled -Warray-bounds for gcc-11. I'm still looking at -Warray-bounds to see what has changed here. There were some interesting findings from that one, but the number of added warnings made it hard to keep track of what is going on. It appears that the -Wstringop-overread warnings mostly a subset of those.
[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 --- Comment #10 from Khem Raj --- (In reply to Martin Sebor from comment #9) > Fixed in r11-7658. I validated the fix as well.
[Bug tree-optimization/99580] False positive -Warray-bounds with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99580
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Component|c++ |tree-optimization
Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
||9.2.0
CC||msebor at gcc dot gnu.org
Last reconfirmed||2021-03-14
Blocks||56456
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
Confirmed. The warning first appeared with r238761 AKA "Teach VRP to register
assertions along default switch labels (PR18046)."
A simplified test case is below:
$ cat pr99580.C && -O2 -S -Wall -fdump-tree-vrp1-details pr99580.C
struct vec
{
int operator[] (int i)
{
switch (i) {
default:
case 0: return x;
case 1: return y;
case 2: return z;
}
}
int x, y, z;
};
vec v[3];
int f ()
{
int max_el = v[0][1];
int max_j = 1;
for (int i = 0; i < 3; i++)
for (int j = i + 1; j < 3; j++)
if (v[i][j] > max_el)
max_j = j;
return v[max_j][max_j];
}
pr99580.C: In function ‘int f()’:
pr99580.C:28:17: warning: array subscript 3 is above array bounds of ‘vec [3]’
[-Warray-bounds]
28 | return v[max_j][max_j];
| ~~~^
pr99580.C:16:5: note: while referencing ‘v’
16 | vec v[3];
| ^
$ grep warning pr99580.C.110t.vrp1
Array bound warning for MEM [(struct vec *)&v][max_j_27]
And:
Simulating block 14
extract_range_from_stmt visiting:
max_j_27 = ASSERT_EXPR 1>;
Intersecting
int ~[1, 2] EQUIVALENCES: { max_j_21 } (1 elements)
and
int [1, 2147483646]
to
int [3, 2147483646] EQUIVALENCES: { max_j_21 } (1 elements)
Intersecting
int [3, 2147483646] EQUIVALENCES: { max_j_21 } (1 elements)
and
int VARYING
to
int [3, 2147483646] EQUIVALENCES: { max_j_21 } (1 elements)
Found new range for max_j_27: int [3, 2147483646] EQUIVALENCES: { } (0
elements)
Adding destination of edge (14 -> 17) to worklist
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Martin Sebor changed: What|Removed |Added Component|c |middle-end Keywords||diagnostic --- Comment #4 from Martin Sebor --- Most warnings designed to detect invalid accesses (not just -Wstringop-overread but also -Wstringop-overflow and -Wformat-overflow/-truncation, -Wrestrict, and some forms of -Warray-bounds) use the same underlying code to determine the identity of the accessed object, so they all should trigger if they see a constant address. But I tested the warning with the kernel when I implemented it months ago and don't think I saw any instances of it (though I don't see sharpsl_param in any of my logs). I still don't. How many do you see? Here's the list of -Wstringop- warnings in my fresh build but I'm never sure I use the right target. Is allyesconfig the right one? $ grep Wstringop-over /src/linux-stable/gcc-master.log arch/x86/mm/pgtable.c:437:13: warning: ‘preallocate_pmds.constprop’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] arch/x86/mm/pgtable.c:440:13: warning: ‘preallocate_pmds.constprop’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] arch/x86/mm/pgtable.c:462:9: warning: ‘free_pmds.constprop’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] arch/x86/mm/pgtable.c:455:9: warning: ‘pgd_prepopulate_user_pmd’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] arch/x86/mm/pgtable.c:464:9: warning: ‘free_pmds.constprop’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] drivers/gpu/drm/i915/intel_pm.c:3093:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3058:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3059:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3086:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3087:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3088:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3103:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3104:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/intel_pm.c:3105:9: warning: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Wstringop-overread] drivers/gpu/drm/i915/display/intel_dp.c:4556:22: warning: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Wstringop-overread] The full breakdown with the warnings forcefully disabled in the top-level Makefile re-enabled is below: DiagnosticCount UniqueFiles -Wmissing-prototypes759 248 114 -Wunused-const-variable=391 233 31 -Wformat-truncation=311 297 229 -Wmaybe-uninitialized 158 133 103 -Wunused-but-set-variable 143 137 88 -Warray-bounds 94 32 12 -Wzero-length-bounds 69 66 16 -Wsuggest-attribute=format 60 26 21 -Wnested-externs 4111 -Woverride-init 36 22 15 -Wrestrict 23 14 10 -Wformat-overflow= 20 19 15 -Wempty-body 15 158 -Wstringop-overflow= 1273 -Wmisleading-indentation 1122 -Wcast-function-type 1122 -Wstringop-overread 10 102 -Wenum-conversion
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 Eric Gallager changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||mwoehlke.floss at gmail dot com, ||skvadrik at gmail dot com --- Comment #10 from Eric Gallager --- Redoing some ccs that mysteriously disappeared without being marked as "removed" in the bug history (guessing it was from the server migration)
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #3 from Yongwei Wu --- Is there really a valid use case for a non-lock-free version of 128-bit CAS? I am using it in a lock-free data structure. The GCC-generated code is MUCH slower than the mutex-based version, defeating all its valid purposes. I am talking about a 10x difference. And the Clang-generated code is more than 200x faster in my 8-thread contention test. To me, the current GCC behaviour is not missed optimization. It is pessimization. I am really having a difficult time understanding the rationale of the current design.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #27 from Yongwei Wu --- Anyone can show a valid use case for a non-lock-free version of 128-bit atomic_compare_exchange? I am trying to use it in a data structure intended to be lock-free. I am surprised to find that the C++ std::atomic::compare_exchange_weak does not result in lock-free code for a 128-bit struct intended for ABA-free CAS. As a result, the GCC-generated code is MUCH slower than the mutex-based version in my 8-thread contention test, defeating all its valid purposes. I am talking about a 10x difference. And the Clang-generated code is more than 200x faster in the same test. Friends, being 200x worse in an important use case (lock-free, ABA-free data structures like queues and lists) is not funny at all.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #28 from Yongwei Wu --- OK, somewhat answering myself. I was not aware of the fact that 128-bit atomic read has to be implemented using cmpxchg16b as well, thus defeating some non-CAS usage scenarios. The natural question is: which usage scenario is more significant? Or is there a way to support both? I still think lock-free data structures are too import to ignore.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 --- Comment #5 from Steffen Schuemann --- Thank you for looking into this and sorry for the namespace issue, I was to greedy when deleting the preprocessor parts that switched between my implementation and std::filesystem. First of all, I'm with you in thinking the macOS issue is more of an os problem, but knowing the chances that this gets fixed on Apples side, especially for anything older than Big Sur, I hoped that a fix/workaround on GCC/LLVM side would be a much better chance. Thanks for the changes, I'll try to test macOS later this day. And thank you for pointing out that the situation under Linux is in fact not the same. You are right. Sadly I was fooled to believe it is, while comparing the behavior with my implementation but after some debugging the reason mine iterates through /proc/1/task/1/cwd without an error is actually a bug on my side. So I have to thank you for helping me find that one. So to recap: EPERM issue is indeed macOS only, not Linux!
[Bug c++/99582] New: No intrinsics to access rcl or rcr instruction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582 Bug ID: 99582 Summary: No intrinsics to access rcl or rcr instruction on x86_64 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- How to deal with this? Any compiler patterns to access this instruction?
