[Bug tree-optimization/94675] [9/10/11/12 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #21 from Xavier --- The problem still happens with gcc 9.4.0 but it appears to be fixed with gcc 10.
[Bug c/100410] [10 regression] optimization bug with -O3 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100410 --- Comment #2 from Xavier --- It looks like it's already fixed in 10.3 and 11.1 : https://godbolt.org/z/W98edbPEx Do you confirm the code is correct, and it was a bug of 10.1 and 10.2 only ?
[Bug c/100410] New: [10 regression] optimization bug with -O3 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100410 Bug ID: 100410 Summary: [10 regression] optimization bug with -O3 -fno-strict-aliasing Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chantry.xavier at gmail dot com Target Milestone: --- Created attachment 50746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50746=edit testcase We have a bug in our lzo decompressing code when switching to Debian 11 (still not released) which has gcc version 10.2.1 20210110 We use -O2 and several optim flags from -O3. The code worked well with all previous versions of gcc, including gcc version 9.3.0. It also works with several versions of clang. I am attaching a testcase that seems to reproduce the problem. Compile with gcc -O3 -fno-strict-aliasing -Wall testcase.c % gcc -O2 -fno-strict-aliasing -Wall testcase.c % ./a.out 15 40 `aaa` % gcc -O3 -fno-strict-aliasing -Wall testcase.c % ./a.out 15 40 `aa` % valgrind ./a.out 15 40 ==321763== Memcheck, a memory error detector ==321763== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==321763== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==321763== Command: ./a.out 15 40 ==321763== ==321763== Conditional jump or move depends on uninitialised value(s) ==321763==at 0x483BC98: strlen (vg_replace_strmem.c:459) ==321763==by 0x48CDF75: __vfprintf_internal (vfprintf-internal.c:1688) ==321763==by 0x48B8D9A: printf (printf.c:33) ==321763==by 0x1091E3: main (in /home/xavier/dev/master/platform/lib-common/tests/a.out) ==321763== Uninitialised value was created by a stack allocation ==321763==at 0x109086: main (in /home/xavier/dev/master/platform/lib-common/tests/a.out) ==321763== `aa` Using -fno-strict-aliasing does not seem to have an impact, but since this code violates the strict aliasing rule, maybe it has something to do with it ? I do not fully understand the generated assembly but I see a difference here. This might be the condition to enable the copy by block of 16 bytes with movdqa / movups ? -- 0x10c3 <+83>:>---mov%rax,%r8 -- 0x10c6 <+86>:>---lea(%rax,%rbp,1),%rdx -- 0x10ca <+90>:>---cmp$0x7,%r12d -- 0x10ce <+94>:>---jbe0x11a5 -- 0x10d4 <+100>:>--lea-0x8(%r12),%ecx -- 0x10d9 <+105>:>--cmp$0x1f,%ecx -- 0x10dc <+108>:>--jbe0x118c -- 0x10e2 <+114>:>--cmp$0x8,%rbp -- 0x10e6 <+118>:>--je 0x118c
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #18 from Xavier --- The lib has been recently opensourced so I can share it : https://github.com/Intersec/lib-common/blob/master/src/core/str-stream.h We have 100-200 usages of p_end/s_end/b_end so even if it's possible to patch them all, I am not a big fan of this solution.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #16 from Xavier --- (In reply to Martin Sebor from comment #14) > That said and codegen improvements aside, I think the submitted test case is > sufficiently tricky that I don't see issuing a warning for it as a problem. > All flow-based warnings have a non-zero rate of false positives (as do many > front-end warnings) and there are mechanisms to avoid them. Compared to > some of the other false positives we have, avoiding this one seems like a > low priority to me. Well is there a workaround ? Or do you suggest using pragma ignore ?
[Bug tree-optimization/94675] [9 regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #2 from Xavier --- Note that in our code, we are not even dereferencing the pointer, it's just ps->s += len. And since we always keep a pointer right after the array (p_end / s_end), won't that be a source of problems for Warray-bounds ?
[Bug tree-optimization/94675] New: [9 regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Bug ID: 94675
Summary: [9 regression] -Warray-bounds false positive with -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chantry.xavier at gmail dot com
Target Milestone: ---
Created attachment 48319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48319=edit
test case
Tested with gcc 9.1 9.2 and 9.3 on godbolt.
Compiling with "-O2 -Warray-bounds" gives the following false positive :
---
: In function 'f':
:38:11: warning: array subscript 7 is outside array bounds of 'byte[1]'
{aka 'unsigned char[1]'} [-Warray-bounds]
38 | ps->s += len;
| ^~
:46:6: note: while referencing 'c'
46 | byte c;
| ^
Compiler returned: 0
---
Error also with -O3 but not with -O.
Note that the error goes after removing the assert.
[Bug c++/89729] [g++ 8] -Wclass-memaccess warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89729 --- Comment #3 from Xavier --- (In reply to Martin Sebor from comment #1) Thanks a lot for the detailed explanation, it's much clearer now. Wclass-memaccess does look sane. script_data_t is apparently manipulated from both C and C++ code, which might explain why it's done this way. We can either disable the warning in this case or use a (void *) so no problem. (In reply to Jonathan Wakely from comment #2) > You should use the gcc-help mailing list for questions like this, because > you're not reporting a bug. You're right, sorry about that.
[Bug c++/89729] New: [g++ 8] -Wclass-memaccess warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89729
Bug ID: 89729
Summary: [g++ 8] -Wclass-memaccess warning
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chantry.xavier at gmail dot com
Target Milestone: ---
Created attachment 45975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45975=edit
test case
There are already many bugs about this one, but since I am not expert on C++, I
would like to have your advice.
g++ -std=gnu++98 -c -Wall memaccess-short.cc
memaccess-short.cc: In function ‘void script_data_init_empty(script_data_t*)’:
memaccess-short.cc:14:61: warning: ‘void* memset(void*, int, size_t)’ clearing
an object of type ‘script_data_t’ {aka ‘struct script_data_t’} with no trivial
copy-assignment; use value-initialization instead [-Wclass-memaccess]
({ (typeof(*(p)) *)memset((p), 0, sizeof(*(p)) * (count)); })
^
memaccess-short.cc:19:5: note: in expansion of macro ‘p_clear’
p_clear(, 1);
^~~
memaccess-short.cc:4:16: note: ‘script_data_t’ {aka ‘struct script_data_t’}
declared here
typedef struct script_data_t {
^
memaccess-short.cc:20:33: warning: ‘void* memcpy(void*, const void*, size_t)’
writing to an object of type ‘script_data_t’ {aka ‘struct script_data_t’} with
no trivial copy-assignment [-Wclass-memaccess]
memcpy(data, , sizeof(d2));
^
memaccess-short.cc:4:16: note: ‘script_data_t’ {aka ‘struct script_data_t’}
declared here
typedef struct script_data_t {
^
I know this is a mix of C and C++ code so not very clean.
What's the correct way in gnu++98 to do this ?
p_clear is in a C header, but I can either write a variant for C++ (using
ifdef), or maybe even directly replace the p_clear calls from C++ files.
The other bugs mention cast to void * as a workaround, this does seem to work,
even with a simple C cast. Is this also acceptable in my case for both memset
and memcpy ?
[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722
--- Comment #9 from Xavier ---
We are compiling with -std=gnu++98 so decltype is not available there.
And the "+ 0" trick does not seem to work correctly.
% cat toto.c
#include
int main(void) {
char data[128];
printf("%ju\n", sizeof(typeof(*data)));
printf("%ju\n", sizeof(typeof(*data + 0)));
printf("%ju\n", sizeof(typeof((*data) + 0)));
return 0;
}
% ./a.out
1
4
4
Do you have a solution that works with -std=gnu++98 ?
[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722 --- Comment #4 from Xavier --- Arf I did not understand this was a const problem. Maybe the warning could be a bit clearer ? :) I confirm that it works fine with typeof(*(bits) + 0). This code is in a header shared between C and C++, and actually our codebase is mostly C, so for now it's probably not worth rewriting all our macros with a C++ version. Thanks for the explanation, and for the workaround !
[Bug c++/89722] New: [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722 Bug ID: 89722 Summary: [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers] Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chantry.xavier at gmail dot com Target Milestone: --- Created attachment 45970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45970=edit test case Using g++ (GCC) 8.3.1 20190228. g++ -Wall -Wextra tstbit-short.cc 2019-03-14 21:23:33 xavier pts/3 tstbit-short.cc: In function ‘int desc_contains(const desc_t*, char)’: tstbit-short.cc:7:41: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers] #define BITMASK_NTH(type_t, n) ((type_t)1 << ((n) & (bitsizeof(type_t) - 1))) ^ tstbit-short.cc:10:41: note: in expansion of macro ‘BITMASK_NTH’ ((bits)[(unsigned)(n) / (shift)] op BITMASK_NTH(typeof(*(bits)), n)) ^~~ tstbit-short.cc:11:29: note: in expansion of macro ‘OP_BIT’ #define TST_BIT(bits, n)OP_BIT(bits, n, bitsizeof(*(bits)), & ) ^~ tstbit-short.cc:19:12: note: in expansion of macro ‘TST_BIT’ return TST_BIT(d->tab, b); ^~~ This does not seem to occur with gcc, nor with g++ <= 7. I could not find a workaround. Clearly I cannot remove the cast : for shifting 32 bits or more, we need to be on a int64.
[Bug tree-optimization/89689] [7/8/9 regression] false warning -Wstringop-overflow=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689 --- Comment #2 from Xavier --- Thanks for the quick answer and for the clear explanation ! I indeed thought about using an assert, I think we will go with the __builtin_unreachable suggestion. You motivated me to open a similar issue I found : 89699. I also had surprising errors with ignored-qualifiers and class-memaccess, I will try to get a test case for these as well.
[Bug c/89699] New: [8 regression] false warning -Wstringop-overflow and memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89699
Bug ID: 89699
Summary: [8 regression] false warning -Wstringop-overflow and
memcmp
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chantry.xavier at gmail dot com
Target Milestone: ---
Created attachment 45958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45958=edit
reduced test case
I am using gcc 8.3.1 20190228
I got a strange warning on a memcmp call, it looks like gcc is tricked to
believe the length is negative and that it overflows, or something like that ?
Not sure.
With "gcc -O -c memcmp-short.c" :
memcmp-short.c: In function ‘f’:
memcmp-short.c:9:12: warning: ‘memcmp’ specified size between
18446744071562067968 and 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
return memcmp(s1, s2, min);
^~~
This is only triggered with optimizations (-O).
And only with gcc >= 8 according to godbolt.
I think I will use a workaround similar to the one suggested in 89689 :
if (min < 0) { __builtin_unreachable(); }
Cheers !
[Bug c/89689] New: [7/8 regression] false warning -Wstringop-overflow=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689 Bug ID: 89689 Summary: [7/8 regression] false warning -Wstringop-overflow= Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chantry.xavier at gmail dot com Target Milestone: --- Created attachment 45953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45953=edit test case I am testing gcc version 8.3.1 20190228 With "gcc -O" I get the following warning: In function ‘a’, inlined from ‘o’ at result2.c:31:5: result2.c:7:12: warning: ‘__builtin_memcpy’ writing 4 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=] return __builtin___memcpy_chk(c, d, n, __builtin_object_size(c, 0)); ^~~~ With "gcc -O -Wall" I get the following warning: In function ‘a’, inlined from ‘o’ at result2.c:31:5: result2.c:7:12: warning: ‘__builtin_memcpy’ forming offset [2, 4] is out of the bounds [0, 1] of object ‘__sb_slop’ with type ‘const char[1]’ [-Warray-bounds] return __builtin___memcpy_chk(c, d, n, __builtin_object_size(c, 0)); ^~~~ result2.c: In function ‘o’: result2.c:13:12: note: ‘__sb_slop’ declared here const char __sb_slop[1]; ^ In both cases it looks buggy, because h.data points to "char buf[5]" and not to "const char __sb_slop[1]". According to my tests on godbolt.org, the first warning appeared on gcc 7, the second warning appeared on gcc 8. There was no warning with gcc <= 6. This test case does not make sense but it was derived from production code using creduce. I do not want to disable Wstringop-overflow or Warray-bounds entirely because they look useful sometimes, and I did not find a workaround by modifying the code. Fortunately the warning can be disabled locally using pragma directives.
[Bug c/86157] New: Wmisleading-indentation disabled after a #line directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86157 Bug ID: 86157 Summary: Wmisleading-indentation disabled after a #line directive Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chantry.xavier at gmail dot com Target Milestone: --- Created attachment 44279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44279=edit test case with a block macro Today at work an instance of the "goto fail" bug was discovered and fixed (4 years after being introduced). We have a coding rule to enforce brackets even for single instructions, exactly to avoid that kind of bug. It's quite well respected, but we have no tool to check it. I learned about the Wmisleading-indentation feature, that is awesome ! But we already have gcc 6 and -Wall, and the bug was not found. That's because of that exception : "The warning is not issued after a #line directive, since this typically indicates autogenerated code, and no assumptions can be made about the layout of the file that the directive references.". That's a shame. We have a few #line directives in most of our files (compiled by gcc) because we use an apple extension called blocks (a kind of closure). More details at https://techtalk.intersec.com/2014/11/blocks-rewriting-with-clang/ So it would be great to have the Wmisleading-indentation feature even for files with #line directives, perhaps with another flag ? Any idea or suggestion or workaround is welcome. Well an easy workaround is to disable the #line directives just for running that check from time to time. So I just did that but still no warning, there is another problem, I just realized this case is more complex than it looked. See attachment for a simplified test case. Since the first line hides a block macro, the problem is not detected anyway.
[Bug c/68334] New: combination of weak and noreturn attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68334
Bug ID: 68334
Summary: combination of weak and noreturn attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chantry.xavier at gmail dot com
Target Milestone: ---
It's probably more a nonsense than a bug, and all compilers behave the same way
(from gcc 4.4 to 5.2 and clang too).
If a function definition has both weak and noreturn, then it looks like the
noreturn optimization is applied anyway in the local compilation unit, even
though the function can be overriden by another one at link time.
main.c
---
#include
#include "test.h"
__attribute__((weak)) __attribute__((noreturn))
void test(void)
{
assert (0);
}
int main(void)
{
test();
return 0;
}
---
test.c
---
#include
#include "test.h"
void test(void)
{
printf("toto\n");
}
---
test.h
---
void test(void);
---
$CC -Wall -Wextra -c test.c -o test.o
$CC -Wall -Wextra -c main.c -o main.o
$CC -Wall -Wextra main.o test.o -o test
Running ./test produces the following output which shows that the function was
overriden but the code is executed twice and then segfaults:
---
toto
toto
zsh: segmentation fault (core dumped) ./test
---
I thought that noreturn optim shouldn't be applied in this case (it could maybe
still be done at linking time when using lto).
Otherwise I might have missed something in the doc which explains what's wrong.
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 Xavier chantry.xavier at gmail dot com changed: What|Removed |Added CC||chantry.xavier at gmail dot ||com --- Comment #2 from Xavier chantry.xavier at gmail dot com 2011-01-23 02:02:18 UTC --- (In reply to comment #1) Also of note is the commented bit in the test case- if you instead dereference the s6_addr bit of the union, it all works without warnings. In the preprocessed source, replace ap = (char *)u.sin6.sin6_addr; with: ap = (char *)u.sin6.sin6_addr.__in6_u.__u6_addr8; Actually it works with any member from __in6.u union. It seems gcc gets confused with the other anonymous union, and use the size of struct sockaddr instead of struct sockaddr_in6. I've got a simpler testcase which shows another interesting information : gcc gets confused when the sign of ap is the same as the size of the smallest struct/array of the union, and different from the sign of the big member that should be used.
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 --- Comment #3 from Xavier chantry.xavier at gmail dot com 2011-01-23 02:06:35 UTC --- Created attachment 23084 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23084 simpler testcase $ gcc -O3 -Wall -c small-test.c small-test.c: In function 'main': small-test.c:18:51: warning: array subscript is above array bounds small-test.c:18:43: warning: array subscript is above array bounds small-test.c:18:35: warning: array subscript is above array bounds so gcc seems to think that the size of ap is 13 instead of 16. It's important that ap and sa_data are both char, and u6_addr8 is unsigned char. Same warning if ap and sa_data are unsigned char and u6_addr8 is char. But other combinations apparently do not give any warning.
