This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR29786 - [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
- From: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- To: "Brooks Moses" <brooks dot moses at codesourcery dot com>
- Cc: fortran at gcc dot gnu dot org
- Date: Fri, 25 May 2007 10:21:15 +0200
- Subject: Re: [Patch, fortran] PR29786 - [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ch9NcFvdBa3wNFVbGlM1Kecr43m9+wG+QA/ndejWhu+EA40FvhcW/YuLEYIHHky3qpBYjWC8JuJEJXTfxYKmLgFvmrgU4+oImJmMRxMh5x9I60NklgMUyzHKxl+w9NNDPEoQlerbqxEQ+1DHlplohXoZdhjd/XzBQ2MFh4s9QBw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fox0pFOAfBMdix279cjqKvBE0fughhf6eaX4SwQ3+aUwhpMQpWNTLkpMaDR5gQgWDMrOifdu9lPyU5VVBHwa/quA3xQuCjyYerZvXFOp+SfhfXhKQt0L6orS3Xcwq57ON4d9cvNXv/xsFIcitwjwUHIxNpgKl2Dix0igJH1K+18=
- References: <339c37f20705240554o50ffce63uf7e54762e5ad264a@mail.gmail.com> <46567C52.4010301@codesourcery.com> <20070525063512.GA37338@troutmask.apl.washington.edu> <46568920.4080107@codesourcery.com>
If you can keep everything within the fortran
front-end code, then I'd support the backport (although it
isn't technically a regression).
I am against this backport: the memory-representation code is widely
untested, especially on cross-compiling setups and unusual archs; for
a change that invasive, I don't think enough dust has settled.
Moreover, 4.2.0 was released, and we really shouldn't be introducing
new features. Many distros apparently intend to skip the 4.2 branch
entirely, and 4.3 sources and binaries are available to people who
need the new functionality (and we know that these mainline binaries
have been heavily used).
Now, on a view that has more to do with strategy and
resources-planning than with actual code quality. I believe it is
within our reach to make 4.3.0 an extra-good release, and all effort
spent on the 4.2 branch after the 4.2.0 release, for things that are
not regressions wrt 4.1.x or 4.0.x, would be better spent elsewhere.
That being said, there are maintainers enough supporting this backport
that you can do whatever is decided, no need to worry about my
objection.
FX