On Thu, Jan 21, 2016 at 8:57 AM, Michael Matz <m...@suse.de> wrote:
> Hi,
>
> this has bothered me for some time. The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> includes <string> and <algorithm> under C++, and we meanwhile use the C++
> compiler for configure tests (which makes sense). Now, the difference for
> a debuggable (but not even checking-enabled) cc1plus for a file containing
> just main():
>
> % cat blaeh.cc
> #include <stdio.h>
> #include <cstring>
> #include <utility>
> #include <new>
> int main() {}
> % cc1plus -quiet -ftime-report blaeh.cc
> TOTAL : 0.12 0.01 0.14
>
> (This is btw. three times as expensive as with 4.8 headers (i.e.
> precompile with g++-4.8 then compile with the same cc1plus as above,
> taking 0.04 seconds; the STL headers bloat quite much over time)
>
> Well, not quite blazing fast but then adding <string>:
>
> % cc1plus -quiet -ftime-report blaeh-string.cc
> TOTAL : 0.60 0.05 0.66
>
> Meeh. And adding <algorithm> on top:
>
> % cc1plus -quiet -ftime-report blaeh-string-alg.cc
> TOTAL : 1.13 0.09 1.23
>
> So, more than a second for checking if some C-only decl is available, just
> because system.h unconditionally includes mostly useless STL headers.
>
> So, how useless exactly? A whopping single file of cc1 proper needs
> <string>, _two_ files need <algorithm>, and a single target has an unlucky
> interface in its prototypes and also needs <string>. (One additional
> header lazily uses std::string for no particular reason). So we pay about
> 5 minutes build time per stage (there are ~400 libbackend.a files) for
> more or less nothing.
>
> So, let's include those headers only conditionally; I'm pretty sure it's
> not unreasonable for a source file, if it needs a particular STL facility
> to #define USES_abcheader (like one normally would have to #include
> <abcheader>) before the "system.h" include.
>
> See the patch. I've grepped for target or language dependencies on other
> STL types, and either they were already including the right header, or
> were covered with the new system.h (i.e. I've built all targets quickly
> for which grepping for 'std::' returned anything). The genconditions.c
> change is for the benefit of aarch64 as well, and it single function
> aarch64_get_extension_string_for_isa_flags returning a std::string.
>
> What do people think? Should I pass it through a proper bootstrap and put
> it to trunk? It's a (developer time) regression, right? ;-)
>
>
> Ciao,
> Michael.
> * system.h (string, algorithm): Include only conditionally.
> (new): Include always under C++.
> * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> * final.c (toplevel): Ditto.
> * ipa-chkp.c (toplevel): Define USES_STRING.
> * genconditions.c (write_header): Make gencondmd.c define
> USES_STRING.
> * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
>
This may have caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434
H.J.
