[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 #2 from Alejandro Colomar --- Here's a simplified version that will cause the same internal compiler error. This one will probably cause less brain damage to readers, as it has significantly less magic. $ cat flexi2.c #include #i

[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 #1 from Alejandro Colomar --- Please use this: Reported-by: Alejandro Colomar

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 Bug ID: 109802 Summary: [regression] during IPA pass: analyzer: internal compiler error (using dubious flexible arrays in unions) Product: gcc Version: 13.1.0

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com ---

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335 Bug ID: 109335 Summary: -Wanalyzer-malloc-leak false positives and false negatives Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Pr

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #5 from Alejandro Colomar --- Interesting. Thanks for clarifying :)

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #3 from Alejandro Colomar --- Hi Andrew! Just a few nitpicks: - In the first testcase you posted, the [] is missing the 0: [0]. - In the reduced test case, you call the pointer to one past the end as 'end'. That is misleading,

[Bug c/108036] New: Spurious warning for zero-sized array parameters to a function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Bug ID: 108036 Summary: Spurious warning for zero-sized array parameters to a function Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #29 from Alejandro Colomar --- Hi! On 10/28/22 12:51, rguenther at suse dot de wrote: > Quite likely yes (OTOH __BIGGEST_ALIGNMENT__ changed as well). That > also means BITINT_MAXWIDTH should eventually be decided by the ABI > grou

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107348 --- Comment #6 from Alejandro Colomar --- Thanks! Maybe a working __builtin_classify_type2() would be useful... Maybe not... BTW, maybe it's worth checking all the code in gcc that is comparing the result against 14, and see if it should be r

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107348 --- Comment #4 from Alejandro Colomar --- Hmm. Then I wonder if array_type_class is being used at all, or if it's unused code.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107348 --- Comment #2 from Alejandro Colomar --- Being a builtin, I expected that you could just do "compiler magic" to avoid the decay.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107348 Bug ID: 107348 Summary: documentation: __builtin_classify_type() undocumented Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Co

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 --- Comment #6 from Alejandro Colomar --- timerfd_create() might not be important if the timer is not correctly deleted. pthread_mutex_init() is another one that is quite more important, as leaking such a thing in a multithreaded program will b

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 --- Comment #5 from Alejandro Colomar --- We could also keep the old [[gnu::malloc(...)]] attribute, of course, if a new attribute would be an issue. We would just have to add an extra argument (the third?, or one before the function name?) to

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 --- Comment #4 from Alejandro Colomar --- Hi David, I was missing that this is to be introduced in GCC 13, which of course I still don't have; but thanks! It'll be a great improvement. Still, this doesn't seem to cover all cases. See for exa

[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 --- Comment #2 from Alejandro Colomar --- Also interesting might be that one function might have more than one closer. For example, open(2) might be closed by close(2), but it is also closed by fdopen(3), in the sense that the file descriptor c

[Bug c/106854] New: [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 Bug ID: 106854 Summary: [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/106850] restrict type qualifier ignored on function return type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106850 --- Comment #3 from Alejandro Colomar --- Ahhh, yeah, something like rvalues don't have qualifiers. I seem to remember now. Maybe the standard should fix this for restrict, because things like clang's _Nonnull would benefit from being kept in

[Bug c/106850] restrict type qualifier ignored on function return type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106850 --- Comment #1 from Alejandro Colomar --- The benefits are: - It's standard. - It's less bytes to type.

[Bug c/106850] New: restrict type qualifier ignored on function return type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106850 Bug ID: 106850 Summary: restrict type qualifier ignored on function return type Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Pri

[Bug c++/103862] -Wold-style-cast warns about system macros

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com ---

[Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233 --- Comment #6 from Alejandro Colomar --- I mean, I'm not against that, in fact I think it's good to know if my program is going to crash, even if it's not my fault, but then I wonder if cases such as

[Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233 --- Comment #5 from Alejandro Colomar --- Is `-fanalyzer` allowed to report errors from system headers exclusively? I mean, ignoring the fact that C++ is unsupported, there's no report at all that relates that error report to my code; not even

[Bug c++/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233 --- Comment #1 from Alejandro Colomar --- $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux bookworm/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="http

[Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233 Bug ID: 103233 Summary: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference Product: gcc Version: unknown Status: UNCONFIRMED

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #9 from Alejandro Colomar --- Is there any proposal regarding suffices for constants? I didn't see it in the main proposal for _BitInt(). I mean something like 1u8 to create a constant of type unsigned _BitInt(8). --- @Joseph Re

[Bug c/102989] Add Clang's _ExtInt(N)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #5 from Alejandro Colomar --- Thanks for that info. It's nice to see the standard is considering that. Yes, we should add what the standard is going to add, so I'd wait to see what the standard decides in the end. Cheers, Alex

[Bug c/102989] Add Clang's _ExtInt(N)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #3 from Alejandro Colomar --- D'oh. s/comma/parenthesis/

[Bug c/102989] Add Clang's _ExtInt(N)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #2 from Alejandro Colomar --- There was a missing comma. Fix: #define __STYPE_MAX(t) (t) 1 << (widthof(t) - 2)) - 1) << 1) + 1)

[Bug c/102989] Add Clang's _ExtInt(N)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #1 from Alejandro Colomar --- This also triggers the following wish: 'widthof(t)', which would be equivalent to 'sizeof(t) * CHAR_BIT' for normal types, but would be equal to N in the case of _ExtInt(N). It could also be used to me

[Bug c/102989] New: Add Clang's _ExtInt(N)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Bug ID: 102989 Summary: Add Clang's _ExtInt(N) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee:

[Bug c/101545] [[nodiscard]]: Incorrect warning when creating a function alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101545 --- Comment #1 from Alejandro Colomar --- The same code with [[gnu::warn_unused_result]] instead of [[nodiscard]] doesn't trigger the warning.

[Bug c/101545] New: [[nodiscard]]: Incorrect warning when creating a function alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101545 Bug ID: 101545 Summary: [[nodiscard]]: Incorrect warning when creating a function alias Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal

[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com --- C

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 --- Comment #7 from Alejandro Colomar --- Oops, sorry, I meant the previous comment for another bug. I don't know if it's solved or not in gcc-11

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com --- C