[Bug libstdc++/97485] New: std::call_once crashes at runtime on glibc if not linked to libpthread:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
Bug ID: 97485
Summary: std::call_once crashes at runtime on glibc if not
linked to libpthread:
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially bug was reported as a crash of llvm-tblgen tool:
https://bugs.gentoo.org/749162.
Small reproducer:
$ cat a.cc
#include
static std::once_flag of;
static std::recursive_mutex * pm = nullptr;
int main() {
std::call_once(of, []() { pm = new std::recursive_mutex; });
}
$ g++-10.2.0 a.cc -o a -ggdb3 && ./a
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Aborted (core dumped)
$ g++-10.2.0 a.cc -o a -pthread && ./a
All gcc versions are affected (at least 6.5.0 and above).
Backtrace:
"""
Reading symbols from ./a...
(gdb) run
Starting program: /tmp/a
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Program received signal SIGABRT, Aborted.
__GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:49
49return ret;
(gdb) bt
#0 __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x77a1c536 in __GI_abort () at abort.c:79
#2 0x77dad961 in __gnu_cxx::__verbose_terminate_handler ()
at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x77ddcd9a in __cxxabiv1::__terminate (handler=)
at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/libstdc++-v3/libsupc++/eh_terminate.cc:48
#4 0x77ddce05 in std::terminate () at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/libstdc++-v3/libsupc++/eh_terminate.cc:58
#5 0x77ddd098 in __cxxabiv1::__cxa_throw (obj=,
tinfo=0x77f6f948 ,
dest=0x77e0a570 )
at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/libstdc++-v3/libsupc++/eh_throw.cc:95
#6 0x77db0c7f in std::__throw_system_error (__i=-1)
at
/usr/src/debug/sys-devel/gcc-11.0.0_pre/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:89
#7 0x531d in std::call_once >(std::once_flag &,
struct {...} &&) (__once=..., __f=...)
at /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/mutex:743
#8 0x521a in main () at a.cc:7
"""
https://stackoverflow.com/questions/8649828/what-are-the-correct-link-options-to-use-stdthread-in-gcc-under-linux
suggests -pthread has to be used.
Would it be feasible to convert this error as any of:
1. Link-time error that would complain about missing pthread_once symbol.
2. Successful run if libpthread is not present (probably not easy as libpthread
can be loaded dynamically at a later point in program's runtime).
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-10-19 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 Priority|P3 |P1 --- Comment #4 from Martin Liška --- Mine, thanks for the report.
[Bug tree-optimization/97462] ICE in op1_range, at range-op.cc:1580 (-Os and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97462 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- I guess it's fixed.
[Bug libstdc++/97485] std::call_once crashes at runtime on glibc if not linked to libpthread: terminate called after throwing an instance of 'std::system_error': what(): Unknown error -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485 Sergei Trofimovich changed: What|Removed |Added Host||x86_64-pc-linux-gnu --- Comment #1 from Sergei Trofimovich --- $ LANG=C gcc-11.0.0 -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc-11.0.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python --enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.0.0_pre p4, commit 6b55fa29adf4d643e61388bf01a4509b0b041d17' --disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-valgrind-annotations --enable-vtable-verify --without-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20201015 (experimental) (Gentoo 11.0.0_pre p4, commit 6b55fa29adf4d643e61388bf01a4509b0b041d17)
[Bug c/97463] [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97463 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #5 from Richard Biener ---
Hmm, is the TOPN allocation strathegy configurable? I wonder whether we have
to resort to an alternate allocation scheme (mmap/sbrk), avoiding libc? At
least
I don't see a good way to force the gcov allocation to call the libc malloc
rather than a user replacement that is being instrumented. Of course the
instrumentation code could do sth like
if (is_allocated == 0)
{
is_allocated = in_progress;
... = malloc ();
is_allocated = 1;
}
else if (is_allocted == in_progress)
{
topn_mem = &transitional_garbage_space;
}
but of course that's quite some overhead for a small benefit. Maybe it
could be hidden in gcov_malloc.
[Bug tree-optimization/97466] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 Martin Liška changed: What|Removed |Added Known to fail||11.0 Last reconfirmed||2020-10-19 CC||marxin at gcc dot gnu.org Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Known to work||10.2.0 Ever confirmed|0 |1 Summary|ICE in |ICE in |vect_get_and_check_slp_defs |vect_get_and_check_slp_defs |, at tree-vect-slp.c:538|, at tree-vect-slp.c:538 |(at -O3)|(at -O3) since ||r11-3998-g540d5f4f0215e1cd Target Milestone|--- |11.0 --- Comment #2 from Martin Liška --- Started with Richi's r11-3998-g540d5f4f0215e1cd.
[Bug tree-optimization/97467] ICE in verify_range, at value-range.cc:369 (-Os and above) since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||ice-on-valid-code Ever confirmed|0 |1 Known to fail||11.0 Summary|ICE in verify_range, at |ICE in verify_range, at |value-range.cc:369 (-Os and |value-range.cc:369 (-Os and |above) |above) since ||r11-3685-gfcae5121154d1c33 Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Priority|P3 |P1 Last reconfirmed||2020-10-19 --- Comment #1 from Martin Liška --- Thanks for the report, started with r11-3685-gfcae5121154d1c33.
[Bug c++/97468] gcc crashes when using __may_alias__ attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97468 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-19 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's at least as old as 4.8.0.
[Bug tree-optimization/97464] Missed redundant store optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97464 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||rguenth at gcc dot gnu.org Component|c++ |tree-optimization Keywords||alias, missed-optimization Last reconfirmed||2020-10-19 --- Comment #1 from Richard Biener --- In GCCs memory model x and y can still point to the same memory, the only thing that hints at this not being the case is the load from x at the --x; statement but we're eliminating this load (using TBAA) with the store from the ++x statement which means we get to see (at the store elimination phase) int tem = x; y = 1; x = tem; and here the store to x is necessary because x and y may now point to the same storage, each ending lifetime of the int/float object eventually live previously at the location. So yes, before eliminating dead code after eliminating redundancies we could have seen the store is not necessary (actually we still don't use the present load to do so). So, it's a difficult one. And I believe we have a duplicate report somewhere.
[Bug driver/97469] [11 Regression] __attribute__ ((__target__ ("..."))) resets -mcmodel= values, breaks grub compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-19 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Martin Liška --- I'll take a look, we have similar issues with __target__ and __optimize__ attributes.
[Bug tree-optimization/97466] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Summary|ICE in |[11 Regression] ICE in |vect_get_and_check_slp_defs |vect_get_and_check_slp_defs |, at tree-vect-slp.c:538|, at tree-vect-slp.c:538 |(at -O3) since |(at -O3) since |r11-3998-g540d5f4f0215e1cd |r11-3998-g540d5f4f0215e1cd
[Bug tree-optimization/97466] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine.
[Bug libstdc++/97485] std::call_once crashes at runtime on glibc if not linked to libpthread: terminate called after throwing an instance of 'std::system_error': what(): Unknown error -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485
--- Comment #2 from Sergei Trofimovich ---
AFAIU '-1' comes from
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr-posix.h;h=965247602acf11f81c5fa009c7ee48eb55cbacca;hb=HEAD#l696
696 static inline int
697 __gthread_once (__gthread_once_t *__once, void (*__func) (void))
698 {
699 if (__gthread_active_p ())
700 return __gthrw_(pthread_once) (__once, __func);
701 else
702 return -1;
703 }
where '__gthread_active_p ()' returns false:
(gdb) call __gthread_active_p()
$2 = 0
That is defined in
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr-posix.h;h=965247602acf11f81c5fa009c7ee48eb55cbacca;hb=HEAD#l236
236 #ifdef __GLIBC__
237 __gthrw2(__gthrw_(__pthread_key_create),
238 __pthread_key_create,
239 pthread_key_create)
240 # define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create)
241 #elif defined (__BIONIC__)
242 # define GTHR_ACTIVE_PROXY __gthrw_(pthread_create)
243 #else
244 # define GTHR_ACTIVE_PROXY __gthrw_(pthread_cancel)
245 #endif
246
247 static inline int
248 __gthread_active_p (void)
249 {
250 static void *const __gthread_active_ptr
251 = __extension__ (void *) >HR_ACTIVE_PROXY;
252 return __gthread_active_ptr != 0;
253 }
Both of symbols are weak, unbound to libpthread and unversioned (for
non-working case):
$ g++-11.0.0 a.cc -o a && x86_64-pc-linux-gnu-nm -D a | fgrep -i pthread
w __pthread_key_create
w pthread_once
$ g++-11.0.0 a.cc -o a -pthread && x86_64-pc-linux-gnu-nm -D a | fgrep -i
pthread
w __pthread_key_create@@GLIBC_2.2.5
w pthread_once@@GLIBC_2.2.5
[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||10.2.0 Ever confirmed|0 |1 Last reconfirmed||2020-10-19 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Known to fail||11.0 Keywords||ice-on-invalid-code Summary|ICE on using function-like |[11 Regression] ICE on |macro as a non |using function-like macro |function-like macro |as a non function-like ||macro since ||r11-338-g2a0225e47868fbfc --- Comment #1 from Martin Liška --- Confirmed, started with r11-338-g2a0225e47868fbfc.
[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug driver/97469] [11 Regression] __attribute__ ((__target__ ("..."))) resets -mcmodel= values, breaks grub compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug tree-optimization/97472] [11 Regression] Another EVRP problem since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97472 Martin Liška changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P1 Summary|Another EVRP problem|[11 Regression] Another ||EVRP problem since ||r11-3685-gfcae5121154d1c33 Known to work||10.2.0 Last reconfirmed||2020-10-19 Known to fail||11.0 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r11-3685-gfcae5121154d1c33.
[Bug c++/97468] gcc crashes when using __may_alias__ attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97468
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from Richard Biener ---
#1 0x016e9d82 in layout_type (
type=)
at /home/rguenther/src/gcc2/gcc/stor-layout.c:2618
but of course calling layout_type from type_hash_canon is quite fishy as
we'll end up layouting a template_type_parm here ... now, feeding this
to type_hash_canon is fishy as well so the FE should probably not call
any of the attribute handlers on those ...
tree
type_hash_canon (unsigned int hashcode, tree type)
{
type_hash in;
type_hash **loc;
/* The hash table only contains main variants, so ensure that's what we're
being passed. */
gcc_assert (TYPE_MAIN_VARIANT (type) == type);
/* The TYPE_ALIGN field of a type is set by layout_type(), so we
must call that routine before comparing TYPE_ALIGNs. */
layout_type (type);
[Bug target/97469] [11 Regression] __attribute__ ((__target__ ("..."))) resets -mcmodel= values, breaks grub compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|driver |target --- Comment #3 from Jakub Jelinek --- Started with my r11-3183-gba948b37768c99cd8eb9f5b6fbd45fcf4bd15b78
[Bug c/97480] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97480 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-19 Status|UNCONFIRMED |NEW Priority|P3 |P1 Summary|ice in |[11 Regression] ICE in |vect_get_and_check_slp_defs |vect_get_and_check_slp_defs |, at tree-vect-slp.c:538|, at tree-vect-slp.c:538 Ever confirmed|0 |1 Known to work||10.2.0 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |11.0 Known to fail||11.0 --- Comment #2 from Martin Liška --- Very likely dup of PR97466.
[Bug target/97473] Spilled function parameters not aligned properly on multiple non-x86 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97473 Richard Biener changed: What|Removed |Added Component|other |target --- Comment #3 from Richard Biener --- To not disrupt the ABI such parameters have to be copied in the callee to appropriately aligned stack slots or (with disrupting the ABI), passed by reference. I think separate bugs, one for each affected target, are appropriate here.
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #4 from Richard Biener --- I will have a look.
[Bug gcov-profile/97483] [GCOV]gcov: internal compiler error: in handle_cycle, at gcov.c:627 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97483 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-19 Status|UNCONFIRMED |WAITING --- Comment #2 from Martin Liška --- Dunno. I need a test-case or a back-trace. Can you please try the latest GCC release?
[Bug gcov-profile/97483] [GCOV]gcov: internal compiler error: in handle_cycle, at gcov.c:627 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97483 --- Comment #3 from ammy.yi --- We tried latest GCC with a different OS and cannot reproduce this issue.
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
--- Comment #5 from Richard Biener ---
OK, so the issue is that the C++ frontend marks 'this' as restrict which in
turn means that no other pointer can alias it. For foo() GCC computes
:
_1 = MEM[(struct A &)a_7(D) clique 1 base 1].a;
# PT = nonlocal escaped null
_2 = MEM[(struct A &)a_7(D) clique 1 base 1].b;
_3 = MEM[(int &)_2 clique 1 base 0];
_4 = _1 * _3;
MEM[(struct A &)a_7(D) clique 1 base 1].a = _4;
# PT = nonlocal escaped null
_5 = MEM[(struct A &)a_7(D) clique 1 base 1].b;
_9 = MEM[(int &)_5 clique 1 base 0];
return _9;
in particular
a_7(D), points-to NULL, points-to vars: { D.2410 } (nonlocal, restrict)
_5, points-to non-local, points-to escaped, points-to NULL, points-to vars: { }
and thus the load of _9 via _5 does not alias the store via a_7. Basically,
GCC does not consider storage pointed to by a restrict pointer to point to
itself (what the CTOR does - make b refer to its own a).
It's not difficult to fix this - simply amend the constraints:
a = &PARM_NOALIAS(9)
PARM_NOALIAS(9) = &NONLOCAL
also have
PARM_NOALIAS(9) = &PARM_NOALIAS(9)
the question is whether this generally applies to restrict qualified pointers.
In some sense for
A * restrict p;
int *q = p->b;
q is derived from p.
[Bug sanitizer/97478] Cross Build from windows to linux. It looks like the sys/timeb.h header file does not exist in latest glibc any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97478 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-10-19 --- Comment #1 from Martin Liška --- I can confirm that: * We plan to remove the obsolete function ftime, and the header , in a future version of glibc. In this release, the header still exists but calling ftime will cause a compiler warning. All programs should use gettimeofday or clock_gettime instead. Please report bug to upstreal libsanitizer (LLVM project).
[Bug c++/97477] g++ doesn't accept __restrict keyword inside array function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477 Richard Biener changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Richard Biener --- IIRC restrict is not official C++ but I agree it should be accepted.
[Bug tree-optimization/97480] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97480 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Component|c |tree-optimization
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Richard Biener changed: What|Removed |Added Component|c++ |libstdc++ Target||x86_64-MinGW-W64 --- Comment #1 from Richard Biener --- I guess there needs to be a workaround on the windows side?
[Bug tree-optimization/97467] [11 Regression] ICE in verify_range, at value-range.cc:369 (-Os and above) since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467
--- Comment #2 from Aldy Hernandez ---
Ranger can figure out that the RHS operand of a shift is a zero and feeds it to
operator_lshift::op1_range, which then uses it to create a swapped [1,0] range.
Testing the following patch:
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 0efa00186e8..30d2a4d3987 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1579,6 +1579,11 @@ operator_lshift::op1_range (irange &r,
wide_int shift = wi::to_wide (shift_amount);
if (wi::lt_p (shift, 0, SIGNED))
return false;
+ if (shift == 0)
+ {
+ r = lhs;
+ return true;
+ }
// Work completely in unsigned mode to start.
tree utype = type;
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Does Ninja use using namespace std; before including standard headers, or does some mingw header use that?
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #6 from Richard Biener ---
So the C standard isn't explicit here but if I read "based on" as "a pointer
q is based on p if adjusting p changes q" then it's based on. If the
change to q is supposed to be the same as the change to p then this case
wouldn't be covered. Joseph? C testcase:
struct S { int a; int *p; };
int foo (struct S * restrict p)
{
p->a = 1;
p->p->b = 2;
return p->a;
}
int main()
{
struct S s;
s.p = &s.a;
if (foo (&s) != 2)
abort ();
}
so can S->p point to S->a in foo()?
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 --- Comment #7 from Richard Biener --- Created attachment 49397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49397&action=edit fix in points-to analysis So this fix would allow this case (and fix the C++ FEs using of restrict)
[Bug tree-optimization/97466] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 --- Comment #4 from Richard Biener --- *** Bug 97480 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/97480] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97480 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 97466 ***
[Bug tree-optimization/97466] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 --- Comment #5 from Richard Biener --- Meh, I didn't intend to commit this assert ...
[Bug tree-optimization/97486] New: [11 Regression] ICE in vect_create_constant_vectors, at tree-vect-slp.c:4513 since r11-4005-g6c6e0cafa38cee83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97486
Bug ID: 97486
Summary: [11 Regression] ICE in vect_create_constant_vectors,
at tree-vect-slp.c:4513 since
r11-4005-g6c6e0cafa38cee83
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
It's reduced from emacs:
$ cat emacs.i
struct {
int *end_info;
int *fp;
} png_load_body_c;
int *png_set_longjmp_fn();
void setjmp();
void png_load_body() {
int *fp;
int png_ptr, info_ptr, *end_info;
if (!fp)
return;
if (png_ptr) {
info_ptr = 0;
end_info = png_set_longjmp_fn();
}
png_load_body_c.end_info = end_info;
png_load_body_c.fp = fp;
if (png_ptr)
png_set_longjmp_fn();
setjmp(info_ptr);
}
$ gcc emacs.i -c -O3
during GIMPLE pass: slp
emacs.i: In function ‘png_load_body’:
emacs.i:10:6: internal compiler error: in vect_create_constant_vectors, at
tree-vect-slp.c:4513
10 | void png_load_body() {
| ^
0x736046 vect_create_constant_vectors
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4513
0x736046 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5032
0x1045d47 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5041
0x1047a92 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:5299
0x104905d vect_slp_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4046
0x104905d vect_slp_bbs
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4164
0x1049afc vect_slp_function(function*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4215
0x104b76d execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1430
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/97486] [11 Regression] ICE in vect_create_constant_vectors, at tree-vect-slp.c:4513 since r11-4005-g6c6e0cafa38cee83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97486 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||11.0 Last reconfirmed||2020-10-19 Known to work||10.2.0 Priority|P3 |P1 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW
[Bug tree-optimization/97486] [11 Regression] ICE in vect_create_constant_vectors, at tree-vect-slp.c:4513 since r11-4005-g6c6e0cafa38cee83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97486
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
OK, so we insert on the edge 4->5
[local count: 290235635]:
info_ptr_14(ab) = 0;
_16 = png_set_longjmp_fn ();
[local count: 290197324]:
# info_ptr_1(ab) = PHI
png_load_body_c.end_info = _16;
png_load_body_c.fp = fp_9(D);
png_set_longjmp_fn ();
where gimple_find_edge_insert_loc has
/* If the destination has one predecessor which has no PHI nodes,
insert there. Except for the exit block.
The requirement for no PHI nodes could be relaxed. Basically we
would have to examine the PHIs to prove that none of them used
the value set by the statement we want to insert on E. That
hardly seems worth the effort. */
restart:
if (single_pred_p (dest)
&& gimple_seq_empty_p (phi_nodes (dest))
&& dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
{
so the single-arg PHI confuses us here.
So we now either have to restrict the BB region or convince ourselves that
splitting the edge is OK at the above point (I think it is) ...
I'm tending to keep regions small for now.
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #15 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:222f312a773157f53396ba4cb287deb07f84cc34 commit r11-4033-g222f312a773157f53396ba4cb287deb07f84cc34 Author: guojiufu Date: Mon Oct 19 13:48:19 2020 +0800 [PATCH] fold x << (n % C) to x << (n & C-1) if C meets power2 This patch fixes PR66552 which is also as: https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540930.html which requests to optimizes (x shift (n mod C)) to (x shift (n bit_and (C - 1))) when C is a constant and power of two. gcc/ChangeLog 2020-10-19 Li Jia He PR tree-optimization/66552 * match.pd (x << (n % C) -> x << (n & C-1)): New simplification. gcc/testsuite/ChangeLog 2020-10-19 Li Jia He PR tree-optimization/66552 * gcc.dg/pr66552.c: New testcase.
[Bug middle-end/97487] New: [10/11 Regression] ICE in expand_simple_binop, at optabs.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487
Bug ID: 97487
Summary: [10/11 Regression] ICE in expand_simple_binop, at
optabs.c:939
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20201018 snapshot (g:1e70b1a358b6ce3b894f284d88fbb90518d45cc0)
ICEs when compiling the following testcase w/ -O3 --param
max-rtl-if-conversion-unpredictable-cost=0:
long int __attribute__ ((simd))
i1 (long int kt, long int sg)
{
return kt < 0 ? sg : 0;
}
% gcc-11.0.0 -O3 --param max-rtl-if-conversion-unpredictable-cost=0 -c
xaw8sf5n.c
during RTL pass: ce1
xaw8sf5n.c: In function 'i1.simdclone.0':
xaw8sf5n.c:5:1: internal compiler error: in expand_simple_binop, at
optabs.c:939
5 | }
| ^
0x69936d expand_simple_binop(machine_mode, rtx_code, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:939
0x69936d expand_simple_binop(machine_mode, rtx_code, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:934
0xa65578 force_operand(rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/expr.c:7720
0xa3baea copy_to_mode_reg(machine_mode, rtx_def*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/explow.c:629
0xca49bb maybe_legitimize_operand
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:7199
0xca49bb maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:7331
0xca1c09 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:7350
0xca74ad expand_binop_directly
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:1122
0xca5b2f expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/optabs.c:1209
0x17a9183 noce_try_sign_mask
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:2780
0x17a9183 noce_process_if_block
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:3610
0x17a9183 noce_find_if_block
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:4075
0x17a9183 find_if_header
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:4280
0x17a9183 if_convert
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:5413
0x17a92b1 rest_of_handle_if_conversion
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:5478
0x17a92b1 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/ifcvt.c:5518
[Bug tree-optimization/97466] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:95f27849a580ac834d4f51a0642da9671f0a9dee commit r11-4034-g95f27849a580ac834d4f51a0642da9671f0a9dee Author: Richard Biener Date: Mon Oct 19 11:07:36 2020 +0200 tree-optimization/97466 - remove spurious assert This removes an assertion that was supposed to be only for temporary debugging. I've also re-indented the code which I missed as well. 2020-10-19 Richard Biener PR tree-optimization/97466 * tree-vect-slp.c (vect_get_and_check_slp_defs): Remove spurious assert, re-indent.
[Bug tree-optimization/97466] [11 Regression] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3) since r11-3998-g540d5f4f0215e1cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/97467] [11 Regression] ICE in verify_range, at value-range.cc:369 (-Os and above) since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:5b80069c7e65a3ed60ee16deac4a450a9c32efa6 commit r11-4035-g5b80069c7e65a3ed60ee16deac4a450a9c32efa6 Author: Aldy Hernandez Date: Mon Oct 19 09:48:27 2020 +0200 Handle right shifts by zero in range-ops. If the shift amount in operator_lshift::op1_range was zero, an invalid range of [1, 0] was being created. gcc/ChangeLog: PR tree-optimization/97467 * range-op.cc (operator_lshift::op1_range): Handle shifts by 0. gcc/testsuite/ChangeLog: * gcc.dg/pr97467.c: New test.
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 --- Comment #3 from Brecht Sanders --- MinGW is pure C, so it doesn't use: using namespace std; But I do see Ninja doing this before including windows.h. However GCC 10 and older have no issue with this. What changed in GCC 11 to cause the issue?
[Bug tree-optimization/97467] [11 Regression] ICE in verify_range, at value-range.cc:369 (-Os and above) since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Aldy Hernandez --- Fixed.
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 --- Comment #4 from Jakub Jelinek --- (In reply to Brecht Sanders from comment #3) > MinGW is pure C, so it doesn't use: using namespace std; > But I do see Ninja doing this before including windows.h. Then it is Ninja that needs to be fixed. One can use using namespace std;, but better only after including all headers one has no control over, because it significantly affects name lookup. > However GCC 10 and older have no issue with this. > What changed in GCC 11 to cause the issue? GCC 11 defaults to -std=c++17, while GCC 10 defaulted to -std=c++14. I bet it won't compile even with GCC 10 if you use -std=c++17.
[Bug middle-end/97487] [10/11 Regression] ICE in expand_simple_binop, at optabs.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Keywords||openmp
[Bug tree-optimization/97488] New: [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488
Bug ID: 97488
Summary: [11 Regression] ICE: Segmentation fault (in
wi::set_bit_large)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: aldyh at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-11.0.0-alpha20201018 snapshot (g:1e70b1a358b6ce3b894f284d88fbb90518d45cc0)
ICEs when compiling the following testcase w/ -O1 -ftree-vrp:
__int128
ef (__int128 ms)
{
int dh = 129;
int *hj = &dh;
return ms << *hj ? ms : 0;
}
% x86_64-pc-linux-gnu-gcc-11.0.0 -O1 -ftree-vrp -c byj7y5ib.c
during GIMPLE pass: evrp
byj7y5ib.c: In function 'ef':
byj7y5ib.c:8:1: internal compiler error: Segmentation fault
8 | }
| ^
0xdbbd3f crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/toplev.c:330
0x10f9d4d wi::set_bit_large(long*, long const*, unsigned int, unsigned int,
unsigned int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/wide-int.cc:699
0x1834acf wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::result_type wi::set_bit
>(generic_wide_int const&, unsigned int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/wide-int.h:2246
0x1834acf operator_lshift::op1_range(irange&, tree_node*, irange const&, irange
const&) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/range-op.cc:1610
[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #27 from Arseny Solokha --- Is it still an issue?
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Brecht Sanders changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Brecht Sanders --- Yes, you're right, when setting CXXFLAGS="-std=c++17" and building with GCC 10 Ninja also fails to build. I have opened a ticket with Ninja for this, see: https://github.com/ninja-build/ninja/issues/1861
[Bug analyzer/97489] New: [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489
Bug ID: 97489
Summary: [11 Regression] ICE: Segmentation fault (in
ana::supergraph::get_node_for_function_entry(function*
) const)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20201018 snapshot (g:1e70b1a358b6ce3b894f284d88fbb90518d45cc0)
ICEs when compiling the following testcase, extracted from
test/CodeGenCXX/pr34163.cpp from the clang 10.0.1 test suite, w/ -fanalyzer:
struct X {
virtual ~X() {}
virtual void key_function();
};
void X::key_function() {}
% g++-11.0.0 -fanalyzer -c dkuvlwww.cpp
during IPA pass: analyzer
dkuvlwww.cpp:6:25: internal compiler error: Segmentation fault
6 | void X::key_function() {}
| ^
0x1020adf crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/toplev.c:330
0x13aeb92 ana::supergraph::get_node_for_function_entry(function*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/supergraph.h:96
0x13aeb92 ana::function_point::from_function_entry(ana::supergraph const&,
function*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/program-point.cc:215
0x139f36f ana::program_point::from_function_entry(ana::supergraph const&,
function*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/program-point.h:253
0x139f36f ana::exploded_graph::add_function_entry(function*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:1949
0x139fa07 ana::exploded_graph::on_escaped_function(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:3985
0x139fa7b add_any_callbacks
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:2290
0x12ff60a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/tree.c:12001
0x12ff9f1 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/tree.c:12078
0x139f8fa ana::exploded_graph::build_initial_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:2330
0x13a37e0 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:4576
0x13a463c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/engine.cc:4650
0x1397628 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201018/work/gcc-11-20201018/gcc/analyzer/analyzer-pass.cc:84
[Bug tree-optimization/97488] [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-19 Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- Confirmed. The shift amount in operator_lshift::op1_range is > than the precision of the type so the low_bits wrap around. Testing the following: diff --git a/gcc/range-op.cc b/gcc/range-op.cc index 30d2a4d3987..13a0ee37feb 100644 --- a/gcc/range-op.cc +++ b/gcc/range-op.cc @@ -1608,8 +1608,10 @@ operator_lshift::op1_range (irange &r, // This would be [0x42, 0xFC] aka [0110, 1100]. // Ideally we do this for each subrange, but just lump them all for now. - unsigned low_bits = TYPE_PRECISION (utype) - - TREE_INT_CST_LOW (shift_amount); + unsigned saturated_shift_amount = TREE_INT_CST_LOW (shift_amount); + if (saturated_shift_amount > TYPE_PRECISION (utype)) + saturated_shift_amount = TYPE_PRECISION (utype); + unsigned low_bits = TYPE_PRECISION (utype) - saturated_shift_amount; wide_int up_mask = wi::mask (low_bits, true, TYPE_PRECISION (utype)); wide_int new_ub = wi::bit_or (up_mask, r.upper_bound ()); wide_int new_lb = wi::set_bit (r.lower_bound (), low_bits);
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug sanitizer/97490] New: [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
Bug ID: 97490
Summary: [10/11 Regression] false-positive -Wstringop-overflow=
with address sanitizer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Building the Linux kernel with gcc-10.1 or higher shows a couple of warnings in
one file:
drivers/net/wireless/ath/ath9k/dynack.c:209:14: warning: writing 4 bytes into a
region of size 0 [-Wstringop-overflow=]
I manually created a reduced test case:
typedef unsigned int u32;
typedef unsigned short u16;
typedef unsigned char u8;
typedef _Bool bool;
static inline void _ether_addr_copy(u8 *dst, const u8 *src)
{
*(u32 *)dst = *(const u32 *)src;
*(u16 *)(dst + 4) = *(const u16 *)(src + 4);
}
struct _ieee80211_hdr {
u8 addr1[6];
};
struct _haddr_pair {
u8 h_dest[6];
};
struct _ath_dyn_txbuf {
u16 t_rb;
struct _haddr_pair addr[64];
};
struct _ath_dynack {
bool enabled;
struct _ath_dyn_txbuf st_rbf;
};
struct _ath_hw {
int reg_ops;
struct _ath_dynack dynack;
};
void _ath_dynack_sample_tx_ts(struct _ath_hw *ah, struct _ieee80211_hdr *hdr)
{
struct _ath_dynack *da = &ah->dynack;
struct _haddr_pair *addr;
if (!da->enabled)
return;
addr = &da->st_rbf.addr[da->st_rbf.t_rb];
_ether_addr_copy(addr->h_dest, hdr->addr1);
}
$ gcc-10 -O2 -Wall -fsanitize=kernel-address -c dynack.c
test.c: In function '_ath_dynack_sample_tx_ts':
test.c:8:21: warning: writing 4 bytes into a region of size 0
[-Wstringop-overflow=]
8 | *(u32 *)dst = *(const u32 *)src;
| ^~~
test.c:26:14: note: at offset 0 to object 'enabled' with size 1 declared here
26 | bool enabled;
| ^~~
test.c:9:27: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
9 | *(u16 *)(dst + 4) = *(const u16 *)(src + 4);
| ~~^
test.c:26:14: note: at offset 0 to object 'enabled' with size 1 declared here
26 | bool enabled;
| ^~~
See also https://godbolt.org/z/K5jcM8
I checked locally that this happens on all target architectures I tried, but
not with gcc-9. The code in the kernel only produces a warning on architectures
that are assumed to allow unaligned load/store instructions, otherwise a
different ether_addr_copy() function is used.
[Bug tree-optimization/97486] [11 Regression] ICE in vect_create_constant_vectors, at tree-vect-slp.c:4513 since r11-4005-g6c6e0cafa38cee83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97486 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/97486] [11 Regression] ICE in vect_create_constant_vectors, at tree-vect-slp.c:4513 since r11-4005-g6c6e0cafa38cee83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97486 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:361c378dda1f17435ecc364ab246978784df2482 commit r11-4068-g361c378dda1f17435ecc364ab246978784df2482 Author: Richard Biener Date: Mon Oct 19 11:30:46 2020 +0200 tree-optimization/97486 - avoid edge insertion in SLP vectorizing This avoids edge inserting and eventual splitting during BB SLP vectorization for now. 2020-10-19 Richard Biener PR tree-optimization/97486 * tree-vect-slp.c (vect_slp_function): Split after stmts ending a BB. * gcc.dg/vect/bb-slp-pr97486.c: New testcase.
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 --- Comment #7 from Jakub Jelinek --- So, can we use this for anything but modulo 3, or 5, or 17, or 257 (all of those have 2^32 mod N == 2^64 mod N == 2^128 mod N == 1), probably also keyed on the target having corresponding uaddv4_optab handler, normal expansion not being able to handle it and emitting a libcall?
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:
https://gcc.gnu.org/g:634ee90804cae1e08c8e25913288e0ecf0a5ea0a
commit r10-8911-g634ee90804cae1e08c8e25913288e0ecf0a5ea0a
Author: Srinath Parvathaneni
Date: Fri Oct 16 14:53:28 2020 +0100
arm: Fix the warning -mcpu=cortex-m55 conflicting with
-march=armv8.1-m.main (pr97327).
This patch fixes (PR97327) the warning -mcpu=cortex-m55 conflicts with
-march=armv8.1-m.main
for -mfloat-abi=soft by adding the isa_bit_mve_float to clearing FP bit
list.
The following combination are fixed with this patch:
$ cat bug.c
int main(){
return 0;
}
$ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=soft bug.c -c
$ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=soft
-march=armv8.1-m.main+mve bug.c -c
Before this patch for above combinations:
cc1: warning: switch '-mcpu=cortex-m55' conflicts with
'-march=armv8.1-m.main' switch
After this patch for above combinations no warning/errors.
gcc/ChangeLog:
2020-10-16 Srinath Parvathaneni
PR target/97327
* config/arm/arm.c (fp_bitlist): Add isa_bit_mve_float to FP bits
array.
gcc/testsuite/ChangeLog:
PR target/97327
* gcc.target/arm/mve/intrinsics/pr97327.c: New test.
(cherry picked from commit 90042c43a92c452a5f9f3afbfcdad511ea09a54f)
[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug sanitizer/97490] [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 --- Comment #8 from Jakub Jelinek --- And perhaps for other (but constant and not power of two) modulos use that unsigned long long a; a = (n >> 96) * (unsigned long long) (((__uint128_t 1) << 96) % c); a += ((n >> 64) & 0xULL) * (unsigned long long) (((__uint128_t 1) << 64) % c); a += ((n >> 32) & 0xULL) * (unsigned long long) (((__uint128_t 1) << 32) % c); a += (n & 0xULL); return a % c; form? Though, guess it might get quite large because the multiplications by constants can expand again into multiple instructions. And it needs to be careful that the 4 addends don't overflow the 32 bits.
[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |11.0
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 SRINATH PARVATHANENI changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from SRINATH PARVATHANENI --- Committed patches to trunk and GCC-10 branches.
[Bug sanitizer/97490] [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-19 Summary|[10/11 Regression] |[10/11 Regression] |false-positive |false-positive |-Wstringop-overflow= with |-Wstringop-overflow= with |address sanitizer |address sanitizer since ||r10-5451-gef29b12cfbb4979a Ever confirmed|0 |1 Known to fail||10.2.0, 11.0 Status|UNCONFIRMED |NEW Known to work||9.3.0 --- Comment #1 from Martin Liška --- Confirmed, started with Martin's commit.
[Bug middle-end/97487] [10/11 Regression] ICE in expand_simple_binop, at optabs.c:939 since r10-1420-g744fd446c321f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487 Martin Liška changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10/11 Regression] ICE in |expand_simple_binop, at |expand_simple_binop, at |optabs.c:939|optabs.c:939 since ||r10-1420-g744fd446c321f78f Last reconfirmed||2020-10-19 Status|UNCONFIRMED |NEW Known to fail||10.2.0, 11.0 Known to work||9.3.0 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r10-1420-g744fd446c321f78f.
[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-19 Known to work||10.2.0 Summary|[11 Regression] ICE:|[11 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |ana::supergraph::get_node_f |ana::supergraph::get_node_f |or_function_entry(function* |or_function_entry(function* |) const)|) const) since ||r10-5950-g757bf1dff5e8cee3 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Known to fail||11.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-5950-g757bf1dff5e8cee3.
[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928 --- Comment #28 from Richard Biener --- Yes, the original issue is still present.
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 --- Comment #18 from Martin Liška --- (In reply to Fangrui Song from comment #17) > The algorithm is Donald B. Johnson's "Finding all the elementary circuits of > a directed graph" (1975). (Hawick and James's just implemented the same > algorithm by changing the representation of graphs). > > I am wondering why we enumerate every elementary cycle, find the minimum > edge, reduce edge weighs, and repeat the process. I basically taken the original patch submission and finished it. > > What do we lose if we don't use the costly algorithm? (The time complexity > is O(n*e*(c+1)). However, many implementations (Boost and gcov.c) do not use > a hash set for the blocked list, and thus I suspect the actual complexity is > higher). Do we have other low-cost approaches? (e.g. repeatedly finding > strongly connected components and reducing) Do you have a test-case where it is significant? Feel free to provide a patch which can make it faster, I'll appreciate and review it.
[Bug target/96682] Arm: Wrong code generated for MVE with -O1 and above optimization options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96682 SRINATH PARVATHANENI changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from SRINATH PARVATHANENI --- Pushed fix to trunk and gcc-10 branches.
[Bug target/96683] Arm: MVE ACLE intrinsics vst1q_{s8|u8|s16|u16} is not supported by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96683 SRINATH PARVATHANENI changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from SRINATH PARVATHANENI --- Pushed patch to trunk and gcc-10 branch.
[Bug target/96684] arm: MVE intrinsics / __ARM_undef presence in f16 vector max routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96684 SRINATH PARVATHANENI changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from SRINATH PARVATHANENI --- Committed patch to trunk and gcc-10 branch as below. commit 251950d899bc3c18b5775fe9fe20bebbdc8d15cb Author: Joe Ramsay Date: Fri Oct 2 15:28:29 2020 +0100 commit e68d5be766d7b94f2cddb42cc0d62be9039f34e0 Author: Joe Ramsay Date: Fri Oct 2 15:28:29 2020 +0100 arm: Remove coercion from scalar argument to vmin & vmax intrinsics
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #9 from Jakub Jelinek --- -fno-allow-store-data-races is fairly new option, previously it has been --param=allow-store-data-races=0 I have no idea how you've tried to add -save-temps, so can't answer why you get the error. What I was suggesting is build with make V=1 and copy/paste the command line used to compile a particular source file and append -save-temps to those options
[Bug tree-optimization/97488] [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488 --- Comment #2 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:2d2f4ffc97a8510e72a99ee106159aeae2627a42 commit r11-4070-g2d2f4ffc97a8510e72a99ee106159aeae2627a42 Author: Aldy Hernandez Date: Mon Oct 19 06:18:46 2020 -0400 Gracefully handle right shifts larger than the precision. gcc/ChangeLog: PR tree-optimization/97488 * range-op.cc (operator_lshift::op1_range): Handle large right shifts. gcc/testsuite/ChangeLog: * gcc.dg/pr97488.c: New test.
[Bug tree-optimization/97488] [11 Regression] ICE: Segmentation fault (in wi::set_bit_large)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Aldy Hernandez --- fixed
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #10 from Christophe Leroy --- (In reply to Jakub Jelinek from comment #9) > What I was suggesting is build with make V=1 and copy/paste the command line > used to compile a particular source file and append -save-temps to those > options That's exactly what I did, I built with V=1, then I copy/pasted the line and added -save-temps at the end as you see in comment #8
[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #29 from Richard Biener ---
So a testcase for missed outer loop induction SLP (and nested cycle SLP) is
for example
int a[1024];
void foo (unsigned n)
{
for (int i = 0; i < 1020; i += 4)
{
int suma = a[i];
int sumb = a[i+1];
int sumc = a[i+2];
int sumd = a[i+3];
for (unsigned j = 0; j < 17; ++j)
{
suma = (suma ^ i) + 1;
sumb = (sumb ^ i) + 2;
sumc = (sumc ^ i) + 3;
sumd = (sumd ^ i) + 4;
}
a[i] = suma;
a[i+1] = sumb;
a[i+2] = sumc;
a[i+3] = sumd;
}
}
[Bug fortran/97491] New: Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 Bug ID: 97491 Summary: Wrong restriction for VALUE arguments of pure procedures Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- $ cat pure.f90 pure function foo(x) result (ret) integer :: ret integer, value :: x x = x / 2 ret = x end function foo $ gfortran pure.f90 pure.f90:4:2: 4 | x = x / 2 | 1 Error: Variable 'x' cannot appear in a variable definition context (assignment) at (1) in PURE procedure
[Bug libstdc++/97485] std::call_once crashes at runtime on glibc if not linked to libpthread: terminate called after throwing an instance of 'std::system_error': what(): Unknown error -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97485 --- Comment #3 from Jonathan Wakely --- Looks like a dup of PR 55394
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #11 from Christophe Leroy --- Created attachment 49398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49398&action=edit Build of fs/pipe.o
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #12 from Christophe Leroy --- Created attachment 49399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49399&action=edit pipe.s from build of fs/pipe.o fs/pipe.o includes an instance of get_order() allthouth get_order() is declared static and not called from any function.
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #13 from Christophe Leroy --- (In reply to Christophe Leroy from comment #10) > (In reply to Jakub Jelinek from comment #9) > > What I was suggesting is build with make V=1 and copy/paste the command line > > used to compile a particular source file and append -save-temps to those > > options > > That's exactly what I did, I built with V=1, then I copy/pasted the line and > added -save-temps at the end as you see in comment #8 This was a problem with PATH, when I was copying the command line, it was using another (older) version of GCC which was the one in the PATH. Sorry.
[Bug other/97492] New: arm cortex-m0+ or constant value can use adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97492
Bug ID: 97492
Summary: arm cortex-m0+ or constant value can use adds
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: kjetilos at gmail dot com
Target Milestone: ---
Given the following C code the compiler generates code that can be further
optimized.
void write_byte(void)
{
unsigned *regs = (unsigned *) 0x421;
*regs = (*regs & ~0xff) | (0x9 & 0xff);
}
In this code the first byte is cleared and a constant 9 is or'ed into the word.
This is compiled down to these instructions for cortex-m0+.
write_byte:
movsr3, #255
ldr r1, .L2
ldr r2, [r1]
bicsr2, r3
subsr3, r3, #246
orrsr3, r2
str r3, [r1]
bx lr
.L3:
.align 2
.L2:
.word 69271552
In this case where a constant less than 255 is or'ed into the last byte of a
word then the subs + orrs instruction (or sometimes movs + orrs) sequence can
be replaced by a single adds instruction to save 2 bytes.
[Bug c++/97477] g++ doesn't accept __restrict keyword inside array function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477 --- Comment #2 from Dalon Work --- (In reply to Richard Biener from comment #1) > IIRC restrict is not official C++ but I agree it should be accepted. You are correct, it is not official c++. g++ accepts and uses the '__restrict' keyword in c++ to mean approximately the same thing as the 'restrict' keyword in c. Not being a g++ developer, I cannot say to what degree this extension to the c++ language is supported by the g++ compiler, so I'll leave it up to you to decide what to do with this information.
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 --- Comment #23 from Peter Bergner --- (In reply to Richard Biener from comment #22) > OK, so the fix here is quite obviously to simply drop the > build_distinct_type_copy calls: Thanks richi, I'll put the patch through a bootstrap/regtest cycle.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #6 from Martin Liška ---
(In reply to Richard Biener from comment #5)
> Hmm, is the TOPN allocation strathegy configurable? I wonder whether we have
> to resort to an alternate allocation scheme (mmap/sbrk), avoiding libc?
No. The only thing we support is a recursive malloc as seen in:
./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c
It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a
statically allocated buffer when we recursively entry allocate_gcov_kvp.
However this is different as we can't call malloc/calloc from the function as
we're in code that initializes a memory allocator.
We can mitigate the issue with a pair of new functions __gcov_supress_malloc
and __gcov_alloc_malloc that will be called by a custom memory allocator.
What do you think about it?
> At
> least
> I don't see a good way to force the gcov allocation to call the libc malloc
> rather than a user replacement that is being instrumented. Of course the
> instrumentation code could do sth like
>
> if (is_allocated == 0)
> {
> is_allocated = in_progress;
> ... = malloc ();
> is_allocated = 1;
> }
> else if (is_allocted == in_progress)
> {
> topn_mem = &transitional_garbage_space;
> }
>
> but of course that's quite some overhead for a small benefit. Maybe it
> could be hidden in gcov_malloc.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #7 from Jan Hubicka --- > No. The only thing we support is a recursive malloc as seen in: > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c > > It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a > statically allocated buffer when we recursively entry allocate_gcov_kvp. > > However this is different as we can't call malloc/calloc from the function as > we're in code that initializes a memory allocator. > > We can mitigate the issue with a pair of new functions __gcov_supress_malloc > and __gcov_alloc_malloc that will be called by a custom memory allocator. > > What do you think about it? How this works with the llvm implementation (that is very similar here, right?) Honza
Re: [Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
> No. The only thing we support is a recursive malloc as seen in: > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c > > It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a > statically allocated buffer when we recursively entry allocate_gcov_kvp. > > However this is different as we can't call malloc/calloc from the function as > we're in code that initializes a memory allocator. > > We can mitigate the issue with a pair of new functions __gcov_supress_malloc > and __gcov_alloc_malloc that will be called by a custom memory allocator. > > What do you think about it? How this works with the llvm implementation (that is very similar here, right?) Honza
[Bug c/97493] New: generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
Bug ID: 97493
Summary: generate wrong code with "-Os -fno-toplevel-reorder
-frename-registers"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: suochenyao at 163 dot com
Target Milestone: ---
Description:
I think gcc generates wrong code with -Os -fno-toplevel-reorder
-frename-registers.
But no difference is found with optimization levels.
No message and difference occurs with "gcc -Wall -Wextra" and
"-fno-strict-aliasing -fwrapv"
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int printf(const char *, ...);
union uuu{
short a;
long b;
} c={0};
long *d = &c.b;
short *e = &c.a;
short f=0;
int main() {
*d = 3;
f = ++*e;
printf("%d\n", c.a);
}
***
Gcc Version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/suocy/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/home/suocy/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/suocy/bin/gcc-dev
--disable-multilib --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201018 (experimental) (GCC)
***
Command Line:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O0 a.c -o a.out0
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O1 a.c -o a.out1
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O2 a.c -o a.out2
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O3 a.c -o a.out3
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -Os a.c -o a.outs
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -Os -fno-toplevel-reorder
-frename-registers a.c -o a.outf
$ ./a.out0 > out0
$ ./a.out1 > out1
$ ./a.out2 > out2
$ ./a.out3 > out3
$ ./a.outs > outs
$ ./a.outf > outf
$ diff out0 out1
$ diff out0 out2
$ diff out0 out3
$ diff out0 outs
$ diff out0 outf
1c1
< 4
---
> 1
[Bug c/97493] generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- The testcase is invalid. In standard C only one union member may be active at a time, and while GCC as extension allows type puning through unions, the union must be visible in the expressions accessing it, so taking addresses of the union elts and dereferencing them through those pointers where the union is not visible is UB.
[Bug analyzer/97489] [11 Regression] ICE: Segmentation fault (in ana::supergraph::get_node_for_function_entry(function*) const) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks; confirmed, though for me I see the ICE with g:af66094d037793773eb8a49597866457f2f6a104, and do not see the ICE with its predecessor; in particular the backtrace shows add_any_callbacks which I added in that commit. It's crashing on "__dt_comp ", finding the dtor in the vtable when building the initial worklist, here: 96 return get_node_for_block (ENTRY_BLOCK_PTR_FOR_FN (fun)); where fun->cfg is NULL. Working on a fix.
[Bug c++/97388] By-value function parameter changes are rolled back prior to destructor call during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97388 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-10-19 --- Comment #3 from Jakub Jelinek --- Created attachment 49400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49400&action=edit gcc11-pr97388.patch Untested fix.
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #8 from Martin Liška --- (In reply to Jan Hubicka from comment #7) > > No. The only thing we support is a recursive malloc as seen in: > > ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c > > > > It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a > > statically allocated buffer when we recursively entry allocate_gcov_kvp. > > > > However this is different as we can't call malloc/calloc from the function > > as > > we're in code that initializes a memory allocator. > > > > We can mitigate the issue with a pair of new functions __gcov_supress_malloc > > and __gcov_alloc_malloc that will be called by a custom memory allocator. > > > > What do you think about it? > > How this works with the llvm implementation (that is very similar here, > right?) > > Honza They have the very same problem when I disable a statically pre-allocated buffers with -mllvm -vp-static-alloc=0: Program received signal SIGILL, Illegal instruction. 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 103 if (malloc_depth != 0) __builtin_trap(); (gdb) bt #0 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 #1 0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101 #2 0x00401c45 in instrumentTargetValueImpl (CountValue=1, CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146 #3 __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8, CounterIndex=0) at /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232 #4 0x0040148f in malloc_impl (size=56) at pr97461.c:85 #5 0x004013fe in malloc (size=56) at pr97461.c:95 #6 0x77e048a3 in __add_to_environ (name=0x406138 "__LLVM_PROFILE_RT_INIT_ONCE", value=, combined=, replace=) at setenv.c:215 #7 0x00402ce4 in truncateCurrentFile () #8 0x004039bc in parseAndSetFilename () #9 0x00404134 in __llvm_profile_initialize () #10 0x00405e95 in __libc_csu_init (argc=argc@entry=1, argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89 #11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1, argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=, rtld_fini=, stack_end=0x7fffdf98) at ../csu/libc-start.c:270 #12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #9 from Jan Hubicka --- > > They have the very same problem when I disable a statically pre-allocated > buffers with -mllvm -vp-static-alloc=0: > > Program received signal SIGILL, Illegal instruction. > 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 > 103 if (malloc_depth != 0) __builtin_trap(); > (gdb) bt > #0 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 > #1 0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101 > #2 0x00401c45 in instrumentTargetValueImpl (CountValue=1, > CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146 > #3 __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8, > CounterIndex=0) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232 > #4 0x0040148f in malloc_impl (size=56) at pr97461.c:85 > #5 0x004013fe in malloc (size=56) at pr97461.c:95 > #6 0x77e048a3 in __add_to_environ (name=0x406138 > "__LLVM_PROFILE_RT_INIT_ONCE", value=, combined= out>, > replace=) at setenv.c:215 > #7 0x00402ce4 in truncateCurrentFile () > #8 0x004039bc in parseAndSetFilename () > #9 0x00404134 in __llvm_profile_initialize () > #10 0x00405e95 in __libc_csu_init (argc=argc@entry=1, > argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89 > #11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1, > argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=, > rtld_fini=, stack_end=0x7fffdf98) at > ../csu/libc-start.c:270 > #12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120 Hmm, it seems to me that having some entries prealocated by default would be way to avoid this problem in majority cases w/o having to modify the upstream packages. Honza
Re: [Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
> > They have the very same problem when I disable a statically pre-allocated > buffers with -mllvm -vp-static-alloc=0: > > Program received signal SIGILL, Illegal instruction. > 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 > 103 if (malloc_depth != 0) __builtin_trap(); > (gdb) bt > #0 0x004014e6 in calloc (nmemb=1, size=8) at pr97461.c:103 > #1 0x00401ae1 in allocateValueProfileCounters (Data=0x40a2c8) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:101 > #2 0x00401c45 in instrumentTargetValueImpl (CountValue=1, > CounterIndex=0, Data=0x40a2c8, TargetValue=4199264) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:146 > #3 __llvm_profile_instrument_target (TargetValue=4199264, Data=0x40a2c8, > CounterIndex=0) at > /home/marxin/Programming/llvm-project/compiler-rt/lib/profile/InstrProfilingValue.c:232 > #4 0x0040148f in malloc_impl (size=56) at pr97461.c:85 > #5 0x004013fe in malloc (size=56) at pr97461.c:95 > #6 0x77e048a3 in __add_to_environ (name=0x406138 > "__LLVM_PROFILE_RT_INIT_ONCE", value=, combined= out>, > replace=) at setenv.c:215 > #7 0x00402ce4 in truncateCurrentFile () > #8 0x004039bc in parseAndSetFilename () > #9 0x00404134 in __llvm_profile_initialize () > #10 0x00405e95 in __libc_csu_init (argc=argc@entry=1, > argv=argv@entry=0x7fffdfa8, envp=0x7fffdfb8) at elf-init.c:89 > #11 0x77decd9a in __libc_start_main (main=0x401580 , argc=1, > argv=0x7fffdfa8, init=0x405e50 <__libc_csu_init>, fini=, > rtld_fini=, stack_end=0x7fffdf98) at > ../csu/libc-start.c:270 > #12 0x004012aa in _start () at ../sysdeps/x86_64/start.S:120 Hmm, it seems to me that having some entries prealocated by default would be way to avoid this problem in majority cases w/o having to modify the upstream packages. Honza
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #10 from Martin Liška --- > Hmm, it seems to me that having some entries prealocated by default > would be way to avoid this problem in majority cases w/o having to > modify the upstream packages. I tend to the same. I'm going to prepare a patch for it.
[Bug preprocessor/97471] [11 Regression] ICE on using function-like macro as a non function-like macro since r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nathan Sidwell --- Fixed 5abe05b4331 2020-10-19 | preprocessor: Fix non-fn fn-like macro at EOF [PR97471]
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-10-19 Status|UNCONFIRMED |NEW --- Comment #14 from Martin Liška --- All right, I can reproduce it. I'm also attaching x86_64 pre-processes source file.
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #15 from Martin Liška --- Created attachment 49401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49401&action=edit x86_64 pre-processed source file
