[patch, Fortran] Fix PR 60526, variable name has already been declared as a type

Thomas Koenig tkoenig@netcologne.de
Sat Feb 6 20:20:00 GMT 2016


Hi Andre,

> In preventing memory clutter I like to advise the use of:
>
> char u_name[GFC_MAX_SYMBOL_LEN + 1];
>
> and safe us all the dynamic memory allocation/free.

We're really talking micro-optimizations here, but well ... ;-)

In the attached patch, I have replaced this with alloca.  I was going
to  use a VLA originally, but apparently C++ doesn't like that, at least
not in the version that we use within C++.

I think this is the right idiom for a throw-away variable like this.
I also found 15 instances of alloca in fortran, so it is OK to use.

> Furthermore, how
> about switching:
>
>    strncpy (u_name, name, nlen+ 1);
>    u_name[0] = TOUPPER(u_name[0]);
>
> that way strncpy() can use its full power and copy aligned data using
> longs,

I don't think this would have mattered for an array of char
(these are usually not aligned).  However, a pointer using alloca
should be aligned, so this could be used.

So, here's the new version.

OK for all trunk and 5?



>> 2016-02-03  Thomas Koenig  <tkoenig@gcc.gnu.org>
>>
>>           PR fortran/60526
>>           * decl.c (build_sym):  If the name has already been defined as a
>>           type, issue error and return false.
>>
>> 2016-02-03  Thomas Koenig  <tkoenig@gcc.gnu.org>
>>
>>           PR fortran/60526
>>           * gfortran.dg/type_decl_4.f90:  New test.
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: p3.diff
Type: text/x-patch
Size: 1025 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20160206/d1505169/attachment.bin>


More information about the Fortran mailing list