[Bug sanitizer/96259] New: Regression warning on GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96259
Bug ID: 96259
Summary: Regression warning on GCC 10
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: freddy77 at gmail dot com
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: ---
I found this issue updating a software from Fedora 31 to Fedora 32. I manage to
reproduce the problem with this main.c file:
struct DataIn {
int type;
int dummy;
};
struct DataOut {
struct DataIn in;
};
void func(struct DataOut *data)
{
if (data->in.type) {
__builtin_memset(&(data->in), 0, sizeof(struct DataIn));
}
}
and using this command line:
gcc -Warray-bounds=2 -Werror -O2 -fsanitize=address -c main.c
this is reporting:
: In function 'void func(DataOut*)':
:15:24: error: 'void* __builtin_memset(void*, int, long unsigned int)'
offset [4, 7] from the object at 'data' is out of the bounds of referenced
subobject 'DataIn::type' with type 'int' at offset 0 [-Werror=array-bounds]
15 |__builtin_memset(&(data->in), 0, sizeof(struct DataIn));
|^~~
:4:8: note: subobject 'DataIn::type' declared here
4 |int type;
|^~~~
cc1plus: all warnings being treated as errors
Compiler returned: 1
I reproduced the issue using https://godbolt.org/ so I verified that this
happens with GCC 10.1 but not with GCC 9.3. It seems related to:
- nested structure
- having a "if" in the code
- "-Warray-bounds=2"
- "-fsanitize=address"
I know "-Warray-bounds=2" could have false positive but it's still a
regression.
[Bug sanitizer/96259] Regression warning on GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96259 --- Comment #1 from Frediano Ziglio --- The commit introducing this regression is: commit 6889a3acfeed47265886676c6d43b04ef799fb82 Author: Martin Sebor Date: Thu Sep 19 22:15:34 2019 + PR middle-end/91631 - buffer overflow into an array member of a declared object not detected ... From-SVN: r275981
[Bug c++/41941] New: bad stack allocation using inline asm
compiling a assembler inline code which use a log of registers and with -O2
option instructions like
movq%rbx, -40(%rsp)
are generated which are wrong cause it writes to not allocated stack which
could lead to corruption on interrupts
code
void foo(const unsigned char *p)
{
unsigned int t0, t1, t2, t3;
__asm__ __volatile__
(
".intel_syntax noprefix;"
"mov r8" ", " "rsi" ";"
"mov r9" ", " "rcx" ";"
".att_syntax prefix;"
: "=a" (t0), "=c" (t1), "=S" (t2), "=D" (t3)
: "D" (p)
: "memory", "cc"
, "%ebx" , "%r8", "%r9", "%r10", "%r11", "%r12" , "%r13", "%r14", "%r15"
);
}
I'll attach source code, generated code and gcc command output
freddy77
--
Summary: bad stack allocation using inline asm
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: freddy77 at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
[Bug c++/41941] bad stack allocation using inline asm
--- Comment #1 from freddy77 at gmail dot com 2009-11-04 15:37 --- Created an attachment (id=18965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18965&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
[Bug c++/41941] bad stack allocation using inline asm
--- Comment #2 from freddy77 at gmail dot com 2009-11-04 15:37 --- Created an attachment (id=18966) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18966&action=view) output assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
[Bug c++/41941] bad stack allocation using inline asm
--- Comment #3 from freddy77 at gmail dot com 2009-11-04 15:37 --- Created an attachment (id=18967) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18967&action=view) gcc command output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
[Bug c++/41941] bad stack allocation using inline asm
--- Comment #4 from freddy77 at gmail dot com 2009-11-04 15:39 --- Oh... I forgot. I used gcc from Ubuntu 9.10 distro either gcc 4.4.1, g++ 4.4.1, gcc 4.3.4 and g++ 4.3.4 have same issue. The issue does not occur using -Os option (which use push instructions) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
[Bug c++/81879] New: Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879
Bug ID: 81879
Summary: Bad compilation of small program if LTO is used
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddy77 at gmail dot com
Target Milestone: ---
Created attachment 41994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41994&action=edit
preprocessed file
Trying to narrow down an issue I cannot compile and run a really small program
like
#include
int main()
{
std::cout << std::endl;
return 0;
}
Trying to compile with
x86_64-w64-mingw32-g++ -flto -O2 -g -pipe -Wall -Werror -Wextra -static
-mconsole -o test.exe test.cpp
It compiles without any warnings but when executed it crashes.
Note that if I remove -flto or -static program run correctly.
>From what Wine reports (but I have a crash even running on Windows directly) it
seems the crash calling do_widen virtual function (null pointer, rax was 0).
I noted different problems with LTO with MinGW, opened also these bugs
- https://bugzilla.redhat.com/show_bug.cgi?id=1475237 (similar to this one)
- https://sourceforge.net/p/mingw/bugs/2346/
- https://bugzilla.redhat.com/show_bug.cgi?id=1455137
I'm using MinGW compiler provided with Fedora 26, specifically:
mingw64-binutils-2.27-2.fc26.x86_64
mingw64-gcc-c++-7.1.0-1.fc26.x86_64
mingw64-headers-5.0.2-1.fc26.noarch
Tried to update binutils (compiler 2.29 version) without success (same crash).
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 --- Comment #1 from Frediano Ziglio --- This is weird. If after the x86_64-w64-mingw32-g++ -flto -O2 -g -save-temps -Wall -Werror -Wextra -static -mconsole -o test.exe test.cpp command I run x86_64-w64-mingw32-g++ -v test.exe.ltrans0.s -static -o test.exe -mconsole the executable I get is able to run. Trying to find some difference between the executables I found that the widen call is different, specifically in one case (the one crashing) do_widen is not generated. Quite weird that in the wrong code %rdx is assigned to a pointer inside a function while in the working case a valid pointer to a function is used. @@ -49312,7 +49312,7 @@ ---: 89 d6 mov%edx,%esi ---: e8 c0 fa ff ff callq 4275e0 ::_M_widen_init() const> ---: 48 8b 03mov(%rbx),%rax : 48 8d 15 46 00 00 00lea0x46(%rip),%rdx# 427b70 ::do_widen(char) const> +---: 48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 427b2a ::widen(char) const [clone .part.23]+0x1a> ---: 48 8b 40 30 mov0x30(%rax),%rax ---: 48 39 d0cmp%rdx,%rax ---: 75 0d jne427b40 ::widen(char) const [clone .part.23]+0x30> @@ -49345,30 +49345,13 @@ ---: 90 nop ---: 90 nop -00427b70 ::do_widen(char) const>: : 89 d0 mov%edx,%eax : c3 retq : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop : 90 nop
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 --- Comment #2 from Frediano Ziglio --- It seems that this do_widen replacement with an invalid pointer goes on and on, looking at differences in the generated executable: -- ---: 00 00 ---: 48 8b 10mov(%rax),%rdx ---: 4c 8b 5a 30 mov0x30(%rdx),%r11 : 48 8d 15 2a 65 ff fflea-0x9ad6(%rip),%rdx# 427b70 ::do_widen(char) const> +---: 48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 431636 > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*) const+0x6e6> ---: 49 39 d3cmp%rdx,%r11 : 0f 84 ba fc ff ff je 431309 > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*) const+0x3a9> -- ---: 48 89 44 24 60 mov%rax,0x60(%rsp) ---: callq ::_M_widen_init() const> ---: 48 8b 44 24 60 mov0x60(%rsp),%rax : 48 8d 0d a2 5f ff fflea-0xa05e(%rip),%rcx# 427b70 ::do_widen(char) const> +---: 48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431bbe > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x23e> ---: 4c 8b 44 24 68 mov0x68(%rsp),%r8 ---: 48 8b 10mov(%rax),%rdx -- ---: 48 89 44 24 48 mov%rax,0x48(%rsp) ---: callq ::_M_widen_init() const> ---: 48 8b 44 24 48 mov0x48(%rsp),%rax : 48 8d 0d e7 5c ff fflea-0xa319(%rip),%rcx# 427b70 ::do_widen(char) const> +---: 48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431e79 > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x1d9> ---: 48 8b 10mov(%rax),%rdx ---: 4c 8b 42 30 mov0x30(%rdx),%r8 -- ---: 44 0f b6 54 24 6f movzbl 0x6f(%rsp),%r10d ---: 48 8b 10mov(%rax),%rdx ---: 4c 8b 5a 30 mov0x30(%rdx),%r11 : 48 8d 15 ef eb fc fflea-0x31411(%rip),%rdx# 427b70 ::do_widen(char) const> +---: 48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 458f71 > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*) const+0x6d1> ---: 49 39 d3cmp%rdx,%r11 : 0f 84 d2 fb ff ff je 458b5c > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*) const+0x2ac> -- ---: 48 89 44 24 58 mov%rax,0x58(%rsp) ---: callq ::_M_widen_init() const> ---: 48 8b 44 24 58 mov0x58(%rsp),%rax : 48 8d 0d f5 e7 fc fflea-0x3180b(%rip),%rcx# 427b70 ::do_widen(char) const> +---: 48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 45936b > >::get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x1eb> ---: 48 8b 10mov(%rax),%rdx ---: 4c 8b 42 30 mov0x30(%rdx),%r8 -- ---: 48 89 44 24 48 mov%rax,0x48(%rsp) ---: callq ::_M_widen_init() const> ---: 48 8b 44 24 48 mov0x48(%rsp),%rax : 48 8d 0d 97 e5 fc fflea-0x31a69(%rip),%rcx# 427b70 ::do_widen(char) const> +---: 48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 4595c9 > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x1d9> ---: 48 8b 10mov(%rax),%rdx ---: 4c 8b 42 30 mov0x30(%rdx),%r8 -- ---: 48 89 d9mov%rbx,%rcx ---: callq ::_M_widen_init() const> ---: 48 8b 03mov(%rbx),%rax : 48 8d 15 ea a9 fc fflea-0x35616(%rip),%rdx# 427b70 ::do_widen(char) const> +---: 48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 45d176 > >::do_put(std::ostreambuf_iterator >, std::ios_base&, char, tm const*, char, char) const+0x146> ---: 4c 8b 40 30 mov0x30(%rax),%r8 ---: b8 25 00 00 00 mov$0x25,%eax -- ---: 48 89 f1mov%rsi,%rcx ---: callq ::_M_widen_init() const> ---: 48 8b 06mov(%rsi),%rax : 48 8d 15 ce a5 fc fflea-0x35a32(%rip),%rdx# 427b70 ::do_widen(char) const> +---: 48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 45d592 >::fill() const+0x62> ---: 4c 8b 40 30 mov0x30(%rax),%r8 ---: b8 20 00 00 00 mov$0x20,%eax -- ---: callq ::_M_widen_init() const> ---: 48 8b 03mov(%rbx),%rax ---: 8b 54 24 2c mov0x2c(%rsp),%edx : 48 8d 0d 41 a5 fc ff
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 --- Comment #3 from Frediano Ziglio --- I noted that during the link the resolution file using -static or not is different without -static 750 6dacea834fb099d1 PREVAILING_DEF_IRONLY _ZNKSt5ctypeIcE8do_widenEc 753 6dacea834fb099d1 PREVAILING_DEF main 738 6dacea834fb099d1 RESOLVED_EXEC _ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc 743 6dacea834fb099d1 RESOLVED_EXEC _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ 797 6dacea834fb099d1 UNDEF _ZSt4cout 761 6dacea834fb099d1 RESOLVED_EXEC _ZNSt8ios_base4InitD1Ev 766 6dacea834fb099d1 RESOLVED_EXEC _ZNKSt5ctypeIcE13_M_widen_initEv 771 6dacea834fb099d1 RESOLVED_EXEC _ZSt16__throw_bad_castv 776 6dacea834fb099d1 RESOLVED_EXEC _ZNSo5flushEv 782 6dacea834fb099d1 RESOLVED_EXEC _ZNSo3putEc 788 6dacea834fb099d1 RESOLVED_EXEC atexit 791 6dacea834fb099d1 RESOLVED_EXEC _ZNSt8ios_base4InitC1Ev with -static 750 1b64a3a32ab1e36a PREEMPTED_REG _ZNKSt5ctypeIcE8do_widenEc 753 1b64a3a32ab1e36a PREVAILING_DEF main 738 1b64a3a32ab1e36a RESOLVED_EXEC _ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc 743 1b64a3a32ab1e36a RESOLVED_EXEC _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ 797 1b64a3a32ab1e36a RESOLVED_EXEC _ZSt4cout 761 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSt8ios_base4InitD1Ev 766 1b64a3a32ab1e36a RESOLVED_EXEC _ZNKSt5ctypeIcE13_M_widen_initEv 771 1b64a3a32ab1e36a RESOLVED_EXEC _ZSt16__throw_bad_castv 776 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSo5flushEv 782 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSo3putEc 788 1b64a3a32ab1e36a RESOLVED_EXEC atexit 791 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSt8ios_base4InitC1Ev Specifically the _ZNKSt5ctypeIcE8do_widenEc (our missing function) in the failing case is PREEMPTED_REG while with the successful one is PREVAILING_DEF_IRONLY.
[Bug c/69319] New: Suspect compiler bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69319 Bug ID: 69319 Summary: Suspect compiler bug Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: freddy77 at gmail dot com Target Milestone: --- Created attachment 37374 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37374&action=edit test program, single C file with only system includes Hi, I found a strange problem with optimized code. The code uses an hand written dynamic double linked list (circular). There are some trick to make see the list as an item of the list. After some work I manage to get a small test program. I don't really understand why this specific code crash. Trying to read the assembly code (x86_64) looks like the compiler is assuming some value on first iteration of the a "check" loop causing an assertion to fail. I tested the program with Ubuntu 15.10 compiler (5.2.1) and a Fedora 22 (5.3.1), all x86_64. Test program is really small. I manage to get a single C file only with system includes.
[Bug c/69319] Suspect compiler bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69319 --- Comment #1 from Frediano Ziglio --- Created attachment 37375 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37375&action=edit .i file of the single source program
[Bug c/69319] Suspect compiler bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69319 --- Comment #3 from Frediano Ziglio --- Created attachment 37376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37376&action=edit original file split into pure C + main I don't know if may help (I hope so). I split the file into a pure C (no extra include beside a member.h that does not include anything) and a main.c file which just include some standard header. Included the small Makefile and the .i file for member.c. The options are just "-Wall -Wstrict-aliasing -O2 -Wextra", no warning are produced. Note: removing the noreturn attribute or the malloc attribute make the program work correctly. I suspect is some aliasing problem (perhaps I don't consider something and is just my fault).
[Bug c/69319] Suspect compiler bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69319 --- Comment #4 from Frediano Ziglio --- -O0, -O1 or -fno-strict-aliasing all works. But I don't understand how gcc can generate such code. What am I missing?
[Bug c/112409] New: Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
Bug ID: 112409
Summary: Structure is not initialized as expected
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddy77 at gmail dot com
Target Milestone: ---
I was writing a small network utility till I found a weird behaviour computing
TCP checksums. After some debugging I found that the error disappeared with
either -O1 or -O0. So I reduced the program, trying using multiple GCC versions
and it kept happening.
The final program (stripped down) is:
typedef long unsigned int size_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
#define ntohs __builtin_bswap16
#define htonl __builtin_bswap32
static inline unsigned
reduce_cksum(unsigned sum)
{
return (sum >> 16) + (sum & 0xu);
}
static unsigned
cksum(const void *pkt, size_t len, unsigned int start)
{
const uint16_t *data = (const uint16_t *) pkt;
unsigned sum = start;
for (; len >= 2; len -= 2)
sum += *data++;
if (len)
sum += ntohs(*((const uint8_t *)data) << 8);
sum = reduce_cksum(sum);
sum = reduce_cksum(sum);
return sum;
}
static unsigned
tcpdump_flow_new(uint32_t saddr, uint32_t daddr)
{
struct {
uint32_t saddr, daddr;
uint8_t zero, proto;
} pseudo = { htonl(saddr), htonl(daddr), 0, 6 };
return cksum(&pseudo, 10, 0);
}
int main(void)
{
unsigned res = tcpdump_flow_new(0x01020304, 0xa1b2c3d4);
return res;
}
Using -O2 option and Compiler Explorer (but I tried multiple versions locally)
produced this:
main:
xor edx, edx
lea rax, [rsp-12]
lea rsi, [rsp-2]
.L2:
movzx ecx, WORD PTR [rax]
add rax, 2
add edx, ecx
cmp rax, rsi
jne .L2
mov eax, edx
movzx edx, dx
shr eax, 16
add edx, eax
mov eax, edx
movzx edx, dx
shr eax, 16
add eax, edx
ret
It's easy to spot that the constants disappeared from the code and program uses
not initialized memory.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Frediano Ziglio changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Frediano Ziglio --- But the pointer "passes" through a "void*" conversion, so there should be no aliasing. Or am I missing something? So what's the standard C way to avoid this (without using specific compiler options) ?
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 --- Comment #7 from Frediano Ziglio --- Sorry for the noise, thanks for the informations. I didn't notice banner on top. I went back and I notice it, pretty small and it looks like a lot of other website banners for technical disruptions or cookies.
