This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] PR 51312


Hi,

On 08/07/2014 03:24 PM, Jason Merrill wrote:
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 some cases:

+ if (!int_fits_type_p (value, ENUM_UNDERLYING_TYPE (enumtype))) + error ("enumerator value %E is outside the range of underlying "
+               "type %<%T%>", value, ENUM_UNDERLYING_TYPE (enumtype));

Maybe only do the conversion above if the expression isn't already an integer or enumeration?
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?

Thanks,
Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]