[Bug libstdc++/90442] New: std::pmr::new_delete_resource->allocate results in UBSan error member call on address ... which does not point to an object of type 'memory_resource'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90442
Bug ID: 90442
Summary: std::pmr::new_delete_resource->allocate results in
UBSan error member call on address ... which does not
point to an object of type 'memory_resource'
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: laurynas.biveinis at gmail dot com
Target Milestone: ---
Created attachment 46344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46344&action=edit
Preprocessed testcase
The following results in an UBSan error:
#include
int main(void) {
auto * const mem = std::pmr::new_delete_resource()->allocate(10);
}
compiled with g++-9 pmr_san.cpp -fsanitize=undefined -std=c++17 -o pmr_san
results in
../gcc-9/pmr_san2.cpp:4:63: runtime error: member call on address
0x00010752d440 which does not point to an object of type 'memory_resource'
0x00010752d440: note: object is of type '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
01 00 00 00 c8 7e 51 07 01 00 00 00 00 00 00 00 00 00 00 00 e0 ee 50 07 01
00 00 00 98 ee 50 07
^~~
vptr for '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
/usr/local/Cellar/gcc/9.1.0/include/c++/9.1.0/memory_resource:99:25: runtime
error: member call on address 0x00010752d440 which does not point to an object
of type 'memory_resource'
0x00010752d440: note: object is of type '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
01 00 00 00 c8 7e 51 07 01 00 00 00 00 00 00 00 00 00 00 00 e0 ee 50 07 01
00 00 00 98 ee 50 07
^~~
vptr for '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
I am not sure whether this is a libstdc++ or UBSan bug (or if I am doing
something wrong). I am attaching a preprocessed version too.
This looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963,
triggered by Boost implementation of PMR.
[Bug middle-end/77673] New: 4-byte load generated instead of 1-byte load, possibly reading past the end of object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673
Bug ID: 77673
Summary: 4-byte load generated instead of 1-byte load, possibly
reading past the end of object
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: laurynas.biveinis at gmail dot com
Target Milestone: ---
For the following function
void mach_parse_compressed(unsigned char* ptr, unsigned long int* val)
{
if (ptr[0] < 0xC0U) {
*val = ptr[0] + ptr[1];
return;
}
*val = ((unsigned long int)(ptr[0]) << 24)
| ((unsigned long int)(ptr[1]) << 16)
| ((unsigned long int)(ptr[2]) << 8)
| ptr[3];
}
starting with GCC 5.1, with -O2 -fPIC, the following is generated on x86_64:
mach_parse_compressed(unsigned char*, unsigned long*):
movl(%rdi), %eax <--- this load is not safe before branching
bswap %eax
movl%eax, %edx
movzbl (%rdi), %eax
cmpb$-65, %al
jbe .L5
movl%edx, %eax
movq%rax, (%rsi)
ret
.L5:
movzbl 1(%rdi), %edx
addl%edx, %eax
cltq
movq%rax, (%rsi)
ret
"movl(%rdi), %eax" loads all of ptr[0]..ptr[3] even though before we
compare ptr[0] with 0xC0U, we don't know whether we can assume that
ptr[1]..ptr[3] does not point past the end of an object.
GCC 5.1/5.2/5.3/5.4/6.1/6.2 are all affected. Versions 4.7, 4.8, 4.9 are not. I
have checked this using Ubuntu GCC build and http://gcc.godbolt.org/. If
necessary, I can build GCC from pristine .tar.gz and re-test.
[Bug middle-end/77673] 4-byte load generated instead of 1-byte load, possibly reading past the end of object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673 Laurynas Biveinis changed: What|Removed |Added CC||laurynas.biveinis at gmail dot com --- Comment #1 from Laurynas Biveinis --- Created attachment 39663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39663&action=edit Test program containing the function for Valgrind/ASan/memory protection errors A test program for Linux to show the various ASan/Valgrind/SIGSEGV error this bug produces.
[Bug middle-end/102829] New: Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829
Bug ID: 102829
Summary: Redundant null check after atomic load from that
address
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: laurynas.biveinis at gmail dot com
Target Milestone: ---
The following source code
struct d {
long b;
d *e() {
__atomic_load_n(&b, 0);
return this;
}
};
d *j;
void i();
void k() {
auto l = j->e();
if (l)
i();
}
produces the following bit of assembly with -O3 on x86_64
(https://godbolt.org/z/G1ThvnMWP):
...
mov rdx, QWORD PTR [rax]
testrax, rax
je .L1
...
It first dereferences the address at RAX, and later checks whether RAX == 0.
Since we already tried accessing memory at that address, the nullptr check
seems redundant. Moreover, since the address happens to be of 'this' of
variable j, it being equal to nullptr is UB anyway and may be assumed to be !=
nullptr?
Clang tests show the redundant test being present up to version 11 inclusive
(https://godbolt.org/z/rT3ha4enb) and absent from version 12 onwards
(https://godbolt.org/z/Gfb9EWMfq)
[Bug tree-optimization/102829] Redundant null check after atomic load from that address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102829 --- Comment #2 from Laurynas Biveinis --- FWIW adding "if (this == nullptr) __builtin_unreachable();" between __atomic_load_n and return fails to workaround this issue
