[Bug c/105156] New: No diagnostic for `enum { toobig = UINT_MAX }`

2022-04-04 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 Bug ID: 105156 Summary: No diagnostic for `enum { toobig = UINT_MAX }` Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`

2022-04-04 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 --- Comment #2 from Keith Thompson --- Andrew, did you use "-std=c17 -pedantic-errors"? Both gcc and clang correctly diagnose "enum { toobig = 0x7fff * 2U + 1U };". I'm seeing weird behavior that I don't understand. Replacing the UINT_MAX m

[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`

2022-04-04 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 --- Comment #4 from Keith Thompson --- OK, that explains the bug. It sounds like the code that suppresses warnings in system headers needs to be a bit more clever. Using UINT_MAX here isn't an error in the header.

[Bug c/107091] New: Misleading error message "incompatible types when returning ..."

2022-09-29 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107091 Bug ID: 107091 Summary: Misleading error message "incompatible types when returning ..." Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/108531] New: Imaginary types are not supported, violating ISO C Annex G

2023-01-24 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531 Bug ID: 108531 Summary: Imaginary types are not supported, violating ISO C Annex G Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

2023-01-24 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531 --- Comment #1 from Keith Thompson --- After I submitted this, I found that this is probably a duplicate of: https://sourceware.org/bugzilla/show_bug.cgi?id=15720 (I disagree with the resolution of that bug report.)

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

2023-01-24 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531 --- Comment #3 from Keith Thompson --- In the latest C2X draft, https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf Annex G still requires imaginary number support for any implementation that defines __STDC_IEC_60559_COMPLEX__ or __STDC_I

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

2023-01-25 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531 --- Comment #5 from Keith Thompson --- FYI, I've sent an email to the C standard editors (the addresses at the top of the N3054 draft) suggesting that imaginary number support should be optional even if __STDC_IEC_559_COMPLEX__ and __STDC_IEC_60

[Bug c/108986] New: Incorrect warning for [static] array parameter

2023-03-01 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 Bug ID: 108986 Summary: Incorrect warning for [static] array parameter Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/108986] Incorrect warning for [static] array parameter

2023-03-01 Thread Keith.S.Thompson at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 --- Comment #1 from Keith Thompson --- A similar case. The warning refers to the size in bytes, but unlike the first case it's not incorrect, though referring to the length would IMHO be clearer. Note also that the warning appears twice. It onl