This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH, FORTRAN] Class Name Clash


Hi Tobias,

On Thu, 10 Apr 2014 10:50:24, Tobias Burnus wrote:
>
> Bernd Edlinger wrote:
>> this patch fixes a recently discovered name-clash in gfc_build_class_symbol.
>>
>> Fortunately it is quite easy to fix: just make sure that the class names of target
>> classes end with "_t", and target array classes end with "[0-9]t".
>> This trick makes all names unique again.
>
> One thing which in general doesn't make it as simple is that it breaks the ABI for
> polymorphic variables.
>
> However, as I have already broken the ABI for polymorphic variables in order to
> support finalization (= destructors), doing another ABI breakage is no problem.
>
> As we do break the ABI, we also switched to compressed .mod files - hence, most
> code simply won't compile without recompiling the modules. Hence, there is no
> problem form that side and the the ABI notice at
> http://gcc.gnu.org/gcc-4.9/changes.html#fortran
> should be sufficient.
>
> Side note: I would really like if we could manage to create a GCC/gfortran
> version 4.x which is .mod-ABI compatible with 4.(x-1) but so far we failed to
> do so. And with the new array descriptor looming, either 4.9++ or 4.9+2 will
> break the ABI again.
>
>> I hope it is not too late, and this can still go into 4.9.0.
>> Boot-Strapped without any regressions on x86_64-unknown-linux-gnu.
>
> Regarding the patch: As Fortran is case insensitive, gfortran always stores
> identifiers as lower case. Thus, using something uppercase prevents problems.
>
> You also cannot blindly append characters as the values are fixed sized.
>
> Would it do to replace the existant appended "p" (pointer) and "a" (allocatable)
> by "P" and "A"? I think that should work as well and avoids the other issues.
>

I thought about that, too. But it is likely that the pattern for array of target class
"__class_%s_%d_%d" will eventually clash with the non-array target class "__class_%s"

If the class name is something like "test_1_1"

And I tried of course, to create an example that exceeds the name length, but that turned
out to be impossible, because get_unique_hashed_string keeps the string length small:

  /* If string is too long, use hash value in hex representation (allow for
     extra decoration, cf. gfc_build_class_symbol & gfc_find_derived_vtab).
     We need space to for 15 characters "__class_" + symbol name + "_%d_%da",
     where %d is the (co)rank which can be up to n = 15.  */

Thus for long names, the sting is replaced by sprintf (string, "%X", h);

(which may contain uppercase A-F).

This means that we should not have problems with the buffer length for
the target classes.

I think at least the pattern __class_%s_%d_%d needs to be replaced by something
like __class_%s_%d_%dT.

Would you prefer to change the letters to a->A p->P, and add an uppercase T to the
target array pattern, while keeping the name of the normal target class as it is?

If yes, I can change the patch accordingly. Please advise.

Thanks
Bernd.

> Tobias
 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]