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 [EMAIL PROTECTED] (650) 331-3385 x713
