This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC 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
- 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