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

[Tobias Burnus <burnus@net-b.de>]

Tobias Schlüter wrote:
> On 2010-11-07 13:04, Janus Weil wrote:
>>>> Yes, that is expected, because the patch changes the name of the vtab
>>>> to "vtab$main$dt", so one needs to change the name of the subroutine
>>>> in the test case in the same way in order to see the failure:
>
> Sorry I'm late, but gcc has the macro ASM_FORMAT_PRIVATE_NAME which does
> the work of making a name collision-free. If you use it you can make the
> rest of the name as readable as you want.

I think that it won't work. One needs the same assembler name for in 
each translation unit as there is one, common, global vtable per base 
type. My understanding is that ASM_FORMAT_PRIVATE_NAME would generate 
several disjunct assembler names...

>> The best option I can currently see is to use leading underscores (as
>> in "_vtab_main_dt"). This is forbidden in Fortran (cf. F08:R303), but
>> accepted by the assembler (cf.
>> http://sourceware.org/binutils/docs-2.20/as/Symbol-Names.html#Symbol-Names).
>>
>> Attached is a patch which does this change. I also added a few macros
>> in gfortran.h. Ok for trunk after successful regtest?

+static void
+get_unique_type_string (char *string, gfc_symbol *derived)
+{
+  if (derived->module)
+    sprintf (string, "%s_%s", derived->module, derived->name);
+  else
+    sprintf (string, "%s_%s", derived->ns->proc_name->name, derived->name);
+}

I wonder whether that works for cases like:

* module name == procedure name
* internal procedures == procedure name / module name.
* Nested submodules (when implemented)

I assume defining the same-named (and disjunct) DT in a module and 
separately in a subroutine is weird; with internal procedures and 
submodules it will start to get crazy. But shouldn't one do something 
like _proc_<procedure_name> for procedures? A {module/procedure 
name}_internal-proc-name?

Alternatively, one can defer it until a real-world bug report comes 
(which I think is very unlikely).

(And, at some point, the name becomes too long and one could think of 
using a hash name as in GCC's C++ compiler.)

Tobias