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: "Tobias Burnus" <burnus at net-b dot de>
- Cc: "François-Xavier Coudert" <fxcoudert at gmail dot com>, "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: Thu, 30 Aug 2007 16:50:13 +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=qLuD+EEezImYStB6EX3XmSz7Ct0vPQIffICWGW03rhWNjpSQD3y+/IWbApwMLI/M60DUHy6wwQZDApnqNDzuZy+bbsxpkSpmFXLLy9pRkLzdZ7CXEAsCqyNd22CIXYdsCg/0SWn8kvpH60UEjuyMp61tr4OLZfctWcQlKWYZt0M=
- 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=DUgp/D1CzbtNjw6Go7ZJcJ8JLgnOZ0MoJ0KXwAsMBUKhQvBuU6vz+pDsYwCLN/ndCqyFL4v6DXgg883AKCBPi41/MPgyi+xltWIzToh6QATCvAdo3tMLJNJaNBwNrPBK32Fc/LV6Bf7nWyc9rTL0Z/fQP8Awf8wxa9VHIfIrs0w=
- References: <19c433eb0708270522m6211e7dx80381c39e8ac9b55@mail.gmail.com> <46D301C3.4040701@net-b.de> <19c433eb0708280458n5eaf9faaq8c2f718aca27f56c@mail.gmail.com> <84fc9c000708280504n3dfaf4e1mb83be9c89ee28210@mail.gmail.com> <46D4226C.1010108@net-b.de>
On 8/28/07, Tobias Burnus <burnus@net-b.de> wrote:
> Richard Guenther wrote:
> > 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?)
> >
>
> I assume in the following that FX's patch has been applied.
>
> ------------ (a) --------------------
> integer, allocatable :: a(:),b(:)
> allocate(a(5),b(5))
> end
> -------------------------------------
>
>
> The problem presumably is the "_gfortran_os_error()" call inbetween. Is
> there the possibility to set the pointers "a" and "b" as "restrict"ed?
> Fortran standard mandates that to an allocatable array, a pointer only
> may point to when it is marked as TARGET. (I don't know whether
> front-end generated code aliases, I think it does not.)
>
> Additionally, is there the possibility to mark the
> "_gfortran_os_error()" as a routine having no side effects - or in this
> special case - as not returning?
I see we produce (with -O):
<bb 2>:
_gfortran_set_options (7, &options.0);
D.1383 = __builtin_malloc (20);
if (D.1383 == 0B)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});
<bb 4>:
D.1385 = __builtin_malloc (20);
if (D.1385 == 0B)
goto <bb 5>;
else
goto <bb 6>;
<bb 5>:
_gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});
<bb 6>:
__builtin_free (D.1383);
__builtin_free (D.1385) [tail call];
return;
which looks ok. The above could use the same call to _gfortran_os_error though,
by making the function pure. Though at the tree level no optimization would do
this transformation leaving only possibly rtl cross-jumping to do
this, but I have
no idea if that can exploit the no-return and the pureness of calls ;)
Richard.