Hi,
On 28/07/2016 16:28, Jason Merrill wrote:
On Thu, Jul 28, 2016 at 7:48 AM, Paolo Carlini wrote:
Ah sorry, I missed the *type* bit. The below passes testing on x86_64-linux.
I don't think we need to check the type again after cxx_constant_value?!?
No, we don't. The patch is OK.
While fi
On Thu, Jul 28, 2016 at 7:48 AM, Paolo Carlini wrote:
> Ah sorry, I missed the *type* bit. The below passes testing on x86_64-linux.
> I don't think we need to check the type again after cxx_constant_value?!?
No, we don't. The patch is OK.
> While finally spending a decent amount of time on thi
Hi,
On 18/07/2016 20:16, Jason Merrill wrote:
On Tue, Jul 12, 2016 at 10:30 AM, Paolo Carlini
wrote:
On 30/06/2016 19:49, Jason Merrill wrote:
I think we should check the type before calling cxx_constant_value.
Ok, I got the point. I'm not sure however how far we want to go with this
and wh
On Tue, Jul 12, 2016 at 10:30 AM, Paolo Carlini
wrote:
> On 30/06/2016 19:49, Jason Merrill wrote:
>> I think we should check the type before calling cxx_constant_value.
>>
> Ok, I got the point. I'm not sure however how far we want to go with this
> and which kind of consistency we want to achiev
Hi Jason,
and sorry about the delay in following up, a few days of vacations...
On 30/06/2016 19:49, Jason Merrill wrote:
I think we should check the type before calling cxx_constant_value.
Ok, I got the point. I'm not sure however how far we want to go with
this and which kind of consistenc
Hi,
we have this pretty old regression where we ICE on the invalid snippet:
class A
{
int f ();
enum { a = f };
};
in fact we hit the gcc_checking_assert in cxx_eval_constant_expression
case COMPONENT_REF:
if (is_overloaded_fn (t))
{
/* We can only get here in checking