[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288 Christian Prochaska changed: What|Removed |Added CC||christian.prochaska@genode- ||labs.com --- Comment #13 from Christian Prochaska --- I found the "Register non-null side effects properly." commit with git bisect while debugging a page fault in the Genode OS framework built with GCC 12.2.0. It turned out that a null pointer check which was present before this commit is now not present anymore. The C++ code with the null pointer check can be found on GitHub: https://github.com/genodelabs/genode/blob/a84af9a9606450471b8038a35f9b55057efa0850/repos/base-nova/src/lib/base/ipc.cc#L71 This is the implementation of the 'Thread::myself()' function which returns a null pointer in some conditions: https://github.com/genodelabs/genode/blob/a84af9a9606450471b8038a35f9b55057efa0850/repos/base/src/lib/base/thread_myself.cc#L22 I compared the disassembled code from objdump and this part is missing when the commit is applied: Genode::ipc_call(Genode::Native_capability, Genode::Msgbuf_base&, Genode::Msgbuf_base&, unsigned long): /.../repos/base-nova/src/lib/base/ipc.cc:71 addr_t const manual_rcv_sel = myself ? myself->native_thread().client_rcv_sel 85f78: 48 83 bd 50 ff ff ffcmpq $0x0,-0xb0(%rbp) 85f7f: 00 85f80: 48 c7 c3 ff ff ff ffmov$0x,%rbx 85f87: 74 1d je 85fa6
[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288 --- Comment #16 from Christian Prochaska --- (In reply to Andrew Pinski from comment #14) > > There was a deferencing of myself before: > Nova::Utcb &utcb = *(Nova::Utcb *)myself->utcb(); I see. The 'Thread::utcb()' function handles the null pointer case internally with a 'this == 0' check and a local '-fno-delete-null-pointer-checks' attribute: https://github.com/genodelabs/genode/blob/a84af9a9606450471b8038a35f9b55057efa0850/repos/base-nova/src/lib/base/stack.cc#L110 So, the elimination of the 'myself' null pointer check is basically a result of undefined behavior with the 'Thread::utcb()' function?
[Bug c++/100918] [10 Regression] Naming a destructor as a qualified template-id results in bogus access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
Christian Prochaska changed:
What|Removed |Added
CC||christian.prochaska@genode-
||labs.com
--- Comment #7 from Christian Prochaska
---
Since the commit above the following test fails. Is this correct?
class T1 { };
class T2 { };
template
class A { };
class B : A { };
class C : B
{
class D : A { };
};
test.cc:11:19: error: ‘class A A::A’ is private within this context
11 | class D : A { };
| ^
test.cc:7:7: note: declared private here
7 | class B : A { };
| ^
When class B is left out, the error does not occur:
class T1 { };
class T2 { };
template
class A { };
class C : A
{
class D : A { };
};
[Bug c++/109804] New: internal compiler error in gimple-ssa-warn-access.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Bug ID: 109804
Summary: internal compiler error in gimple-ssa-warn-access.cc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.procha...@genode-labs.com
Target Milestone: ---
Created attachment 55042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55042&action=edit
output from -freport-bug
during GIMPLE pass: waccess
test.cc: In function ‘T* Genode::construct_at(void*, ARGS&& ...) [with T = B;
ARGS = {C::C()::&}]’:
test.cc:37:19: internal compiler error: Segmentation fault
37 | static inline T * Genode::construct_at(void *at, ARGS &&... args)
| ^~
0xe67c7f crash_signal
../../gcc/toplev.cc:314
0xbb2320 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1626
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb23b9 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1724
0xbb7720 new_delete_mismatch_p
../../gcc/gimple-ssa-warn-access.cc:1763
0xbb7720 matching_alloc_calls_p
../../gcc/gimple-ssa-warn-access.cc:1786
0xbbf214 matching_alloc_calls_p
../../gcc/gimple-ssa-warn-access.cc:1984
0xbbf214 maybe_check_dealloc_call
../../gcc/gimple-ssa-warn-access.cc:3757
0xbbf214 check_call
../../gcc/gimple-ssa-warn-access.cc:4367
0xbbf214 check_block
../../gcc/gimple-ssa-warn-access.cc:
0xbbf214 execute
../../gcc/gimple-ssa-warn-access.cc:4766
[Bug c++/109804] internal compiler error in gimple-ssa-warn-access.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804 --- Comment #1 from Christian Prochaska --- Created attachment 55043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55043&action=edit test.cc
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #7 from Christian Prochaska --- Bug 57440 solved the problem for mingw32 by defining _GTHREAD_USE_MUTEX_INIT_FUNC in os_defines.h.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #10 from Christian Prochaska --- std::__condvar always calls __gthread_cond_destroy() even if __GTHREAD_COND_INIT is used. So, it's handled differently there than in std::__mutex_base.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 Christian Prochaska changed: What|Removed |Added CC||christian.prochaska@genode- ||labs.com --- Comment #6 from Christian Prochaska --- I found the same problem with the Genode OS framework, which allocates memory in 'pthread_mutex_lock()' as well. Has this been resolved for FreeBSD in the meantime?
