OK.
Jason
On 11/18/2011 03:19 PM, Paolo Carlini wrote:
On 11/18/2011 03:11 PM, Jason Merrill wrote:
On 11/18/2011 08:57 AM, Paolo Carlini wrote:
On 11/18/2011 02:53 PM, Jason Merrill wrote:
I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, an
On 11/18/2011 03:11 PM, Jason Merrill wrote:
On 11/18/2011 08:57 AM, Paolo Carlini wrote:
On 11/18/2011 02:53 PM, Jason Merrill wrote:
I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_depende
On 11/18/2011 08:57 AM, Paolo Carlini wrote:
On 11/18/2011 02:53 PM, Jason Merrill wrote:
I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_dependent_expr.
Ok. In the meanwhile I actually test
On 11/18/2011 02:53 PM, Jason Merrill wrote:
I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_dependent_expr.
Ok. In the meanwhile I actually tested the attached, and it works. Is it
what you
I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we don't
want to mess with build_non_dependent_expr.
Jason
On 11/18/2011 02:29 PM, Paolo Carlini wrote:
On 11/18/2011 02:27 PM, Paolo Carlini wrote:
On 11/18/2011 02:16 PM, Jason Merrill wrote:
On 11/17/2011 06:52 PM, Paolo Carlini wrote:
The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha
On 11/18/2011 02:27 PM, Paolo Carlini wrote:
On 11/18/2011 02:16 PM, Jason Merrill wrote:
On 11/17/2011 06:52 PM, Paolo Carlini wrote:
The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha, I guess tsubst_copy_and_build needs to handl
On 11/18/2011 02:16 PM, Jason Merrill wrote:
On 11/17/2011 06:52 PM, Paolo Carlini wrote:
The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR better.
I see. Maybe better
On 11/17/2011 06:52 PM, Paolo Carlini wrote:
The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR better.
Jason
Hi,
On 11/17/2011 09:52 PM, Paolo Carlini wrote:
On 11/17/2011 09:37 PM, Jason Merrill wrote:
On 11/16/2011 10:00 AM, Paolo Carlini wrote:
this is an ICE on valid, 4.6/4.7 Regression, which manifests itself as
tree codes unhandled by cxx_eval_constant_expression.
Hmm, those codes shouldn't m
On 11/17/2011 09:37 PM, Jason Merrill wrote:
On 11/16/2011 10:00 AM, Paolo Carlini wrote:
this is an ICE on valid, 4.6/4.7 Regression, which manifests itself as
tree codes unhandled by cxx_eval_constant_expression.
Hmm, those codes shouldn't make it this far; we should go through
fold_non_dep
On 11/16/2011 10:00 AM, Paolo Carlini wrote:
this is an ICE on valid, 4.6/4.7 Regression, which manifests itself as
tree codes unhandled by cxx_eval_constant_expression.
Hmm, those codes shouldn't make it this far; we should go through
fold_non_dependent_expr before we get to cxx_eval_constant
On Wed, Nov 16, 2011 at 9:00 AM, Paolo Carlini wrote:
> Hi,
>
> this is an ICE on valid, 4.6/4.7 Regression, which manifests itself as tree
> codes unhandled by cxx_eval_constant_expression. The patchlet below appears
> to fix the issue and passes testing on x86_64-linux.
>
> Ok for mainline? Bran
14 matches
Mail list logo
