Giovanni Bajo wrote:
>
> It looks like the general consensus is that we should not use fold() anymore
> in the frontends (I consider gimplify part of middle-end already, as it is
> mostly language-independent). I know Java people also are trying to remove
> usage of fold() since it produces simpli
Richard Kenner wrote:
I think the confusion may be in what is being called "parsing and
semantic analysis" as opposed to "the front end". I agree that fold
is probably not appropriate to be called during the former, but the latter
includes the act of building the GENERIC tree and I see absolutely
But folding during parsing and semantic analysis, beyond that required
by the language standard, is hobbled by such matters as needing to
preserve language-specific lvalue-nature - for example, needing to
keep a COND_EXPR in a form which the C++ front end understands as a
lvalue
On Mon, 7 Mar 2005, Richard Kenner wrote:
> What I thought we agreed on was *only* that if a language has rules about
> what *must* be a constant, we should not be depending on fold to be part
> of the enforcement for those rules.
A language has rules about what must be a constant. It has rules
It looks like the general consensus is that we should not use fold()
anymore in the frontends
I haven't seen that and certainly don't agree with it. The earlier we can
get rid of junk trees, the better. There is no point in having separate
code in a front end to fold "1+1" nor a point i
On Mar 7, 2005, at 12:40, Giovanni Bajo wrote:\
But how are you proposing to handle the fact that the C++ FE needs to
fold
constant expressions (in the ISO C++ sense of 'constant expressions)?
For
instance, we need to fold "1+1" into "2" much before gimplification.
Should
a part of fold() be ext
Giovanni Bajo wrote:
But how are you proposing to handle the fact that the C++ FE needs to fold
constant expressions (in the ISO C++ sense of 'constant expressions)? For
instance, we need to fold "1+1" into "2" much before gimplification. Should
a part of fold() be extracted and duplicated in the C
