On 12/9/19 7:06 AM, Paolo Carlini wrote:
Hi,
On 08/12/19 18:51, Jason Merrill wrote:
Hmm, is the change to cp_expr really necessary vs. using
protected_set_expr_location?
Yes, using protected_set_expr_location works fine in this case, I
suppose because we are dealing with expressions anyway
Hi,
On 08/12/19 18:51, Jason Merrill wrote:
Hmm, is the change to cp_expr really necessary vs. using
protected_set_expr_location?
Yes, using protected_set_expr_location works fine in this case, I
suppose because we are dealing with expressions anyway plus the cp_expr
constructor from a tree
On 12/6/19 4:36 PM, Paolo Carlini wrote:
Hi,
On 06/12/19 18:53, Jason Merrill wrote:
On 12/6/19 11:14 AM, Paolo Carlini wrote:
Hi,
as promised, the below takes care of the various remaining casts.
It's mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_6
Hi,
On 06/12/19 18:53, Jason Merrill wrote:
On 12/6/19 11:14 AM, Paolo Carlini wrote:
Hi,
as promised, the below takes care of the various remaining casts.
It's mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_64-linux.
It occurs to me that once we're
On 12/6/19 11:14 AM, Paolo Carlini wrote:
Hi,
as promised, the below takes care of the various remaining casts. It's
mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_64-linux.
It occurs to me that once we're passing the location into the build_*
functi
Hi,
as promised, the below takes care of the various remaining casts. It's
mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_64-linux.
Thanks, Paolo.
gcc/cp
2019-12-06 Paolo Carlini
* typeck.c (check_for_casting_away_con
