[Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

[Janus Weil]

Hi all,

with the test cases in this PR Tobias demonstrated that our naming
scheme for class containers and vtables is insufficient. It currently
is based only on the type name. As shown in the PR, naming ambiguities
can be created, e.g. by setting up two derived types with identical
names in different modules, and use-renaming them in the main program.

The patch avoids these naming ambiguities by including the module name
in the naming scheme for class containers and vtabs. Example:

module mo
type :: dt
  ! ...
end type
class(dt), pointer :: cp
end module

Without the patch, the class container name is "class$dt", with the
patch it will be "class$mo$dt". This makes sure that we get one unique
class container and vtab for each derived type, even with renamed
derived types.

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2010-11-06  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46313
	* class.c (get_unique_type_string): New function.
	(gfc_build_class_symbol): Use 'get_unique_type_string' to construct
	uniques names for the class containers.
	(gfc_find_derived_vtab): Use 'get_unique_type_string' to construct
	uniques names for the vtab symbols.

2010-11-06  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46313
	* gfortran.dg/class_28.f03: New.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr46313.diff
Type: application/octet-stream
Size: 4820 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20101106/272a70a7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: class_28.f03
Type: application/octet-stream
Size: 528 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20101106/272a70a7/attachment-0001.obj>