This is the mail archive of the
mailing list for the Cygwin project.
Re: GCC-4.7.2-2: Go/No-go?
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 12 Apr 2013 07:47:07 +0100
- Subject: Re: GCC-4.7.2-2: Go/No-go?
- References: <51643F10 dot 7000905 at gmail dot com> <87eheixuz8 dot fsf at Rainer dot invalid> <20130410154730 dot GA404 at ednor dot casa dot cgf dot cx> <516599BE dot 7090000 at gmail dot com> <51661EA2 dot 1070801 at users dot sourceforge dot net> <51665212 dot 6050101 at gmail dot com> <51665F0F dot 8040902 at users dot sourceforge dot net> <20130411101342 dot GA12461 at calimero dot vinschen dot de> <5166A928 dot 8030805 at gmail dot com> <20130411121925 dot GA24666 at calimero dot vinschen dot de> <5166ADBA dot 9000807 at gmail dot com> <5167201E dot 4090405 at towo dot net>
On 11/04/2013 21:42, Thomas Wolff wrote:
> Am 11.04.2013 14:34, schrieb Dave Korn:
>> Also, I don't plan on doing it unless there's significant demand.
> I would appreciate to keep it as gcc-3.
Fancy being the maintainer for it then? ;-)
> The reason is quite peculiar; gcc-4
> changed the order of variables in the stack frame of a function call, which
> led to one very specific interworking malfunction (between mintty and
> mined) which in turn unveiled a very subtle bug. This is material for very
> interesting debugging exercises for students... Not sure whether it's
> significant but the changed variable order might in fact affect other
> software as well. ------ Thomas
Only seriously buggy software. Anything in a C program that attempts to
make inferences about the layout of the stack frame is invoking undefined