Hi Thomas, > On 18 Jun 2019, at 17:40, Thomas Schwinge <tho...@codesourcery.com> wrote: >
> I normally don't pay too much attention to how GCC builds proceed, but > here, I was waiting for it to complete... ;-) > > Doing a native bootstrap build on x86_64-pc-linux-gnu, with > '--enable-checking=yes,extra,df,fold,rtl' (is that excessive, maybe?), I > just noticed that stage 2 (thus actually '-fno-checking') build of > 'insn-extract.c' took more than 80 min to complete (with 1.3 GiB RAM > resident, which seems "reasonable"). > > I know we have some such issues compiling GCC's large generated files, > but I don't think I noticed that one being so much slower than the > others. In terms of file size (which doesn't say too much, I > understand), it's with 432 KiB not exactly small, but not exactly huge > either: 'insn-automata.c' occupies 11 MiB, and in the '-j16' build on > "Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz" completed much earlier. > > I do notice that 'insn-extract.c' is special in that it contains exactly > one function, containing one huge 'switch' statement at its top level. > > Is this maybe an issue/regression that somebody else also has noticed > (recently?), and/or worth investigating? It also has a habit of OOMing on i686-darwin10 when built with —enable-checking=yes,rtl,tree (O1 is sufficient to suppress that issue tho). I hadn’t paid too much attention to the time taken, just that it breaks bootstrap with that checking recipe. Iain.
