This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402

--- Comment #22 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #21)
> On Wed, 4 Apr 2018, marxin at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
> > 
> > --- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> ---
> > For the libsanitizer/*/*_interceptors I make a quick patch:
> > https://github.com/marxin/gcc/commit/5ce658230db567474997fa411f23ac78366487ce
> > which basically splits asan_interceptors.cc and
> > sanitizer_common_interceptors.inc and moves implementation of string functions
> > to a separate compile unit.
> > This shrinks time from 38->34s for asan_interceptors.cc being built with
> > enabled checking stage1 compiler.
> > 
> > I believe splitting the interceptors to couple of logical sub-files will make
> > it very fast. List of interceptors grepped from
> > sanitizer_common_interceptors.inc:
> > I can imagine splitting that to components like string, stdio, time, process,
> > thread, math,..
> 
> The question is of course _why_ it is this slow.  It's not that this
> is 10000s of functions or very large ones...

It's analyzed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]