[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