This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.4.0 Status Report (2009-01-06)
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