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

Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- Created attachment 55039 --> https://gcc.gnu.org/bugzi

[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

Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- Created attachment 54786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54786&action=edit Preprocessed reproducer Link:

[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

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- It's interesting to pass pointers to one past the end of an array to a function, acting as a sentinel value that serves

[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

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- I can't find any documentation about `__builtin_classify_type()`. Moreover, it behaves weird with arrays. $ grepc type_class ./gcc/typeclass.h:30:

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

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- Some stuff is allocated and deallocated through non-pointer types. Most of the time it's file descriptors, i.e., int. Since

[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

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- Related: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313> The description of the restrict qualifier would lead one to think that

[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

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- There are two problems here: One is a dereference of a NULL pointer in the standard C++ library code (at

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

ignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- I'd like to see Clang's _ExtInt(N) arbitrary-precision fixed-width integers (https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types) in GCC. I have in

[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

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- The following code never discards that `42`, passing it to the caller of foobar() (in a different translation unit), and forcing it

[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

[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

[Bug c/95024] No way to pass "-Wno-error=..." with #pragma GCC diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95024 --- Comment #2 from Alejandro Colomar --- If I use #pragma GCC diagnostic ignored "-Wconversion" I will loose the warning. I still want the warning, but not the error. That's what I have right now as a workaround, but it's not what I want. __

[Bug c/95024] New: No way to pass "-Wno-error=..." with #pragma GCC diagnostic

ty: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- There is no way to disable `-Werror` for specific lines of code. I would use something like this: // I want errors about conve

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746 --- Comment #3 from Alejandro Colomar --- I tried to use ``#pragma GCC diagnostic`` to enable ``-Wsystem-headers`` only for that macro. It bloated me with completely unrelated errors from libraries. So it is not an option. The only workaround

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746 --- Comment #2 from Alejandro Colomar --- Maybe the design is not perfect. Maybe some special warnings should still be warned about when they are used in user's code. I don't think there are any possible false positives with this warning. But

[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754 --- Comment #1 from Alejandro Colomar --- __builin_unreachable() helped silencing that specific bug, as a temporary workaround: [[gnu::nonnull]] static int init_x(int cond, int **x, int *y) { if (!cond) return -1;

[Bug analyzer/94754] New: -fanalyzer false positive due to it ignoring previous if

Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- The analyzer follows branches that are incompatible (sometimes). Code to reproduce the bug: [[gnu::nonnull]] static voidinit_x(int

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

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- I found out that the macro `#define __arraycount(__x) (sizeof(__x) / sizeof(__x[0]))` which is in libbsd's doesn't trigger any wa

[Bug c/91107] __attribute__((pure)) to function with non-const pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91107 --- Comment #2 from Alejandro Colomar --- Technically it can modify globals as long as that doesn't affect the state of the program, but in this case it is affecting the state of the program, so it isn't a pure function. Fair enough, then the bu

[Bug c/91107] __attribute__((pure)) to function with non-const pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91107 --- Comment #2 from Alejandro Colomar --- Technically it can modify globals as long as that doesn't affect the state of the program, but in this case it is affecting the state of the program, so it isn't a pure function. Fair enough, then the bu

[Bug c/91107] New: __attribute__((pure)) to function with non-const pointers

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: colomar.6.4.3 at gmail dot com Target Milestone: --- I have a function that takes two arrays and writes into a third array the result of a pure function (c_i = a_i / b_i): inline void

[Bug tree-optimization/10980] vararg functions are not inlined

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

[Bug c/80354] Poor support to silence -Wformat-truncation=1

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