[RFA C++/fortran/java] PR c/12245 (not really C frontend issue)

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka wrote:
> 
> > this patch adds the fold_p parameter to convert_to_* except for
> > convert_to_pointer that folds output always anyway and update callers
> 
> That's a logical step.
> 
> > Index: cp/typeck.c
> > ===================================================================
> > *** cp/typeck.c	(revision 144373)
> > --- cp/typeck.c	(working copy)
> > *************** build_reinterpret_cast_1 (tree type, tre
> > *** 5548,5556 ****
> >         return fold_if_not_in_template (build_nop (type, expr));
> >       }
> >     else if (TREE_CODE (type) == VECTOR_TYPE)
> > !     return fold_if_not_in_template (convert_to_vector (type, expr));
> >     else if (TREE_CODE (intype) == VECTOR_TYPE && INTEGRAL_TYPE_P (type))
> > !     return fold_if_not_in_template (convert_to_integer (type, expr));
> >     else
> >       {
> >         if (valid_p)
> > --- 5548,5556 ----
> >         return fold_if_not_in_template (build_nop (type, expr));
> >       }
> >     else if (TREE_CODE (type) == VECTOR_TYPE)
> > !     return convert_to_vector (type, expr, !processing_template_decl);
> >     else if (TREE_CODE (intype) == VECTOR_TYPE && INTEGRAL_TYPE_P (type))
> > !     return convert_to_integer (type, expr, !processing_template_decl);
> 
> Are you sure that these are never UNARY_PLUS_EXPR?  I'm not entirely
> comfortable with this approach because fold_if_not_in_template might
> grow support for more C++-specific nodes, and then this code would
> break.  At this point in the release cycle, I would prefer that you not
> changed fold_if_not_in_template calls (here and elsewhere in the patch)
> into to the new convert functions.

Well, I concluded that UNARY_PLUS_EXPR should not appear as result of
convert_to_vector action and fold is not recursive, so it will see the
CONVERT_EXPR or similar node and not get into UNARY_PLUS_EXPR sitting
inside the EXPR.

But I can keep fold_if_not_in_template wrapping the
conver_to_vector call with fold parameter set to true.
> 
> Other than that, I'll approve the C++ changes, and the
> language-independent changes.  I think you should get review from
> appropriate language maintainers for the other changes.

OK, the changes are quite simple in everything except for C++
(C++ is only frontend that seem to need to delay folding for later time)

Honza