This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR29786 - [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Brooks Moses <brooks dot moses at codesourcery dot com>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, "fortran at gcc dot gnu dot org List" <fortran at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 24 May 2007 23:35:12 -0700
- Subject: Re: [Patch, fortran] PR29786 - [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
- References: <339c37f20705240554o50ffce63uf7e54762e5ad264a@mail.gmail.com> <46567C52.4010301@codesourcery.com>
On Thu, May 24, 2007 at 11:04:02PM -0700, Brooks Moses wrote:
>
> I have been thinking about it, though. It's quite possible to backport
> most of the target-memory stuff without touching the existing code much
> at all, at the cost of having a little bit of extra code duplication
> between the Fortran front end and the middle end. (On mainline, the
> right thing to do was to consolidate the duplicated parts into shared
> functions. On a release branch, I believe the right thing is to leave
> them separate, so as not to muck about with things more than is needed.)
> Thus, this should be a low-risk backport, despite the size of the patches.
>
> Comments?
>
On a release branch, we (the gfortran gang) have been somewhat
cavalier with backporting with respect to release branch
rules (If it's a bug, we fix it). I doubt you'll be able to
get the non-fortran code into the release branch without much
discussion. If you can keep everything within the fortran
front-end code, then I'd support the backport (although it
isn't technically a regression).
--
Steve