[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- The tree.c hunk has been reverted, so can we close this PR (the other PR has been reopened)?
[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 --- Comment #8 from David Malcolm --- https://gcc.opensuse.org/c++bench-czerny/pb11/ has this link: http://www.polyhedron.com/fortran-compiler-comparisons/polyhedron-benchmark-suite which is a 404. An updated link seems to be: http://www.fortran.uk/fortran-compiler-comparisons-2015/the-polyhedron-solutions-benchmark-suite/ from which a zipfile containing aermod.f90 can be seen (am looking at it now).
[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 --- Comment #7 from Richard Biener --- Ok, so the reason for the slowness is that the Fortran frontend emits full diagnostics to a temporary buffer for gfc_match_rvalue: /* Match a function reference. */ function0: m = gfc_match_actual_arglist (0, _arglist); if (m == MATCH_NO) { if (sym->attr.proc == PROC_ST_FUNCTION) gfc_error ("Statement function %qs requires argument list at %C", sym->name); else gfc_error ("Function %qs requires an argument list at %C", sym->name); m = MATCH_ERROR; break; } for aermod that's 18748 times. And what slows down with the linemap mangling is showing of the caret location (location_get_source_line/get_next_line and thus the fcache I suppose). Tentatively remembering an error like above is of course quite broken (read: expensive). So somehow with the tree.c hunk of the patch location_get_source_line (inclusive callees) gets 90 times more expensive (when using callgrind on aermod).