Re: GCC 4.1.2 RC2
Mark Mitchell writes: Kaveh R. GHAZI wrote: [Java folks: see below for check-in window for daylight savings time patches.] 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. Done. Andrew.
Re: GCC 4.1.2 RC2
Ian, Richard, Diego --
I've explicitly forwarded this to you, as folks who have done work on
middle-end optimization and have seen lots of real-world code.
(That's not to say that I'm not looking for comments from anyone and
everyone -- but I'm specifically trying to get at least some feedback,
so I'm picking on some likely candidates. :-))
Do you have any thoughts on the comments quoted below? Does it seem
overly aggressive to you to assume f cannot throw in g, given:
void f() {}
void g() { f(); }
where this code is in a shared library? Of course, with DWARF2 EH, the
cost is mostly in terms of code size; whereas with SJLJ EH it's also
execution time. Is it silly for me to be worrying about this
pessimization in 4.1.2?
Thanks,
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.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
Does it seem overly aggressive to you to assume f cannot throw
in g, given:
void f() {}
void g() { f(); }
where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
the shared library, one should be able to replace it with
any valid function.
If the shared library needs F to not be able to throw, then
one can just as easily define the function interface to be
void f() throw();
If F was mistakenly placed in the overridable interface of
the shared library, then the fix is elsewhere.
r~
Re: GCC 4.1.2 RC2
Richard Henderson wrote:
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
Does it seem overly aggressive to you to assume f cannot throw
in g, given:
void f() {}
void g() { f(); }
where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
the shared library, one should be able to replace it with
any valid function.
I understand that people do this for C code (e.g., replace memcpy, or
other bits of the C library). Those routines aren't generally
manipulating global data; they're often stand-alone APIs that just
happened to be grouped together into a single library.
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility attributes? But,
presumably, most people don't replace the implementation of
ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here,
but I'd be surprised if there aren't large amounts of legacy code that
would be hurt by this change. Do you disagree?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC 4.1.2 RC2
Mark Mitchell [EMAIL PROTECTED] writes: But, aren't big C++ shared libraries rather different? Does KDE actually use throw() everywhere, or visibility attributes? But, presumably, most people don't replace the implementation of ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, but I'd be surprised if there aren't large amounts of legacy code that would be hurt by this change. Do you disagree? I don't really have any doubt that somebody, somewhere, wants to override a function in a C++ shared library, and wants the overriding function to throw an exception. There is really only one correct compiler behaviour here. But if gcc 4.1.1 behaved one way with regard to overriding a function with a function that throws an exception, I think we can probably get away with having gcc 4.1.2 behave the same way. It should ideally be recorded as a known issue somewhere, though. Ian
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: But, aren't big C++ shared libraries rather different? Does KDE actually use throw() everywhere, or visibility attributes? But, presumably, most people don't replace the implementation of ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, but I'd be surprised if there aren't large amounts of legacy code that would be hurt by this change. Do you disagree? I don't really have any doubt that somebody, somewhere, wants to override a function in a C++ shared library, and wants the overriding function to throw an exception. There is really only one correct compiler behaviour here. I strongly agree that there is only one correct behaviour here. If KDE doesn't use throw(), or visibility attributees, that's a failing in KDE, not the compiler. r~
Re: GCC 4.1.2 RC2
On Mon, Feb 12, 2007 at 01:30:41PM -0800, Richard Henderson wrote: On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: But, aren't big C++ shared libraries rather different? Does KDE actually use throw() everywhere, or visibility attributes? But, presumably, most people don't replace the implementation of ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, but I'd be surprised if there aren't large amounts of legacy code that would be hurt by this change. Do you disagree? I don't really have any doubt that somebody, somewhere, wants to override a function in a C++ shared library, and wants the overriding function to throw an exception. There is really only one correct compiler behaviour here. I strongly agree that there is only one correct behaviour here. If KDE doesn't use throw(), or visibility attributees, that's a failing in KDE, not the compiler. Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? If so, then it might be better to push the fix that allows overrides that throw back to 4.2, and circulate warnings to affected projects that they will want to use throw() and attributes more, giving them until 4.2 to fix any issues found.
Re: GCC 4.1.2 RC2
Richard Henderson wrote: On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: But, aren't big C++ shared libraries rather different? Does KDE actually use throw() everywhere, or visibility attributes? But, presumably, most people don't replace the implementation of ScrollBar::ScrollUp or whatever. I'd be happy to know I'm wrong here, but I'd be surprised if there aren't large amounts of legacy code that would be hurt by this change. Do you disagree? I don't really have any doubt that somebody, somewhere, wants to override a function in a C++ shared library, and wants the overriding function to throw an exception. There is really only one correct compiler behaviour here. I strongly agree that there is only one correct behaviour here. If you both feel that way, it's good enough for me. As a long-time C++ programmer, I'd sure be surprised to find that my code was optimized substantially differently -- in this kind of high-level way, not just at the lower levels of addressing modes and such -- just because I added -fpic to the command-line, but so be it. In that case, I'll not make any further changes in this area. I can't really guarantee that any change I would make to 4.1.2 would restore exactly identical behavior to the 4.1.1 release without backing out other larges bits of infrastructure. And, since we think this is the behavior we want going forward, I think we may as well just go with it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC2
Joe Buck wrote: If KDE doesn't use throw(), or visibility attributees, that's a failing in KDE, not the compiler. Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? Yes. On workstation and server systems, most of the issue will be somewhat larger binaries. On embedded systems, code space is more precious, so there might be more impact. The impact will be greatest on SJLJ systems with shared libraries if such things exist. However, there are as far as I know, zero reports of this as an actual problem in practice. Any impact is likely to vary greatly from library to library. And, many users concerned about code size are going to have turned off EH altogether. So, I don't think we should further hold things up. If so, then it might be better to push the fix that allows overrides that throw back to 4.2, and circulate warnings to affected projects that they will want to use throw() and attributes more, giving them until 4.2 to fix any issues found. I don't think that's very practical. We'd have to back out some of the other changes that were made since 4.1.1, and in so doing we'd lose bug fixes for (other) correctness issues. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.2 RC2
Joe Buck wrote: Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings? On Mon, Feb 12, 2007 at 01:53:10PM -0800, Mark Mitchell wrote: Yes If so, then it might be better to push the fix that allows overrides that throw back to 4.2, and circulate warnings to affected projects that they will want to use throw() and attributes more, giving them until 4.2 to fix any issues found. I don't think that's very practical. We'd have to back out some of the other changes that were made since 4.1.1, and in so doing we'd lose bug fixes for (other) correctness issues. OK, I withdraw the suggestion. It's worth mentioning in release notes though.
Re: GCC 4.1.2 RC2
On Fri, 9 Feb 2007, Mark Mitchell wrote: GCC 4.1.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208 and its mirrors. The changes relative to RC1 are fixes for: 1. PR 29683: a wrong-code issue on Darwin 2. PR 30370: a build problem for certain PowerPC configurations 3. PR 29487: a build problem for HP-UX 10.10 a code-quality problem for C++ on all platforms If you find problems in RC2, please file them in Bugzilla. For any issues which are regressions relative to 4.1.1 or 4.1.0, please alert me by email, referencing the Bugzilla PR number. Please do not send me email before filing a PR in Bugzilla. Based on the absence of issues reported for GCC 4.1.2 RC1, I expect GCC 4.1.2 to be identical to these sources, other than version numbers, and so forth. I intend to spin the final release early next week. Thanks, Mark Mitchell 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 Comparing this to previous 4.1.x there are a few new failures: 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. 2. g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC. This seems to be a regression and started sometime between Oct 8 and Nov 2, 2006. I don't have historical test results any finer grained than that and I don't think other solaris2 testers use -fpic/-fPIC. Here are my posts from that time: http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00509.html http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00076.html If I had to guess, I'd say it started with this checkin: 2006-10-14 Richard Guenther [EMAIL PROTECTED] PR rtl-optimization/29323 * decl.c (finish_function): Set TREE_NOTHROW only for functions that bind local. And as with some -fpic/-fPIC failures, there's a chance it's simply a problem with the testcase that's incompatible with pic, not a problem with the compiler. If so we can adjust the testcase code or simply skip it when using pic. 3. gcc.c-torture/execute/20061101-1.c is a new failure at -O2 and at more opt levels with -fpic/-fPIC, but that testcase is from November so it's probably not a regression. 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. It started failing between June 18 and June 22, 2006 in the 4.1.x branch: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01003.html http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01167.html 5. gfortran.dg/cray_pointers_2.f90 fails with -fPIC (not -fpic). The error message is: ld: fatal: too many symbols require `small' PIC references: have 4604, maximum 2048 -- recompile some modules -K PIC. collect2: ld returned 1 exit status This one appears to be a regression from previous 4.1.x and 4.0 where it works. It looks like it started between June 18 and June 22, 2006: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01003.html http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01167.html 6. 22_locale/num_put/put/wchar_t/14220.cc fails with sparc64 -fpic/-fPIC. The sparc32 doesn't fail. This is a regression from the previous 4.1 release and 4.0.x. The testsuite logfile doesn't say anything about what failed. It started failing sometime between Oct 8 and Nov 2, 2006, which like #2 above has a wide gap between my historical test posts. http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00509.html http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00076.html I don't know whether any of these are important enough to hold up the release, most appear not. Maybe Eric can comment. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC 4.1.2 RC2
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. Looks bogus to me like the 2 other testcases. 3. gcc.c-torture/execute/20061101-1.c is a new failure at -O2 and at more opt levels with -fpic/-fPIC, but that testcase is from November so it's probably not a regression. This is a real failure at -O2, caused by a bad iteraction between the old loop optimizer and the insn cost settings in the SPARC back-end. But it's not a regression in the 4.x series. Of course it will be gone in 4.2 and later. I wrote a patch for the back-end at some point, but the problem is really in the old loop optimizer. I think we can simply mark it as XFAIL on SPARC. I don't know whether any of these are important enough to hold up the release, most appear not. The -fpic/-fPIC failures are a little annoying but other platforms probably have similar glitches, so we can live with them (I personally don't test with -fpic/-fPIC so I have only the above 2 failures in my logs). Results on other versions of Solaris are on par with those on Solaris 10. -- Eric Botcazou
Re: GCC 4.1.2 RC2
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
Re: GCC 4.1.2 RC2
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. What about the patch for PR other/27843 then? -- Eric Botcazou
Re: GCC 4.1.2 RC2
On Fri, 2007-02-09 at 13:36 -0800, Mark Mitchell wrote: GCC 4.1.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208 and its mirrors. On a recent ubuntu x86_64 system, with c,ada,c++,fortran,java,objc: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00377.html Only three unexpected failures: === libmudflap tests === FAIL: libmudflap.c/fail8-frag.c (-static) output pattern test FAIL: libmudflap.c/fail9-frag.c (-static) output pattern test === libstdc++ tests === FAIL: abi_check Laurent
Re: GCC 4.1.2 RC2
On Fri, Feb 09, 2007 at 01:36:00PM -0800, Mark Mitchell wrote: GCC 4.1.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208 OK, I untarred it, built, and tested. I have test results for all languages except Ada, for RHEL 3 (ancient, but with binutils-2.17), on a 32-bit and 64-bit x86. i686-pc-linux-gnu results are at http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00367.html (no failures). x86_64-unknown-linux-gnu results are at http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00350.html and there is only one failure, a Java test: FAIL: FileHandleGcTest -O3 execution - bytecode-native test
