[Bug tree-optimization/90387] [9 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 --- Comment #6 from Bernd Buschinski --- >From the comments I assumed that the fix is kind of trivial but it is not yet in. Is it realistic that it could be fixed in GCC 9.3? Just asking because we are compiling with -Werror and I wonder if I should just exclude array-bounds from Werror or just wait for GCC 9.3? And yes, I can totally understand if there are other more important issues :)
[Bug c/90387] New: [9 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
Bug ID: 90387
Summary: [9 Regression] __builtin_constant_p and -Warray-bounds
warnings
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: b.buschinski at googlemail dot com
Target Milestone: ---
Created attachment 46314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46314&action=edit
gcc9_constant_array_bounds_bug.c
The attached example does not compile with GCC 9.1.0.
It gives an Warray-bounds warning, which I think is invalid, as the code path
should not be triggered as the given length parameter is not compile time
const.
It worked fine with GCC 8.3.
$ gcc-8.3.0 -O2 -Wall -Werror -c gcc9_constant_array_bounds_bug.c
$ echo $?
0
$ gcc-9.1.0 -O2 -Wall -Werror -c gcc9_constant_array_bounds_bug.c
gcc9_constant_array_bounds_bug.c: In function 'foo':
gcc9_constant_array_bounds_bug.c:6:58: error: array subscript [6, 9] is outside
array bounds of 'const char[5]' [-Werror=array-bounds]
6 | ((unsigned char*)src)[6] == ((unsigned char*)pat)[6] \
| ~^~~
gcc9_constant_array_bounds_bug.c:22:9: note: in expansion of macro 'MY_MEMCMP'
22 | MY_MEMCMP(p, pattern + state, p_len) == 0) {
| ^
gcc9_constant_array_bounds_bug.c:11:23: note: while referencing 'pattern'
11 | static char const pattern[] = "abcd";
| ^~~
cc1: all warnings being treated as errors
$ echo $?
1
The code also works fine if I change the "#if 1" to "#if 0", which confuses me
greatly.
It seems that (with the #if 1) GCC 9.1 treats "p_len" as compile-time constant,
which it is clearly not, as this is a function parameter. Or does
-Warray-bounds always check all paths? Regardless if they are impossible?
And yes, the warning would be correct if "p_len" would be compile-time const.
NOTE: I reduced the code from ~500+ lines to this, but I guess you can reduce
it further :)
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
Bernd Buschinski changed:
What|Removed |Added
CC||b.buschinski at googlemail dot
com
--- Comment #4 from Bernd Buschinski ---
I also hit this problem, but not 100% sure if this is a duplicate or not.
Because as far as I can remember it used to work with GCC-11 (can not test now
only have 12) and only started failing with GCC 12.
Can someone tell me if this should be a new bug or is just a duplicate?
Known to fail on:
- sys-devel/gcc-12.1.1_p20220625 (Gentoo)
- gcc-12.1.1-1.fc36.x86_64 12.1.1 20220507 (Red Hat 12.1.1-1) (Fedora)
- 12-20220319-1ubuntu1 (Ubuntu 22.04)
Compiler explorer: https://godbolt.org/z/rrWffMe9x
Code:
#include
extern void *my_memmem(const void *__haystack, size_t __haystacklen,
const void *__needle, size_t __needlelen)
__THROW __attribute_pure__ __nonnull ((1, 3))
__attribute__((access(__read_only__, 1, 2)))
__attribute__((access(__read_only__, 3, 4)));
#define CONTAINSCONST(_cstring, string)
\
({
\
size_t const tmp_CONST_LEN = sizeof(string) - 1;
\
((_cstring).length >= tmp_CONST_LEN &&
\
(my_memmem((_cstring).buffer, (_cstring).length, string, tmp_CONST_LEN) !=
\
NULL));
\
})
struct my_string {
unsigned char *buffer;
unsigned long long length;
};
int foo(struct my_string const *const ss) {
struct my_string const str_path = *ss;
if (CONTAINSCONST(str_path, "/") ||
CONTAINSCONST(str_path, ".abcd") ||
CONTAINSCONST(str_path, "?")) {
return 1;
}
return 0;
}
// $ gcc -std=gnu99 -Wall -Wextra -Walloc-zero -O2 -fsanitize=undefined -Werror
test2.c -S
// test2.c: In function 'foo':
// test2.c:13:7: error: argument 1 is null but the corresponding size argument
2 value is [5, 18446744073709551615] [-Werror=nonnull]
//13 | (my_memmem((_cstring).buffer, (_cstring).length, string,
tmp_CONST_LEN) != \
// |
^~
// test2.c:26:7: note: in expansion of macro 'CONTAINSCONST'
//26 | CONTAINSCONST(str_path, ".abcd") ||
// | ^
// test2.c:3:14: note: in a call to function 'my_memmem' declared with
attribute 'access (read_only, 3, 4)'
// 3 | extern void *my_memmem(const void *__haystack, size_t __haystacklen,
// | ^
// cc1: all warnings being treated as errors
[Bug tree-optimization/105740] New: missed optimization switch transformation for conditions with duplicate conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740 Bug ID: 105740 Summary: missed optimization switch transformation for conditions with duplicate conditions Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: b.buschinski at googlemail dot com Target Milestone: --- Created attachment 53037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53037&action=edit Attached code + asm from the compiler explorer link Compiler Explorer Link: https://godbolt.org/z/q76s99Gj9 The code on the left does not generate a switch statement. The code on the right does generate a switch statement. The code works similar, the only difference is that the duplicate "f->len > 3" check is moved to the top for the "right" version. The compiler explorer code is actually a minimized version of the code I work on (with way more conditions in a hot code path), where I can not easily move the length check to the top, because the "f-> len > 3 && ..." is done in a very complicated macro, but that's just details. I expected both code versions to generate the same assembler. Tested with GCC-12.1 and 11.3. 10.3 does not generate a switch version for both versions, as only 11 got this nice feature. On x86_64 Linux. Please let me know if you need any additional details or if this report was useful at all.
[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740 --- Comment #12 from Bernd Buschinski --- Hi, according to godbolt (gcc trunk) this is still present. is there anything I can do to help here?
[Bug tree-optimization/113741] New: missed / wrong optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 Bug ID: 113741 Summary: missed / wrong optimization switch transformation to same function call Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: b.buschinski at googlemail dot com Target Milestone: --- Created attachment 57308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57308&action=edit Attached code + asm from the compiler explorer link Compiler Explorer Link: https://godbolt.org/z/KozK9M5YY The code is reduced from a "hot" path with huge macros. I actually improved the macros with adding the "else" in the code, but I noticed it suddenly created even more instructions and got slower. The GCC version has 52 ASM lines. The clang version only 9 ASM lines. Clang is doing a better job here. As far as I understand the ASM code, GCC generates a switch statement, but after the: cmp edi, 5 ja .L11 it should not be needed at all anymore. Additionally, GCC "reloads" the static values again (for every .L*: label) mov edi, 4 , which are already stored in "i" (C code). Tested with GCC-13.2 and compiler explorer gcc "trunk". On x86_64 Linux. Please let me know if you need any additional details or if this report was useful at all.
[Bug tree-optimization/113741] missed / wrong optimization switch transformation to same function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113741 --- Comment #2 from Bernd Buschinski --- Ah sorry, I did not know that. Please rephrase the topic to better match the actual problem :) (Or tell me what it should be rephrased to)
