- Indirection requires pointer operand update#
- Indirection requires pointer operand plus#
#) Changes in the parser to pass down the correct locations to diagnostics machinery.#) Preprocessed/original locations in a single location_t. ( PR43486)ī ) Printing accurate column information.
Constants and uses of variables do not have a location on their own. Some trade-off must be investigated.Īdd locations for operands of expressions. This probably means not using %qE, not column info, and similar limitations.
Indirection requires pointer operand update#
Handle locations during optimisation or update middle-end diagnostics to not rely in perfect location information. Indirection requires pointer operand plus#
However, c_fully_fold could also be thought of as a logical lowering step, converting front-end-specific structures (which presently are GENERIC plus the odd extra tree code) to GENERIC, with potentially further transformations needed in future, and increases in the amount of lowering involved (making datastructures correspond more closely to the source for longer in the front end) might require this lowering step everywhere even when folding isn't needed. If the C gimplification handled C_MAYBE_CONST_EXPR, some calls to c_fully_fold could be eliminated altogether only those where the information about constancy is required, in particular for static initializers, would need to remain. With such a change, c_fully_fold would only need to do the more limited folding. In principle, fold should act on GIMPLE (so avoiding any present dependence on which subexpressions were combined into larger expressions in the source program) with the only folding done before gimplification being more limited folding required for initializers. In addition, the front end does not logically need all the transformations done by fold.
At present, there are still various "optimizations" done in the C front end while the trees for expressions are built up, and some cases where some folding still happens such optimizations can be incrementally moved out of the front end into fold (or other optimizers) where they belong, and such folding during parsing incrementally disabled, moving towards trees that more closely correspond to the original source. See PR32643, PR60090, and this quote from Handle locations during folding or avoid aggressive folding in the front-ends. Changes in the diagnostics machinery to extract locations from expr and print a string from a source file instead of re-constructing things. However, opening files is quite embedded into CPP, so that would need to be factored out so we can avoid any unnecessary CPP stuff when reopening but still do it *properly* and *efficiently*. I think that thanks to our line-maps implementation, we can do the seeking quite more efficiently in terms of computation time. This is approximately what Clang (LLVM) does and it seems they can do it very fast by keeping a cache of buffers ever reopened. This is not trivial since we need to do it fast but still do all character conversions that we did when libcpp opened it the first time. Factoring out anything useful from libcpp would help to implement this. Care to handle charsets, tabs, etc must be taken into account. This is easy and fast but potentially memory consuming. Keeping the CPP buffers in memory and having in line-maps pointers directly into the buffers contents. Ideally, this should be more or less independent of CPP, so CPP (through the diagnostics machinery) calls into this when needed and not the other way around. Ifier We need to track the locations of X and r somehow.Ĭhanges in the parser to pass down the correct locations to the build_* functions.Ī location(s) -> source strings interface and machinery. Changes on the build_* functions to handle multiple locations. For non-preprocessed expr we need at least two locations per expr (beg/end). 
This requires:įor each preprocessed token, we would need to keep two locations: one for the preprocessed location and another for the original location. This will fix the well-known limitation of the pretty-printer (see PR35441), PR35742, PR49152 and etc.). Please ask in for more information if you want to help to implement some of these projects.Ī) Printing the input expression instead of re-constructing it. Each point below is a mini-project on itself.
0 kommentar(er)
