[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #25 from Alejandro Colomar --- BTW, since this seems to be a de-facto place to report bugs found by this warning, let's also list here another one found in Linux by Sam the other day: Report:

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #24 from Alejandro Colomar --- (In reply to Wentao Zhang from comment #18) > This produces warnings in kernel defconfig builds and they become errors due > to > CONFIG_WERROR. > > Cases I've observed so far: > > 1. initialization

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116082 --- Comment #3 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #2) > I agree with martin. > > And what if the '\0' is in the middle of the literal? > > char x[4] = "a\0b"; > char x[3] = "a\0b"; > char y[2] = "a\0b"; >

[Bug c/116082] -Wunterminated-string-initialization should not warn about strings that end with "\0" but should warn still for -Wc++-compat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116082 --- Comment #2 from Alejandro Colomar --- I agree with martin. And what if the '\0' is in the middle of the literal? char x[4] = "a\0b"; char x[3] = "a\0b"; char y[2] = "a\0b"; I'd keep it simple, and assume the \0s in the middle of a string

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #23 from Alejandro Colomar --- (In reply to Wentao Zhang from comment #18) > This produces warnings in kernel defconfig builds and they become errors due > to > CONFIG_WERROR. > > Cases I've observed so far: > > 1. initialization

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #22 from Alejandro Colomar --- (In reply to Wentao Zhang from comment #18) > This produces warnings in kernel defconfig builds and they become errors due > to > CONFIG_WERROR. > > Cases I've observed so far: > > 1. initialization

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #17 from Alejandro Colomar --- (In reply to Sergei Trofimovich from comment #16) > Sounds reasonable. Proposed possible changes upstream: > - elfutils: > https://patchwork.sourceware.org/project/elfutils/patch/20240715212340. In

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #15 from Alejandro Colomar --- (In reply to Sergei Trofimovich from comment #14) > This generates warning on reasonably looking code. > > On strace-6.9: > https://github.com/strace/strace/blob/v6.9/src/print_utils.h#L16 > > In

[Bug c/112833] Missing warnings on restrict misuse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833 --- Comment #5 from Alejandro Colomar --- (In reply to Sam James from comment #4) > Mind filing another bug with that? Thanks. I found . It resulted in adding -Wanalyzer-overlapping-buffers,

[Bug c/112833] Missing warnings on restrict misuse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833 --- Comment #3 from Alejandro Colomar --- (In reply to Sam James from comment #2) > Does the analyser have any sort of restrict checks? AFAIK it doesn't. I guess that's a bug (or wishlist) in itself. The `restrict` qualifier is all about data

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #11 from Alejandro Colomar --- (In reply to Konstantin Kharlamov from comment #10) > (In reply to Alejandro Colomar from comment #7) > > (In reply to Konstantin Kharlamov from comment #5) > > > So basically -Wc++-compat warns about

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #9 from Alejandro Colomar --- (In reply to uecker from comment #8) > Have you considered adding the alloc_size attribute to your allocation > functions? I didn't know about it; I will do. Thanks! :-)

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment

[Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335 --- Comment #4 from Alejandro Colomar --- Here's a smaller reproducer: $ cat pass.c #include void my_free(char *p); [[gnu::malloc(my_free)]] char *my_malloc(void); int main(void) { char *p; p = my_malloc();

[Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335 --- Comment #3 from Alejandro Colomar --- Oops, no, that's a different story. The analyzer is thinking it leaks somewhere where it doesn't seem to leak. The false positive still reproduces with gcc-14 (Debian 14-20240429-1) 14.0.1 20240429

[Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335 --- Comment #2 from Alejandro Colomar --- This is probably because there's no way to mark a function as being a valid deallocator (i.e., the converse of [[gnu::malloc()]]). As a workaround, such deallocators could be defined (C99) inline, so

[Bug c/94746] -Wsizeof-pointer-div not triggered by system header macros

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746 Alejandro Colomar changed: What|Removed |Added Resolution|--- |WONTFIX

[Bug c/95024] want a way to turn off -Werror for a specific diagnostic but only emit an warning if it was turned on before hand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95024 --- Comment #4 from Alejandro Colomar --- Sorry, I didn't make it clear; I somehow forgot about it. Here's the problem: $ cat err.c int main(void) { short s; int *p; #pragma GCC diagnostic push #pragma GCC diagnostic

[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 --- Comment #4 from Alejandro Colomar --- Thanks, David! I'm happy that this might help improve the analyzer. :-)

[Bug analyzer/115089] -Wanalyzer-use-of-uninitialized-value false negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 --- Comment #2 from Alejandro Colomar --- I found that Clang's analyzer finds this bug, so I'm less concerned that GCC can't find it. Feel free to ignore it if it's too hard to fix. ;) $ clang-tidy ./bug.c Error while trying to load a

[Bug analyzer/115089] New: -Wanalyzer-use-of-uninitialized-value false negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115089 Bug ID: 115089 Summary: -Wanalyzer-use-of-uninitialized-value false negative Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #21 from Alejandro Colomar --- It would be interesting to learn why MSVC gets it right. Maybe there's a deterministic way to avoid this warning. Although maybe it's just that they're doing heuristics.

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #20 from Alejandro Colomar --- H, I like the _Generic() to assert the type. Thanks! With that, I find it more acceptable. At least I don't need to use GNU extensions, and the cast is coupled with the verification of the type.

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #17 from Alejandro Colomar --- Neither -Wall nor -Wextra (nor -Wincompatible-pointer-types) imply -pedantic. (Ahh, this is the pedwarn reference from Andrew.) Which means the compiler could decide to turn off

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #15 from Alejandro Colomar --- (In reply to uecker from comment #13) > A couple of comments: > > In principle, those warnings are not false positives. The design of _Generic > requires that the non-taken branches are valid in C, so

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #14 from Alejandro Colomar --- Oops, I forgot to paste the version with casts. Here it is. It is too repetitive and error prone. alx@debian:~/tmp/c$ cat g.c #include #include #include #include #define is_same_type(a, b)

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #12 from Alejandro Colomar --- Hi Martin, On Tue, Apr 16, 2024 at 05:35:03AM +, uecker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 > > --- Comment #7 from uecker at gcc dot gnu.org --- > >

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #14 from Alejandro Colomar --- Hi Martin, For the discussion of my -Wincompatible-pointer-types reproducer, please visit . I'll reply to you there, since it's more on-topic, and

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #11 from Alejandro Colomar --- What are pedwarns? :)

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #9 from Alejandro Colomar --- The related bug claims to be fixed in trunk. I can still reproduce mine in gcc-14, from Debian RC-Buggy. alx@debian:~/tmp/c$ gcc-14 -Wall -Wextra g.c -S g.c: In function ‘main’: g.c:96:21: error:

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 --- Comment #6 from Alejandro Colomar --- Oh well, in my case it is -Wincompatible-pointer-types. Maybe the fix was only for -Wformat.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #5 from Alejandro Colomar --- Ahhh, sorry Sam. I had a mistake while writing the reproducer, and didn't realize. I thought it was a side effect of something else. Here's a fixed reproducer, with the fixed diagnostics. $ cat

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #3 from Alejandro Colomar --- The diagnostic is spurious, because of course if I call the following macro #define a2i(TYPE, ...)\ (

[Bug c/114731] -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 --- Comment #2 from Alejandro Colomar --- That's precisely what I meant (my bad, I used incorrect wording). I think that diagnostic is spurious, and should be removed. A few self-corrections: - I should have said diagnostics, instead of

[Bug c/114731] New: -Wincompatible-pointer-types false positive in combination with _Generic(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731 Bug ID: 114731 Summary: -Wincompatible-pointer-types false positive in combination with _Generic(3) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity:

[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 --- Comment #6 from Alejandro Colomar --- Thanks for fixing it! Would you mind showing which commit fixed this? I'm curious about it. I searched in the git log, but nothing mentioned this bug number. Now I can come to my original intent,

[Bug middle-end/108036] [11/12/13/14 Regression] Spurious warning for zero-sized array parameters to a function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #9 from Alejandro Colomar --- Hi Lundin! On Thu, Mar 07, 2024 at 10:18:12AM +, daniel.lundin.mail at gmail dot com wrote: > --- Comment #8 from Daniel Lundin --- > I don't believe char past_end[0] is valid C, because it is an

[Bug analyzer/113990] New: -Wanalyzer-malloc-leak false positive with [[gnu::malloc(free)]] and a realloc() wrapper

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113990 Bug ID: 113990 Summary: -Wanalyzer-malloc-leak false positive with [[gnu::malloc(free)]] and a realloc() wrapper Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug c/113984] -Wfree-nonheap-object false positive with VLA parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113984 --- Comment #1 from Alejandro Colomar --- With -O3, the warning also vanishes, as the function is probably inlined, and there's no VLA parameter any more. alx@debian:~/tmp$ gcc-14 -Wall -O3 nonheap.c alx@debian:~/tmp$ gcc-13 -Wall -O3

[Bug c/113984] New: -Wfree-nonheap-object false positive with VLA parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113984 Bug ID: 113984 Summary: -Wfree-nonheap-object false positive with VLA parameter Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378 --- Comment #6 from Alejandro Colomar --- On Mon, Jan 15, 2024 at 09:38:31AM +, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378 > > --- Comment #5 from Andrew Pinski --- > (In reply to Alejandro

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378 --- Comment #4 from Alejandro Colomar --- On Mon, Jan 15, 2024 at 08:35:53AM +, rguenth at gcc dot gnu.org wrote: > --- Comment #3 from Richard Biener --- > We could buffer stdin to a temporary file ... (of course that would defeat > it's

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378 --- Comment #2 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > >I expect the same diagnostic information when compiling stdin. > > > This part of the diagnostic: > 2 | foo(); > | ^~~ > > Comes from

[Bug c/113378] New: _Static_assert diagnostics lack information when compiling stdin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378 Bug ID: 113378 Summary: _Static_assert diagnostics lack information when compiling stdin Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/107348] documentation: __builtin_classify_type() undocumented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107348 Alejandro Colomar changed: What|Removed |Added Resolution|--- |FIXED

[Bug c/112833] Missing warnings on restrict misuse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833 --- Comment #1 from Alejandro Colomar --- Oops, in the reproducer from above, I should only expect a warning at call site. The definition is correct, since all parameters are restrict, so it's free to copy one to the other. Here's a

[Bug c/112833] New: Missing warnings on restrict misuse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833 Bug ID: 112833 Summary: Missing warnings on restrict misuse Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/112507] New: Missed optimization of strcpy(3) (or stpcpy(3)) with previous strnlen(3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112507 Bug ID: 112507 Summary: Missed optimization of strcpy(3) (or stpcpy(3)) with previous strnlen(3) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity:

[Bug c/111269] location for non-constant expressions inside static assert could be better

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111269 --- Comment #3 from Alejandro Colomar --- On 2023-09-01 18:57, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111269 > > Andrew Pinski changed: > >What|Removed |Added >

[Bug c/111269] location for non-constant expressions inside static assert could be better

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111269 --- Comment #2 from Alejandro Colomar --- Hi Andrew, On 2023-09-01 18:55, pinskia at gcc dot gnu.org wrote: > It is pointing to the whole expression and just the outermost operator, || . That's what I suspected. > > Now the C++ front-end

[Bug c/111269] New: Confusing location of error in source code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111269 Bug ID: 111269 Summary: Confusing location of error in source code Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 --- Comment #8 from Alejandro Colomar --- Test

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 --- Comment #7 from Alejandro Colomar --- Hi Xi, Richard! On 2023-07-11 10:34, xry111 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 > > --- Comment #6 from Xi Ruoyao --- > Anyway I'm already too frustrated

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 Alejandro Colomar changed: What|Removed |Added CC||alx at kernel dot org --- Comment

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259 --- Comment #43 from Alejandro Colomar --- GCC's manual also doesn't seem to document any deviation from ISO C rules regarding mem*() functions. It would be good to document what is the GCC interpretation of ISO C regarding those rules, and

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259 --- Comment #42 from Alejandro Colomar --- I'm very confused by this ticket. The discussion seems to be settled by Martin Sebor that the presented code has UB due to pointer provenance issues, according to the WG14 interpretation of the

[Bug analyzer/109802] [regression] during IPA pass: analyzer: internal compiler error (using dubious flexible arrays in unions)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 --- Comment #4 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #3) > Hmm, I should have used offsetof(3) in a few placed to avoid issues due to > padding, but I was lucky :). Oh, no, I didn't need it. I got it right.

[Bug analyzer/109802] [regression] during IPA pass: analyzer: internal compiler error (using dubious flexible arrays in unions)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 --- Comment #3 from Alejandro Colomar --- Hmm, I should have used offsetof(3) in a few placed to avoid issues due to padding, but I was lucky :).