Re: [3.4 PATCH] PR c++/20995: Type-unsafe trees for templates

[Mark Mitchell <mark at codesourcery dot com>]

Roger Sayle wrote:

> In my defense, my misunderstanding of how C++ works is based largely on
> reading the code, and as you point out until recently a large fraction
> of this code has been incorrect, but lucky.  All of the g++ interactions
> with fold, prior to gcc 4.0 give a disceptive picture of the "intended"
> interactions between the two.  "Of course, template trees are valid
> generic, or you obviously wouldn't be calling fold on them" logic.

Right, I can see how you would have drawn the wrong conclusion.

> I still think that restricted folding is possible during parsing,
> provided that it's done carefully.  For example, for the testcase
> attached to the PR, I believe that:
>
> template<int N> void foo()
> {
>     double d = (N ? 0.0 : 0) + 1;
> }
>
> could be simplified to
>
> template<int N> void foo()
> {
>   double d = 1.0;
> }

Yes, you're correct.  There are specific cases where things like this 
can be done.  The advantages of doing that would be that we would have a 
more compact representation of the template, and less work to do on each 
 instantiation.  The disadvantage is that we would have to do more work 
when parsing the original template, so if there were no instantiations 
of the template we might lose.

In addition, the situation is somewhat complicated by the fact that if 
"N" were something like "S<T>::I" then we need to do access checking on 
"S<T>::I" once we know what "T" is, which means that we have to save 
"S<T>::I" somewhere anyhow.

> However, as you've been trying to tell me for years and I've just
> been to dumb/blind to grasp, the current infrastructure just isn't
> set up for this and the existing implementation is misleading.

Right.  What Nathan and I want to do is to fold only those things with 
the standard calls "constant expressions" (or perhaps just "integral 
constant expressions", augmented with floating-point literals, as a GNU 
extension).  Those are required to be folded at parse-time.  However, 
the language doesn't require that we fold anything else at parse-time, 
and so our thinking is to delay that until we're actually handing things 
to the middle end.

> Correspondingly, calling fold from the C front-end isn't a bug,
> at least not from a correctness perspective as it is in C++.

Right.  In C, it's possible to determine the type of any expression from 
the types of its constituent expressions.  In C++, that's not always 
true when parsing templates, and there are the other lvalue/rvalue 
issues we've discussed previously.  By folding late (at the point of 
conversion to GIMPLE) we could stop disabling the COND_EXPR 
optimizations that we discussed at length before.

> I hope this explains why I may have appeared so pig-headed previously.

I took it rather the opposite way: that if I was unable to explain to 
you why things were as they were, the fault was probably with my 
explanation.  In any event, I'm glad we're on the same page now.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304