This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 18 Jul 2016 13:16:26 -0400
- Subject: Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)
- Authentication-results: sourceware.org; auth=none
- References: <20160715184231.GX7387@tucnak.redhat.com>
On Fri, Jul 15, 2016 at 2:42 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> While in C++11, builtins returning two results, one of them by dereferencing
> a pointer argument can't be constexpr, in my understanding in C++14
> generalized constexprs they can.
Yes.
> So, this patch tweaks cxx_eval_builtin_function_call so that it handles how
> builtins.c folds these builtins (i.e. COMPOUND_EXPR with first operand
> being *arg = const1 and second operand const2, optionally all wrapped into a
> NON_LVALUE_EXPR.
Why so specific? Can't we just pass the return value from fold into
cxx_eval_constant_expression, if it isn't still a CALL_EXPR?
Incidentally, I think we should be using fold_builtin_call_array
rather than fold_build_call_array_loc.
> In addition, I've noticed that the lval argument is passed down to
> evaluation of arguments, that doesn't make sense to me, IMHO arguments
> should be always evaluated as rvalues (and for non-builtins they are).
I'm a bit nervous about this, since some builtins take arguments by
magic rather than by value, but I'm willing to accept this and see
what breaks.
Jason