[Bug preprocessor/118519] Escaped line breaks in the middle of a token

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519 --- Comment #2 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #1) > Why? A lot of programs use quite long identifiers and in projects which use > strict line length restrictions it is still useful. Hmmm, can you please shar

[Bug c/118519] New: Escaped line breaks in the middle of a token

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519 Bug ID: 118519 Summary: Escaped line breaks in the middle of a token Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #4 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > I think this need analyzer to handle really. We get a -Wfree-nonheap-object if I change the strsep(3) call by s++. I think we should treat any call that ge

[Bug analyzer/118500] no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 --- Comment #3 from Alejandro Colomar --- (In reply to Sam James from comment #2) > With -O0/-O1, we do get -Wanalyzer-malloc-leak. It gets lost with >= -O2 > unless we use noinine on my_strdup. Not sure if that's another case of > PR100717 and

[Bug c/118500] New: no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500 Bug ID: 118500 Summary: no diagnostics with strsep(3) and [[gnu::malloc(free)]] attribute Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug analyzer/118498] not diagnostic a leak with analyzer and malloc attribute with free filled in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498 --- Comment #4 from Alejandro Colomar --- (In reply to Sam James from comment #1) > Where's the deallocation? There's not. I expected that(In reply to Andrew Pinski from comment #2) > (In reply to Sam James from comment #1) > > Where's the dea

[Bug c/118498] New: -Wmismatched-dealloc false negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498 Bug ID: 118498 Summary: -Wmismatched-dealloc false negative Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/118095] nonstring attribute cannot be applied to array of char arrays

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

[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 #23 from Alejandro Colomar --- If the attribute could be applied to a type, then you could apply it this way: alx@debian:~/tmp/gcc$ cat nonstring.c typeof(__attribute__((nonstring)) char [4]) tags[10]; alx@debian:~/tmp/gcc$ gcc -Wa

[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

[Bug c/118044] -Wvla-parameter: False positive with [[gnu::access(wo, n)]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 --- Comment #2 from Alejandro Colomar --- Hmmm, interesting. Thanks!

[Bug c/118043] -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 --- Comment #3 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #1) > /* The two specs designate different size arguments. It's okay > for the explicit spec to specify a size where none is provided >

[Bug c/118044] New: -Wvla-parameter: False positive with [[gnu::access(wo, n)]]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118044 Bug ID: 118044 Summary: -Wvla-parameter: False positive with [[gnu::access(wo, n)]] Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/118043] New: -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118043 Bug ID: 118043 Summary: -Wattributes: [[gnu::access(wo, n)]]: False positive with VLA Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[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/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 #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 #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 #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 #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] 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 #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] 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/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/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 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 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/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 #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 #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 #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/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++/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 --- 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++/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++/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/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 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/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/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/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 #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 #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 #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 #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 #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 #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 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 #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 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 #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/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 e

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

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

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

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

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

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

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

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

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

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

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

  1   2   >