Patch to fix parse time message

Tim Josling
Sat Apr 26 06:33:00 GMT 2003

This patch corrects the text of the -ftime-report output, so that the 
"parser" time is correctly reported as "parser and actions".

ChangeLog is at the end and the patch with date to be filled in) is 

While other possible more elaborate patches may be better, this one is a 
step in the right direction and therefore should be approved IMHO. This 
one has the advantage that it can be implemented now.

Bootstrapped on i586-pc-linux-gnu and ran cobol/treelang test suites. 
Ran some compiles with -ftime-report and it printed OK.

Can I apply it?

Tim Josling


With option -ftime-report and other similar options such as -Q, GCC 
reports all the time in the parser and some time spent in 'parser 
actions' as "parser". Periodically, this leads to calls to rewrite the 
parser, usually the suggestion is to hand code it.

In fact some parsers have already been hand coded, for this and other 

I have determined that

1. Typically about 2/3 of the parser time is not bison's fault, and 
therefore bison is being unjustly criticised.

2. Adding a new time category such as 'parser actions' is problematic 
and unikely to happen. My previous patch was rejected and I see little 
chance of getting anything accepted in a reasonable time frame with 
reasonable effort.

a) Bison lacks a feature to hook into just as you enter and exit 
actions. So one must post process the bison output, or change bison to 
add such a feature. Changing bison would not be simple or fast, though 
Akim was responsive to the suggestion. He suggested a somewhat more 
ambitious change which is out of scope for me.

Postprocessing the output was rejected when I submitted a patch to do 
this some time back.

b) Time calls on entry and exit to every action add significantly to CPU 
time. The extra cc1 time is about 0.4% even with the timing options 
turned off. So you would need to add a configure option to disable it. I 
did this in my previous patch, but that had the disadvantage that if say 
Red Hat turned the option off, people would not be able to do 
-ftime-report and have it work, without building the compiler themselves.

Previous tests suggested that the overhead would not be significant. 
However the number of entries and exits from the parser is very high, 
and when calls for these are added, the overhead becomes significant.

Another suggestion to cut the overhead was to wrap all the calls in 'if' 
statements. There were two problems here. There are over 100 calls, and 
it would be difficult to keep such as regime in place reliably. You 
could define the calls as macros, but this seems to contravene the 
coding standards, by hiding conditional logic in the macros. Also, I 
found that this did not actually help. All the ifs seemed to mess up the 
CPUs branch tables sufficiently that there was no speedup.

c) Some languages such as Fortran and C++ have hand coded parsers. This 
makes it impossible to split CPU time for parser and actions as there is 
no clean point to hook into. You could add all the calls with hand 
coding but I think this would not be viable.


Here is the changelog.

+2003-??-??  Tim Josling  <>
+	* timevar.def: Change literal for parser to "parser and actions".

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.timevar.1.txt
URL: <>

More information about the Gcc-patches mailing list