This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] Add maybe_constant_folded_value


Hi,

On 11/13/2014 07:31 PM, Jason Merrill wrote:
On 11/13/2014 12:48 PM, Paolo Carlini wrote:
While we are at it, can you double check that in end_maybe_infinite_loop
we really want the non-sfinae version (which in principle can emit hard
errors): the inconsistency with begin_maybe_infinite_loop seems weird to
me...

I agree, let's use the sfinae version there too.
Ok.

@@ -15998,7 +15998,7 @@ cp_parser_enumerator_definition (cp_parser* parser

/* integral_constant_value will pull out this expression, so make sure
      it's folded as appropriate.  */
-  value = fold_non_dependent_expr (value);
+  value = instantiate_non_dependent_expr (value);

I think this should be replaced with fold_ if (processing_template_decl) in build_enumerator.
Ok. The value can be NULL_TREE, thus in a straightforward change (per the below) I have to check for that, otherwise we crash in maybe_constant_value. Either that or just check for NULL_TREE at the beginning of maybe_constant_value itself, I guess.
@@ -27724,7 +27724,7 @@ cp_parser_omp_clause_collapse (cp_parser *parser,

   if (num == error_mark_node)
     return list;
-  num = fold_non_dependent_expr (num);
+  num = instantiate_non_dependent_expr (num);

I think we want fold_ here.
Ok.


   /* When we defer constant folding within a statement, we may want to
      defer this folding as well.  */
-  tree t = fold_non_dependent_expr_sfinae (init, complain);
+  tree t = instantiate_non_dependent_expr_sfinae (init, complain);
   t = maybe_constant_init (t);

Let's use it here, too.
This is the relatively most tricky change: we have a regression for init/array11.C, because the gcc_assert at the end of maybe_constant_value (called by maybe_constant_init) triggers:

  gcc_assert (r == t
          || CONVERT_EXPR_P (t)
          || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
          || !cp_tree_equal (r, t));

we have VIEW_CONVERT_EXPRs, neither is constant, r != t and cp_tree_equal is true. Wild guess: are VIEW_CONVERT_EXPRs also Ok?

I'm attaching what I have so far.

Thanks,
Paolo.

/////////////////////

Attachment: patchlet3
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]