https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
Sam James <sjames at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sjames at gcc dot gnu.org
--- Comment #9 from Sam James <sjames at gcc dot gnu.org> ---
The order you do it in depends on preference and what works best for the case
at hand.
The general procedure is:
1) Take preprocessed source (just find the command which builds that TU /
whatever.c/whatever.o normally, append -save-temps, and you'll get a
whatever.i); this means it's now self-contained wrt types and so on
2) Start stripping out large chunks of it and grep or inspect code generation
or whatever you prefer to make sure the problem is still there
3) Depending on the size and circumstance, you can cvise it with a script as
long as you have some condition it can grep for to make sure the problem's
still there
4) Rename long/proprietary variable names/type names and so on
Sometimes it's easier to do the preprocessed step nearly-last before cvising.
The problem with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314#c8 is,
it's not self-contained at all. What is LUT, what is jobject, ...? All of these
things matter for us being able to compile it and analyse it, and different
definitions *will* affect if the bug happens or not.
In your position, I would first take the relevant function where it goes wrong,
and start to replace external function calls with just dummy calls like
foo(...) with some prototype listed above it, foo doesn't have to have an
actual definition to be resolved to, it just needs to compile fine (not link).
Then repeat until the function is either self-contained or "self-contained"
with another function only. Repeat and rename identifiers and so on.
