This is the mail archive of the
mailing list for the GCC project.
Re: GCC 5 Status Report (2015-03-20)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: gcc at gcc dot gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 20 Mar 2015 23:14:45 +0100
- Subject: Re: GCC 5 Status Report (2015-03-20)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1503201317370 dot 15299 at zhemvz dot fhfr dot qr>
> Please also prioritize fixing P1s and avoid pushing in risky
> fixes for P2s that might end up causing regressions. We are still
> seeing way too many changes in the IPA area (hi Honza!).
GCC 5 is a busy release from IPA point of view indeed. Here is a quick summary
what is still on my radar for GCC-5:
Bug 62051 - [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
I think this one can be waved away as invalid code though tracking types with visibility default
attached to it may be a safe fix and may make transition to GCC 5 smoother.
I do not think it should be P1
Bug 65475 - [5 Regression] ICE in odr_vtable_hasher::equal (segmentation fault)
Segfault is fixed (so no longer P1 IMO) I want to tamn down the verbosity of ODR violation
warnings at weekend (we probably do not want more than one warning per type)
Bug 64860 - [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works))
This is about incremental linking with LTO but without Andi's patches to make it actually work.
I think we can fix the linker errors eaisly (will do so soon), but I do not see much utility in it.
Bug 61886 - [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
This one I think may need to wait for 5.2. I have fix in works and it is not too intrusiove so far.
My main concern is about getting aliases more commonly appearing and exposing semi-latent bugs.
We did a lot of progress making them work thanks to ICF making aliases mainstream. Main issue IMO
is with alias analysis (that is not hit by ICF), but to fix 61886 we may want to introduce the
transparent aliases only for function symbols that is IMO quite safe. Once I am done I will post
full patch for RMs to consider.
We still have some inliner performance issues:
- I analyzed bzip, crafty and regressions
The first one is easy to fix at ipa-cp side that I hope Martin will look into
- Igor reports eon regression I plan to analyze on weekend
- tramp3d is about 10% above GCC 4.9 codesize - I think this is fine. trakced in:
Bug 65076 - [5 Regression] 16% tramp3d-v4.cpp compile time regression
There are two parameter tweeks I am considering (and running benchamrks over weekend):
- We may run into issues with current 15% unit growth is bit too tight. I am planning to re-benchmark
firefox and see if bumping to 20% makes useful difference. With all bugfixes in area it may not
- -fprofile-use inlining has currently no bound on size of function to inline when call is considered
resonably hot. This makes me bit nervous and I may limit it by inline-insns-single without LTO.
(with LTO overall unit growth works well)
Chromium and Firefox has some ODR violation warnings that may need a bit of love. I think there are some that
are just invalid (need to double check) and we get some unwanted verbosity here too.
ICF at Chromium needs 15% of WPA time (and saves 10% size in addition to gold ICF). Martin has patches
to improve hashing, one was approved the other (adding simple hash for types) will be hopefully done