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.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #19 from Martin Uecker ---
It would still work for other arguments that are used in the active branch, but
not arguments you may not use in active branch or other subexpressions not used
in the active branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #18
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #16 from uecker at gcc dot gnu.org ---
Your example program is indeed not conforming and violates a constraint because
you pass a pointer of type that can not be assigned to the type of the
argument. So a diagnostic is required and
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
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
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 ---
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #11 from Alejandro Colomar ---
What are pedwarns? :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #10 from Andrew Pinski ---
(In reply to Alejandro Colomar from comment #9)
> The related bug claims to be fixed in trunk. I can still reproduce mine in
> gcc-14, from Debian RC-Buggy.
Pedwarn warnings were not fixed ...
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Also note clang has the same behavior .
ICC does too.
MSVC actually gets it right (need to use /std:clatest) and change time_t into
long since time_t there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #6 from Andrew Pinski ---
Because the inner _Generic gets selected first and then outter one is selected.
Also note clang has the same behavior .
Note the syntax error is just a2i should not have a comma in it.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #4 from Sam James ---
I think this sort of thing is somewhat common when it comes to something the
frontend can't even parse. But we'll see what others say.
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, ...)\
(
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
21 matches
Mail list logo
