Hi Thomas,
please note: This is not a review. I don't have the privileges to do so.
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. 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, vector instructions or whatever. At least it has the potential.
with (u_)name+1 we always have an uneven start address and I doubt
strncpy can use an optimized copy algorithm. I know, that now we copy
one byte twice, but that shouldn't really matter.
Besides my ideas above the patch and test looks ok to me (I didn't do a
regtest though).
Regards,
Andre
On Thu, 4 Feb 2016 23:03:13 +0100
Thomas Koenig <tkoe...@netcologne.de> wrote:
> Hello world,
>
> For a type 'foo', we use a symtree 'Foo'. This led to accept-invalid
> when a variable name was already declared as a type. This rather
> self-explanatory patch fixes that.
>
> Regression-tested. OK for trunk and 5? (Do we still care about 4.9?)
>
> Regards
>
> Thomas
>
>
> 2016-02-03 Thomas Koenig <tkoe...@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 <tkoe...@gcc.gnu.org>
>
> PR fortran/60526
> * gfortran.dg/type_decl_4.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
