[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 Pri

[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 nonheap.

[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 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 i

[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 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 give

[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/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

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

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #50 from Alejandro Colomar --- I forgot to set: > That is, __lengthof__ should be useful in all of the following cases: > > #define memberof(T, m) (((T *) NULL)->m) > > struct s { > size_t n; > int fam[] _

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #51 from Alejandro Colomar --- (In reply to Siddhesh Poyarekar from comment #13) > (In reply to qinzhao from comment #11) > > After the discussion with Kees on the major usage of this new builtin, I > > think that the above Category

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #53 from Alejandro Colomar --- (In reply to qinzhao from comment #52) > (In reply to Alejandro Colomar from comment #51) > > I would make it a compile-time error. Why would we want to allow a non-FAM > > there? (Unless the [[gnu::c

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #54 from Alejandro Colomar --- In a similar manner, I've made the following cases compile-time errors for __lengthof__ (still under development): extern int x[]; void f(int a[]) { size_t n; n = __lengthof__(a); n = __

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #58 from Alejandro Colomar --- (In reply to Kees Cook from comment #55) > I was expecting "s->n = 7", not " ...= m", and for > "__lengthof__(memberof(struct s, fam))" to be "== 7". It should be reporting > the array element count, no

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #62 from Alejandro Colomar --- (In reply to qinzhao from comment #61) > (In reply to qinzhao from comment #60) > > I came up with the following draft for the documentation of the new > > __builtin_get_counted_by, let me know your com

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #64 from Alejandro Colomar --- (In reply to Kees Cook from comment #63) > (In reply to Alejandro Colomar from comment #62) > > What's the value of returning NULL instead of just failing the compilation > > with an error? > > It's so

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016 --- Comment #66 from Alejandro Colomar --- (In reply to Kees Cook from comment #65) > (In reply to Alejandro Colomar from comment #64) > > How about having two macros? One that works for non-attributed pointers, > > and other that works for att

[Bug c/116313] New: -Wsequence-point false positive with auto and/or __auto_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116313 Bug ID: 116313 Summary: -Wsequence-point false positive with auto and/or __auto_type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116313 --- Comment #2 from Alejandro Colomar --- p has a variably modified type, isn't it?. Its type is 'int (*)[2 * i]'.

[Bug c/116284] [12/13/14/15 Regression] incorrect classification of zero-sized array as variably modified

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116284 --- Comment #3 from Alejandro Colomar --- I have intentions to propose 0-length arrays as a standard language feature, or at least a well-supported GCC extension. Proposals such as wi

[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 :).

[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. Ne

[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, whi

[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 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 warn

[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 #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 g.c

[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 #5

[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/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: pass

[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/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 a

[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 --- > > Th

[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 #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 #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 -Wincompatible-pointer

[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 #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 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 Compon

[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 compi

[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 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 ignored

[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 Status|UNCONFIRM

[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 th

[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 (e

[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(); my_free(

[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: nor

[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/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 reproducer

[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 Status|UNCONFIRME

[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 standard

[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 what

[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 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 abo

[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 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/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 re-readin

[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 #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 Colo

[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/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 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 --- 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 e

[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/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/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 fi

[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 the

[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 #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/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/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/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/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++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #7 from Alejandro Colomar --- See also:

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

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

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

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

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #12 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #11) > (In reply to Alejandro Colomar from comment #9) > > > > I think it's simpler to have -Wc++-compat warn about any uses of > > [[gnu::nonstring]] at all, si

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #4 from Alejandro Colomar --- +1 The proposal makes sense to me. I had originally proposed something such as char x[3] = "foo"u; for marking that as a non-string. But that was because I didn't know about [[gnu::nonstring]].

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #9 from Alejandro Colomar --- (In reply to Kees Cook from comment #7) > Could "nonstring" be applied to string literals? (Like the "u" suffix idea, > but this would be more backward-compatible.) For example, from the example > in com

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #10 from Alejandro Colomar --- (In reply to Alejandro Colomar from comment #9) > (In reply to Kees Cook from comment #7) > > Could "nonstring" be applied to string literals? (Like the "u" suffix idea, > > but this would be more backw

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #6 from Alejandro Colomar --- (In reply to Jonathan Wakely from comment #5) > (In reply to Alejandro Colomar from comment #4) > > As for C++, maybe such an initialization should be acceptable as a GNU > > extension. > > Please, no.

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #6 from Alejandro Colomar --- (In reply to Pierre Ossman from comment #5) > That may be, but -Wzero-as-null-pointer-constant is documented as > facilitating conversion to "nullptr", That documentation should be fixed to remove that

[Bug c/117059] New: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 Bug ID: 117059 Summary: Make -Wzero-as-null-pointer-constant available in C Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #6 from Alejandro Colomar --- Hmm, okay, Wextra as a first step makes sense. How about one release in Wextra, and then move it to Wall? As for ISO C, I'm not sure if ISO is a good place to start the deprecation. I don't like ISO i

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #4 from Alejandro Colomar --- Since I would like to officially deprecate 0 as a null pointer constant, it would be good if we put it in -Wall. Does it make sense?

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #8 from Alejandro Colomar --- Several years don't buy us much. I think having it for 1 release will already make it better. Further than 1 release gives us not much value; especially if there's no release notes that say that it wil

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Alejandro Colomar changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comme

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059 --- Comment #10 from Alejandro Colomar --- Do we warn about enum/_Bool (PR112556) with this? My computer with which I work with GCC is having a hardware failure and I can't use it until 3 weeks from now when a new piece arrives.

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 --- Comment #3 from Alejandro Colomar --- (In reply to Xi Ruoyao from comment #2) > No, it *is* initializing a pointer. You cannot initialize a struct with 0. > Instead the initializer is considered "flattened" in C. > > For example: > > str

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 --- Comment #1 from Alejandro Colomar --- On the other hand, it would be interesting to have a diagnostic that helps switching from {0} to {}.

[Bug c/117610] New: -Wzero-as-null-pointer-constant false positive with {0}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117610 Bug ID: 117610 Summary: -Wzero-as-null-pointer-constant false positive with {0} Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Prior

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #6 from Alejandro Colomar --- (In reply to Sam James from comment #3) > The boundary doesn't exist if it's being inlined. [[gnu::noipa]] is stronger and prevents any inlining (it's basically telling the compiler to ignore 'inline').

[Bug c/118005] New: Incorrect diagnostic combining [[gnu::noipa]] and inline

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 Bug ID: 118005 Summary: Incorrect diagnostic combining [[gnu::noipa]] and inline Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Pr

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #10 from Alejandro Colomar --- (In reply to Sam James from comment #9) > If they're internals, building the library with LTO and correct visibility > annotations should handle that for you if you mean "I want inlining > internally, b

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #12 from Alejandro Colomar --- (In reply to Sam James from comment #11) > Perhaps it makes sense to only set these when building under a static > analyser then. GCC does itself have some static analysing features via compiler diagno

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #2 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > So noipa implies noinline. Hmmm, I thought it could be considered something like , where you're showing

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #4 from Alejandro Colomar --- Maaaybe I could do the following instead, I guess. I will probably do it anyway, for compatibility with old GCC versions. I little bit more cpp(1), but that's okay-ish too, I guess. // : #if (FOO_INT

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #8 from Alejandro Colomar --- (In reply to Sam James from comment #7) > (In reply to Alejandro Colomar from comment #6) > > (In reply to Sam James from comment #3) > > > The boundary doesn't exist if it's being inlined. > > > > [[gn

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #16 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #13) > We have been warning about noinline and inline since the noinline attribute > was added back in r0-37987-g9162542e3d0cd2 . > > When noipa was added (r8-22

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005 --- Comment #17 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #15) > I think the current behavior is correct, noipa implies the function boundary > is an optimization barrier for the compiler, while inline is the exact > opp

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #20 from Alejandro Colomar --- Hi Kees, (In reply to Kees Cook from comment #19) > Created attachment 59874 [details] > RFC for ignoring NUL byte with nonstring attribute > > Here's an RFC patch for allowing the NUL char truncation

  1   2   >