> I think, in the long-term, your proposed approach is less useful than > fixing early folding and adding locations (via a wrapper or an > on-the-side index) to the tree nodes that don't have one. But, since > nobody is working on the latter, the "long term" may be longer than > the time until someone makes a LLVM-to-GIMPLE conversor, and replaces > the C/C++ FEs by clang. ;-)
Given the current state of front end trees and LLVM, I suspect indeed most people interested in e.g. static analysis will likely switch to LLVM if not already done. > So, as a short-term fix, your proposed > approach is definitely better than the status-quo, so I hope you > manage to get it finished. Unfortunately the suggestions I received, while they make sense on paper require a large amount of work, which I can hardly justify for now and certainly not in the short term. I suspect it would take me less time to redo my work using LLVM than to introduce a whole new API/kludge on top of gcc locations, with also still a large unknown as to whether my new patch would be accepted without yet another large rewrite. Or to put it another way, it does not really make much more sense to me to use pseudo locations than my current htable approach (it only marginally improves things, for a large development effort), in particular since a better solution would be to have a real C and C++ AST, which I suspect GCC will end up having sooner or later (e.g. via clang as you hinted). Arno
