This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch] PR 51312
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jason Merrill <jason at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 07 Aug 2014 15:58:51 +0200
- Subject: Re: [C++ Patch] PR 51312
- Authentication-results: sourceware.org; auth=none
- References: <53E359BC dot 10008 at oracle dot com> <53E37E22 dot 8020002 at redhat dot com>
On 08/07/2014 03:24 PM, Jason Merrill wrote:
If we do that, I have also to move back the latter check to the original
position, otherwise we regress, ie, we don't reject anymore, those two
testcases I tweaked. That means that when we are handling an enum with
fixed underlying type we always do that additional final check and
conversion, which, in my understanding, is redundant if we just call
perform_implicit_conversion_flags (with LOOKUP_NO_NARROWING!) on top.
Also, I was thinking earlier today that conceptually the check pasted
above should check cases different from the cases handled by
perform_implicit_conversion_flags, thus, eg, *not* handle enum27.C,
because it's an hard error, isn't our standard (and suppressible)
narrowing diagnostic. Seems more correct to use it only to diagnose that
the internally computed next enumerator overflows. See what I mean?
On 08/07/2014 06:49 AM, Paolo Carlini wrote:
+ if (ENUM_UNDERLYING_TYPE (enumtype))
+ value = perform_implicit_conversion_flags
+ (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error,
+ LOOKUP_IMPLICIT | LOOKUP_NO_NARROWING);
It seems like doing this unconditionally will suppress this error in
+ if (!int_fits_type_p (value, ENUM_UNDERLYING_TYPE
+ error ("enumerator value %E is outside the range of
+ "type %<%T%>", value, ENUM_UNDERLYING_TYPE (enumtype));
Maybe only do the conversion above if the expression isn't already an
integer or enumeration?