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
