This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581
- From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 23 Jan 2017 20:23:38 +0000
- Subject: [Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581
- Auto-submitted: auto-generated
- References: <bug-79165-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org
--- Comment #11 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
[...]
> 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).
Even if we fixed that, this seems to have uncovered an issue with input.c: if I
add some logging to input.c, there seems to be something going badly wrong with
the caching of reading source lines, for this case at least.
get_next_line is being called many more times that I would have expected given
the pattern of calls to location_get_source_line. For some reason, the cache
isn't working, and it's re-reading large chunks of the source file each time a
diagnostic_show_locus is called (even on repeated calls to access the same
line).
I'm investigating why the cache in input.c is failing.