This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++0x constexpr PATCHes #7-10: the rest of the compiler support
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 7 Jan 2011 06:48:10 -0800
- Subject: Re: C++0x constexpr PATCHes #7-10: the rest of the compiler support
- References: <4CCE261C.1020709@redhat.com>
On Sun, Oct 31, 2010 at 7:29 PM, Jason Merrill <jason@redhat.com> wrote:
> The rest of these patches I'm not applying immediately because the last one
> depends on my fold_indirect_ref_1 patch, and it doesn't really make sense to
> apply the others without the last one; I'm just sending them to the list now
> to make the end of Stage 1.
>
> decl_constant_var.patch: Replaces uses of DECL_INTEGRAL_CONSTANT_VAR_P with
> the new decl_constant_var_p which also allows constexpr variables, adjusts
> when-used template instantiation to require immediate instantiation of
> constexpr functions.
>
> constexpr-register.patch: Handles storing the definition of constexpr
> functions for later expansion.
>
> constexpr-eval.patch: Handles the actual compile-time evaluation of C++0x
> constant expressions.
>
> constexpr-integrate.patch: Integrates the C++0x constant expression
> semantics into the rest of the compiler.
>
> The last patch in particular still needs some work; in particular, I still
> need to sort out the relationship between constant expression evaluation and
> value_dependent_expression_p. ?I think this will just mean using
> potential_constant_expression, but it still needs to happen; I think this
> can be cleaned up in stage 3.
>
> The other remaining cleanup is to switch the C++ front end over to a
> c_fully_fold type model of delayed folding; I had originally expected to do
> that early in development, but it turned out to be more complicated than I
> expected, so I decided to finish the functionality first. ?This will be
> necessary to be fully correct in deciding what is or is not a constant
> expression. ?I do not plan to do this for GCC 4.6.
>
> Tested x86_64-pc-linux-gnu, not applied quite yet.
>
> commit e1c3c7a78bb1d0b58389ba15b13871d2da9c05a9
> Author: Jason Merrill <jason@redhat.com>
> Date: ? Tue Oct 26 19:03:56 2010 -0400
>
> ? ? ? ?* decl2.c (decl_constant_var_p): New fn.
> ? ? ? ?(decl_maybe_constant_var_p): New fn.
> ? ? ? ?(mark_used): Rework instantiation of things needed for constant
> ? ? ? ?expressions.
> ? ? ? ?* cp-tree.h: Declare new fns.
> ? ? ? ?* pt.c (instantiate_decl): Handle cp_unevaluated_operand.
> ? ? ? ?(always_instantiate_p): Use decl_maybe_constant_var_p.
> ? ? ? ?(instantiate_decl): Don't defer constexpr functions.
> ? ? ? ?* repo.c (repo_emit_p): Use decl_maybe_constant_var_p.
> ? ? ? ?* semantics.c (finish_id_expression): Use decl_constant_var_p.
> ? ? ? ?Check for valid name in constant expr after mark_used.
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47207
--
H.J.