Re: GCC 4.1.2 RC2

[Mark Mitchell <mark at codesourcery dot com>]

Kaveh R. GHAZI wrote:

[Java folks: see below for check-in window for daylight savings time
patches.]

> Test results for sparc/sparc64 on solaris2.10 are here:
> http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00422.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00423.html

Thanks!

In general, I think it's too late to fix anything but the mostly truly
egregious problems at this point.  There have been lots of opportunities
to report problems in 4.1.2; at this point, I want to get it out the
door, and start pushing on 4.2.0.

> 1.  g++.dg/debug/debug9.C fails as described in PR 30649.  I believe this
> is simply a mistaken testcase checkin.  If confirmed by someone, no big
> deal I can remove it.

I think there's no question this is a bogus checkin.  I've removed the
testcase.

> 2.  g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC.

This appears to be another manifestation of the problem from PR 29487
(now fixed).  Here, the compiler is again making an unreasonably
conservative assumption that will substantially penalize C++ shared
libraries: namely, that all global functions in shared libraries may be
replaced at link time, and that callers must therefore assume that they
may throw exceptions.

You are correct that this stems from Richard's patch, though that patch
made sense on its own: he used the same rules for exceptions that were
otherwise used for const/pure functions.

I think the key flaw here is that we are using binds_local_p in two
different ways.  One way is to tell us what kind of references we can
emit; for a locally bound entity we may/must use certain relocations,
etc., that we cannot with a global entity.  However, I think it's
unreasonably pessimistic to say that just because the user might use the
linker to replace a function in some way, we can't reason from the
function's behavior.  If the user doesn't state that intent explicitly
(by declaring the function weak), I think we should be free to optimize
based on the body of the function.

I think that this suggests that even the definition of
DECL_REPLACEABLE_P that I checked in is too conservative.  Perhaps the
definition should simply be "DECL_WEAK (decl) && !DECL_COMDAT (decl))";
in other words, only explicitly weak functions are replaceable from an
optimization point of view.  It was weak functions that were the
motivation for the original change.

I would certainly appreciate comments from others about this issue.

I do think this is an important issue; it would be bad for Mozilla, KDE,
etc., to suffer a significant optimization issue in going from 4.1.1 to
4.1.2.  I was pretty determined to get 4.1.2 out the door, and I really
don't want to have any functional changes between the last RC and the
actual release.  So, I feel that I have no choice but to do a 4.1.2 RC3
with a more conservative version of DECL_REPLACEABLE_P.

Therefore, if the Java folks have daylight savings time patches that
they would like to check in, please do so before Monday evening,
California time.  If these work out, we'll leave them in for 4.1.2;
otherwise, we'll back them out.  We will not do an RC4 simply to correct
problems in these patches: the choices will be only to keep the patches
checked in or to take them out entirely.

> 4.  gcc.dg/tree-ssa/20030714-1.c fails with -fpic/-fPIC and this one
> appears to have regressed since the case is from 2003. 

This looks to be at worst a minor code quality issue.

> 6.  22_locale/num_put/put/wchar_t/14220.cc fails with sparc64 -fpic/-fPIC.

This is unfortunate, but I don't see any evidence of a major blocking
issue there.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713