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

[Tobias Burnus]

Janus Weil wrote:
> The patch avoids these naming ambiguities by including the module name
> in the naming scheme for class containers and vtabs.
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

OK.

I think we can worry about submodules and similar problem later - when 
real-world programs pop up which use them. At least there is then only a 
single place to change.

Regarding $ vs. period vs. _: Seemingly, all platforms on which gfortran 
is used support the $ as there was not bug report so far. Thus, I think 
we can continue using it. Regarding user code: I somehow think it is 
unlikely that users have that strange variable names; if they do: It's 
their fault as $ is an not allowed in ISO Fortran.

Janus Weil wrote:
 > Btw, what is the reason for the macro adding *two* underscores in
 > front, instead of just one?

C allows leading underscores -- and according to the ISO C standard, 
identifiers which start with two underscores are for the internal use of 
the compiler.

Steve Kargl wrote:
> A leading underscore moves the issue from -fdollar-ok to
> -fleading_underscore.

Well, there is a difference. Many compilers support a $ sign - some also 
as first character (gfortran does not!). Most compilers do not support 
leading underscores; gfortran's -fleading_underscore only exists to 
generate (before BIND(C) was implemented) __gfortran_... procedures. 
-fleading_underscore is also not officially supported (e.g. it is not in 
the man page) - and there are some compile-time restrictions.

I also do not think we need to explicitly take care of leading 
underscores  (which can also be reached via BIND(C)) or $. If a user 
wants to shoot into his foot, the compiler does not need to prevent it. 
-- It just shouldn't encourage it. And if possible, standard conforming 
code should not break. If users plays around with __vtab$... I think its 
their fault.

Tobias