On Mon, 18 Dec 2023 at 07:59, Michael Riedl wrote:
I have the same issue - all my binding (in may case mostly to Fortran
<snip>
... what are the benefits of adding an "EXPORT QUALIFIED" statements
EXPORT is not a statement but a directive.
to an interface to another language which never prefixed ("C") or,
in case of Fortran Modules, in a different way ?
I agree with the notion that it makes no sense for a Modula-2 compiler to
generate prefixed names from an interface to a library in a language that
doesn't use name mangling or that uses a different name mangling convention.
Generating names that comply with the calling convention of the interfaced to
language should be the purpose of the FOR "language" directive in the module
header. And calling convention does not only consist of parameter passing, it
also means matching any name mangling convention of the interfaced to language.
In M2R10 we specified the FFI directive in the module header this way.
INTERFACE MODULE Foo <*FFI="C"*>;
(* foreign function interface to C, including C naming *)
Suppose, the foreign library uses names that we cannot express in Modula-2
due to characters being allowed in identifiers that are not legal in Modula-2,
or we simply want to make the Modula-2 side source code comply with
Modula-2 naming conventions. In this case, it makes far more sense to
provide a directive to specify the illegal or unliked foreign name within
a declaration that introduces that name:
PROCEDURE FooBarBaz <*FFINAME="FOO$BAR_BAZ"*> ( bam : Bam; boo : Boo );
But even in that case, the compiler should generate a name for FOO$BAR_BAZ that
complies with any name mangling convention of the language specified in the FFI
directive in the module header. No other directive to interfere with that mechanism.
I cannot think of any use case where one might want or need to generate a mangled
name for a foreign library object of a language that doesn't use name mangling, as
is the ase with C. However, even if there was such a use case, it should be dealt
with in a different manner and it should certainly not be default behaviour. It should
be exceptional behaviour triggered by a directive specifically provided for that purpose.
PROCEDURE Foobar <*NAMEMANGLING=ON*> ... ;
or something like that.
In summary, I would consider the observed behaviour a bug, not a feature.
regards
benjamin
Am 12.12.23 um 22:22 schrieb Philip Munts:
> It appears to me that in GCC 12.3.0, externals declared in a C binding
> module (DEFINITION MODULE FOR "C") are not mangled, but in GCC 13.2.0
> they *are* mangled, prefixing the module name.
>
> Given:
>
> DEFINITION MODULE FOR "C" Foo;
>
> PROCEDURE Bar;
>
> END FOO;
>
> Linking a program that calls Foo.Bar in 12.3.0 requires the external C
> function to be named Bar while 13.2.0 requires it to be Foo_Bar.
>
> This is a severe pain in the neck, as I have a substantial number of
> such C binding modules that all have to be rewritten for GCC 13,
> adding EXPORT QUALIFIED for every C external. I opine that external C
> names should never be mangled...
>
> Phil
>