This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran,patch] Inline remaining allocation/deallocation routines
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- Cc: "Tobias Burnus" <burnus at net-b dot de>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 Aug 2007 14:04:54 +0200
- Subject: Re: [gfortran,patch] Inline remaining allocation/deallocation routines
- 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=NWWCXtN/hmtR+5ytikx0ZXI7fPGh+UEsYUDu5ffXvyVvODrBuUEDLGEvjLRwB3jEPAWLRUVEhovW8RDjSDEw6SnJU4y8LyHtW/Cjr9AbrC6kvsCDZOrdh/1auqIusBInQJyalxnpU8cilrSqQUiS1InGgQUcfntQpDWGrzT7Hgw=
- 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=AcufhoIjAs+V2vEdjNTFxDtQm9GKWRybE54wQhTXccUCJXBM/ltgOf5mCAvJr1IqtAxlWoO3U5nBY2CDpYOrCIOb5Vam3OYtmLTl0KHreMzYWW0W/Jjk+kbeZoaH7k5v2BOJFhygSKUyLS2iedosbGWSz7ysk0oUcSV0KYjYzRE=
- References: <19c433eb0708270522m6211e7dx80381c39e8ac9b55@mail.gmail.com> <46D301C3.4040701@net-b.de> <19c433eb0708280458n5eaf9faaq8c2f718aca27f56c@mail.gmail.com>
On 8/28/07, François-Xavier Coudert <fxcoudert@gmail.com> wrote:
> > By the way, somehow the middle end fails to optimize away the "if(a.data
> > != NULL)" branch although the variable has been initialized to NULL
> > before. With my little C program it works (even w/o using the "restrict"
> > attribute). We should fill a middle end PR when this is checked in.
I guess that 'a' is a global? (Do you have a fortran testcase that shows this?)
> Probably because we call a function with a pointer to a somewhere
> (I/O?) which cannot lead to modification according to Fortran rules,
> but we don't correctly give this information to the middle-end. There
> are several such missed-optimizations throughout the front-end, I
> think.
Zdenek posted a patch with infrastructure to support this more easily, but it
didn't get approved yet.
Richard.