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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
--- Comment #1 from Alejandro Colomar ---
Please use this:
Reported-by: Alejandro Colomar
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
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
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
--- Comment #5 from Alejandro Colomar ---
Interesting. Thanks for clarifying :)
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,
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
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
>
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
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.
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.
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
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
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
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
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
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
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
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.
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
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
---
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
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
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;
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #3 from Alejandro Colomar ---
D'oh.
s/comma/parenthesis/
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)
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
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:
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.
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
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
---
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
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
---
37 matches
Mail list logo
