Re: GCC 5 Status Report (2015-03-20)

[Jan Hubicka <hubicka at ucw dot cz>]

> 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!).

Hello :)
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
     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
     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
by Monday.

Honza