Richard Guenther wrote: > On Sun, Jan 18, 2009 at 2:04 AM, Dave Korn >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903 > > I guess the second one is a regression? Please mark the PR as such if this > is the case.
:) No need now, ... >> for which I have submitted one patch so far: ... I got the OK so applied the patch and RESO FIXE the bug. (Simple target-specific fix, approved by both target and libiberty maintainers). >> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00896.html >> >> and am working on a second now for PR37660. Now submitted (http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00920.html), again, only touches target-specific code. >> There is also a problem that is not a regression but a non-conformance >> issue in a new feature; the shared libgcc DLL built on Cygwin does not adhere >> to the naming conventions for the platform. See PR: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904 >> >> for which I will also shortly submit a patch, to be applied optionally on top >> of the 37660 fix. > > Is this an ABI break from 4.3 then? You should make sure to note this in > the release notes. No, it's a new feature that has just been added; the code is shared between Cygwin and MinGW, and it does things the right way for MinGW but the wrong way for Cygwin. If 4.4 goes out with this mis-named DLL, there will be an ABI break between it and 4.5 when we correct the naming scheme; everyone will have built executables that link against the mis-named DLL and they'll all have to rebuild against the new DLL or we'll have to support the incorrect DLL as legacy for who knows how long; it's a nasty mess that would be much better off avoided by getting the feature right in the very first release to add it. I don't know, can I call this a regression or would it stretch the definition? A build of GCC didn't used to produce any misnamed DLLs, and now it does... of course, that's because it didn't used to produce any kind of DLL at all! >> If I understand rightly, it is the case that target maintainers are allowed >> some leeway in what to accept during stage 4, in which case I would like to > > Correct. :) I'll try not to ask for /too/ much! > I don't think we will freeze before 4.3.3 is finally out (which I would expect > at the end of this week). But I wouldn't take bets on being in stage4 > at Feb 1st ;) That gives me a reasonable amount of headroom, I think. Thanks! cheers, DaveK
