This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH to detect narrowing in case values (PR c++/90805)
- From: Jason Merrill <jason at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Jul 2019 13:57:06 -0400
- Subject: Re: C++ PATCH to detect narrowing in case values (PR c++/90805)
- References: <20190613210314.GZ5989@redhat.com> <email@example.com> <20190703141304.GL5989@redhat.com>
On 7/3/19 10:13 AM, Marek Polacek wrote:
On Sat, Jun 22, 2019 at 11:28:36PM -0400, Jason Merrill wrote:
On 6/13/19 5:03 PM, Marek Polacek wrote:
Case values are converted constant expressions, so narrowing conversion is not
permitted. This patch adds detecting narrowing to case_conversion; it's a
handy spot because we have both the value and the (adjusted) type of the
Is there a reason not to use build_converted_constant_expr?
The function comment says "Note that if TYPE and VALUE are already integral
we don't really do the conversion because the language-independent
warning/optimization code will work better that way" so I avoided adding any
What I could do is to, instead of calling check_narrowing, call
build_converted_constant_expr (type, value, tf_warning_or_error);
and not use its result, but I'm not sure what the benefits would be.
I was thinking about using it instead of the current
perform_implicit_conversion_flags, so we get the somewhat different
constraints on the conversion. And then it becomes simpler to use it
unconditionally but throw the result away in the easy case.