http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #19 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-05-31
21:33:51 UTC ---
(In reply to comment #16)
> In any case I recommend not mixing together here different issues:
I don't believe there are separate issues here.
> the first
> one, subject of this report, is overeager warning in open enum context with
> conditional operators
Yes, that warning is overeager *in that context*, i.e. it fires on correct
code. Further, that code is quite common in template metaprogramming,
and we've had it fire in several different packages.
> (I understand that by now we agree that the warning is
> behaving as designed,
I don't believe we agree on that.
The warning itself is good (behaving as designed) in this context:
enum { A };
enum { B };
return 0 ? A : B; // bug
I wouldn't want to suppress that warning above.
But I would *have* to suppress it (we build with -Werror), if it also fires
in the open enum context, where it does *not* behave as designed.
And that would be quite undesireable.
> only it seems sensible to have a way to at least
> controlling it, cmp C front end, EDG); the second one is about speculative
> defects in the way the C++ front end handles enumerated types. For the latter
> we need testcases in Bugzilla, actually a separate PR should be opened.
The second issue you are referring to is really just an explanation of
why the code that generates the warning is doing so: it has been given
bad data.
In comment#15, Lawrence suggested an approach ("Second, ...") that would
avoid giving bad data to build_conditional_expr_1().
