Re: API change between GCC 12.3.0 and 13.2.0?

[Gaius Mulley]

Benjamin Kowarsch <trijezdci@gmail.com> writes:

> 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

Hi,

I guess one of the problems with non-standard extensions using keywords
is that there is some indirection leading to differing default
expectations of what is implied by the use of the FOR "C" with
UNQUALIFIED/QUALIFIED.  In particular the intersection between two
extensions :-)

Therefore I wonder whether it might be pragmatic to migrate to the <*
attribute *> mechanism to select features rather than rely on the FOR
"C" and UNQUALIFIED keywords to turn on/off features.  The UNQUALIFIED
extension (a keyword not in iso or pim) pre-dates the iso standard.
Given iso allows for <* *> I propose the following:

  (i)   introduce attributes to explicitly control
  the behaviour of the definition module.  For example
  gcc/m2/gm2-libs/libc.def would start:

DEFINITION MODULE libc ;

<* name_mangling (FALSE); calling_convention ("C");
   module_registration (FALSE) *>

FROM SYSTEM IMPORT ADDRESS ;

PROCEDURE read (fd: INTEGER; buf: ADDRESS; nbytes: INTEGER) : [ INTEGER ] ;

  ...

  (ii)  also allow:

PROCEDURE foo <* mangle_name ("$foo%bar") *> (a, b: CARDINAL) ;

  (iii) the <* *> directives in (i) and (ii) cannot be used with
  FOR "C" or EXPORT UNQUALIFIED.  Over time the FOR "C" and
  UNQUALIFIED will be deprecated and then removed.

The advantages of this approach are that only one or two hunks of
definition module text need to be changed and at the top of the source -
no awkward lists of identifiers need be constructed.  It also provides
backwards compatibility (modulo deprecation).  It would also be pretty
easy to generate a tool to convert any current definition module into
the directive equivalent (if required) and the directives are also more
direct and precise.

Anyway just a proposal

regards,
Gaius