Mark Mitchell <[EMAIL PROTECTED]> wrote: >> If the parser can't be used to provide useful context, we could >> potentially postpone the calling of "fold" for C++ COND_EXPRs during >> parsing, but call "fold" on COND_EXPRs while lowering to gimple, where >> we'll always know whether we're expecting lvalues/rvalues. > > We should do that for *all* calls to fold. A patch to do that would be > most welcome!
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 simplifications which are not allowed in the Java semantics of constant expressions. 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++ frontend? -- Giovanni Bajo
