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: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- To: "Tobias Burnus" <burnus at net-b dot de>
- Cc: "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 12:58:24 +0100
- 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=nAri9CdfHuWYltgIghFRIVJuNEAr+lfm/0rzFyO8k166W6axcPtNUN6GbHChAWkqRKOPy5wS17ND26eHbLDhNce5xmjDf0dSczJZpIPq+/mHyaKF0pHoD4ds2A14tU+kHOH/y/18zLnGZ7EYBxLi0Qsz7OiN2MOeL23adDSW0jg=
- 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=gMt2Ews0vyDW707P8se3sCgjgu3Kin82o6jbrRqrqVHkti7WSB9Q2bXPtBNfgaWrU7IVCxO+x+22dVkjPlJfyjOSiZn5oYnzvMYLUL6Hw9PK6pnMoiwASXrGdQNbVW+uZJOOZvMQQ3yvPqCCzirdR0z+R8ywZ6zKZsrcClR4Lco=
- References: <19c433eb0708270522m6211e7dx80381c39e8ac9b55@mail.gmail.com> <46D301C3.4040701@net-b.de>
> Compiles flne on x86-64. I will do some more testing and check the
> source code, but I think it is OK.
Thanks! I'll wait for your additional testing, of course.
> Since you now this part of trans-*.c well: Do you also plan to add
> "errmsg=" support to ALLOCATE and DEALLOCATE (F2003 feature)?
No, although it wouldn't be difficult. The problem is that stage2
closes soon, and I've integrated most of the things I thought nice to
implement, except one a tricky one: merging of function decls, which
is proving to be rather tricky. I think, from now on, I'll be focusing
on that one to get it before stage2 closes. I'm not sure I'll make it,
though :(
> 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.
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.
FX