https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #5 from Robert Dubner <rdubner at gcc dot gnu.org> --- As the parser parses each COBOL statement, it tends to call a function, generally named parser_whatever. For example, the COBOL statement "OPEN INPUT <file>" results in the function parser_file_open() being called. SHOW_PARSE causes most such functions to produce a message; it's a fast and easy way of figuring out what the parsers is doing, and what parameters it is passing to each function. I use it frequently, as in many times a day when there is a parsing or code generation bug to be found. TRACE1 does something similar for run-time code. It is powerful, but expensive; it takes a long time to compile and generates a lot of output. I use it when something hard to understand is happening in a small example of a bug. But it ends up showing, at run-time, what the parser was doing at compile time. I can see an immediate need to get rid of extraneous getenv(), and I see how SHOW_PARSE and TRACE1 should be changed to GCOBOL_SHOW and GCOBOL_TRACE. There is a caveat: Most of those getenvs() were introduced by Jim; that technique of having a function respond to its own name in a getenv is a technique I don't often use, and that he often does. I don't know how strongly he might object to getting rid of them. I am waiting for him to weigh in. Given what you've told me about, I suspect I would look into joining the Fortran -fdump-parse-tree option for SHOW_PARSE. And I suppose that -ftrace might be invented for GCOBOL for the TRACE1 option. Is that change to options and files something that needs to be done before the upcoming GCC-15 fork? I only ask at this point because of the timeline that's been suggested. There is a branch upcoming, perhaps in days; it would be a shame to embed a problem into the release because there wasn't time to adequately test it.
