[Bug modula2/108183] New: wrong code generated in the modula2 scaffold mechanism

[Bug modula2/108183] New: wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

            Bug ID: 108183
           Summary: wrong code generated in the modula2 scaffold mechanism
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: gaius at gcc dot gnu.org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

On m32 Darwin, we see very many failures like:
/Volumes/ramdisk/ccPnX6B8.s:379:non-relocatable subtraction expression,
"__M2_dtoa_ctor" minus "L5$pb"
/Volumes/ramdisk/ccPnX6B8.s:379:symbol: "__M2_dtoa_ctor" can't be undefined in
a subtraction expression

===

It seems that the function declarations for '__M2_dtoa_ctor' (and other
imported module ctors) are declared with TREE_STATIC() set, which indicates
that there is a definition in the TU  (which there is not) - they should be
declared as external.

So far, I could not figure out where these decls are built and what controls
whether they are considered external or not.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Target|                            |i686-darwin, powerpc-darwin
   Last reconfirmed|                            |2022-12-19
             Status|UNCONFIRMED                 |NEW

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
example:
a-hello.s:217:2: error: symbol '__M2_termios_ctor' can not be undefined in a
subtraction expression
        leal    __M2_termios_ctor-L5$pb(%eax), %edx     #, _T53_57


(lldb) p (void) debug_tree(decl)
 <function_decl 0x1068c5100 _M2_termios_ctor
    type <function_type 0x106829dc8
        type <void_type 0x1068250a8 PROC VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1068250a8
            pointer_to_this <pointer_type 0x106825150 ADDRESS>>
        QI
        size <integer_cst 0x106802d98 constant 8>
        unit-size <integer_cst 0x106802db0 constant 1>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x106829dc8
        arg-types <tree_list 0x10681cde8 value <void_type 0x1068250a8 PROC>>
        pointer_to_this <pointer_type 0x106850dc8>>
    addressable public static QI (null):0:0 align:8 warn_if_not_align:0 context
<translation_unit_decl 0x10680d168 D.46>
    (mem:QI (symbol_ref:SI ("_M2_termios_ctor") <function_decl 0x1068c5100
_M2_termios_ctor>) [0  S1 A8]) chain <function_decl 0x1068c5000 _M2_RTco_fini>>

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #2 from Gaius Mulley <gaius at gcc dot gnu.org> ---
For reference the source code is:  /libgm2/libm2pim/termios.cc:1981

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #3 from Gaius Mulley <gaius at gcc dot gnu.org> ---
The scaffold array (referencing each module ctor) is generated
gcc/m2/gm2-compiler/M2Quads.mod:2402 and ctors are created in: 
gcc/m2/gm2-gcc/m2decl.cc

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Gaius Mulley from comment #3)
> The scaffold array (referencing each module ctor) is generated
> gcc/m2/gm2-compiler/M2Quads.mod:2402 and ctors are created in: 
> gcc/m2/gm2-gcc/m2decl.cc

terms was one example (of several cases)

I had already found the code in M2Quads & Scaffold and m2decl.cc.

However, not being familiar with m2 (or the design here) .. that was not
leading me to the right code.

It seems that m2decl_DeclareModuleCtor is only called for the module that *is*
in the current TU (so Hello, in the case of a hello world example).  I've tried
putting breakpoints on m2decl_BuildEndFunctionDeclaration() [which seems to be
called for some of the actors, but I do not (for example) see a call for
_M2_termios_ctor).

In the termios.cc file:

struct _M2_termios_ctor { _M2_termios_ctor (); } _M2_termios_ctor;

the symbol '_M2_termios_ctor' does not seem to refer to a function, but to a
static instance of struct _M2_termios_ctor .. so I'm still confused about what
is supposed to happen.

===

extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_dep (void)
{
}

struct _M2_termios_ctor { _M2_termios_ctor (); } _M2_termios_ctor;

_M2_termios_ctor::_M2_termios_ctor (void)
{
//  M2RTS_RegisterModule ("termios", _M2_termios_init, _M2_termios_fini,
//                      _M2_termios_dep);
}

===

        .globl __M2_termios_fini
__M2_termios_fini:
        ret

        .globl __M2_termios_dep
__M2_termios_dep:
        ret

// here are the CTORs...

        .align 1,0x90
        .globl __ZN16_M2_termios_ctorC2Ev
__ZN16_M2_termios_ctorC2Ev:
        ret

        .align 1,0x90
        .globl __ZN16_M2_termios_ctorC1Ev
__ZN16_M2_termios_ctorC1Ev:
        ret:

// and here is the external symbol __M2_termios_ctor
// (ignore the extra leading '_' that's an ABI thing)

        .globl __M2_termios_ctor
        .zerofill __DATA,__common,__M2_termios_ctor,1,0

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
so I guess gm2-libs/termios.def causes the declaration of _M2_termios_ctor to
be created, but I still cannot figure out what the sequence is that causes it
to be created as non-external (there is no external function with that name
anyway as we already established).

There's no termios.mod ..

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---

OK so it seems that the reason for the marking of these object to be static is
because that's what was requested, so the reason lies within the M2 symbol
table and handling of imports ... 

  * frame #0: 0x000000010002e34e
cc1gm2`::m2decl_BuildEndFunctionDeclaration(location_begin=0, location_end=0,
name="_M2_termios_ctor", returntype=0x0000000000000000, isexternal=0,
isnested=0, ispublic=1) at m2decl.cc:219
    frame #1: 0x00000001000757ad
cc1gm2`::DeclareProcedureToGccSeparateProgram(Sym=6114) at M2GCCDeclare.c:7504
    frame #2: 0x0000000100075829 cc1gm2`::DeclareProcedureToGcc(sym=6114) at
M2GCCDeclare.c:7527
    frame #3: 0x000000010007cf4f
cc1gm2`::M2GCCDeclare_DeclareProcedure(sym=6114) at M2GCCDeclare.c:11648
    frame #4: 0x0000000100057b36
cc1gm2`::Lists_ForeachItemInListDo(l=0x0000000106d00550,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff110) at Lists.c:393
    frame #5: 0x00000001000d96c9
cc1gm2`::SymbolTable_ForeachProcedureDo(Sym=155, P=SymbolKey_PerformOperation @
0x00007ffeefbff150) at SymbolTable.c:14153
    frame #6: 0x000000010007cf91
cc1gm2`::M2GCCDeclare_DeclareProcedure(sym=155) at M2GCCDeclare.c:11653
    frame #7: 0x00000001000cd22a cc1gm2`::SearchAndDo(t=0x0000000106d00590,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff1a0) at SymbolKey.c:242
    frame #8: 0x00000001000cd21b cc1gm2`::SearchAndDo(t=0x0000000106c1bc00,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff1c0) at SymbolKey.c:241
    frame #9: 0x00000001000cd21b cc1gm2`::SearchAndDo(t=0x0000000106c1b4f0,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff1e0) at SymbolKey.c:241
    frame #10: 0x00000001000cd21b cc1gm2`::SearchAndDo(t=0x0000000106c0c9d0,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff200) at SymbolKey.c:241
    frame #11: 0x00000001000cd21b cc1gm2`::SearchAndDo(t=0x0000000105f008f0,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff220) at SymbolKey.c:241
    frame #12: 0x00000001000cd717
cc1gm2`::SymbolKey_ForeachNodeDo(t=0x0000000105f00460,
P=SymbolKey_PerformOperation @ 0x00007ffeefbff240) at SymbolKey.c:505
    frame #13: 0x00000001000d9720
cc1gm2`::SymbolTable_ForeachModuleDo(P=SymbolKey_PerformOperation @
0x00007ffeefbff268) at SymbolTable.c:14174
    frame #14: 0x0000000100075c43
cc1gm2`::StartDeclareModuleScopeSeparate(scope=155) at M2GCCDeclare.c:7723
    frame #15: 0x0000000100075e64 cc1gm2`::StartDeclareModuleScope(scope=155)
at M2GCCDeclare.c:7799
    frame #16: 0x000000010007ca52
cc1gm2`::M2GCCDeclare_StartDeclareScope(scope=155) at M2GCCDeclare.c:11442
    frame #17: 0x000000010006b96d cc1gm2`::DoModuleDeclare() at M2Code.c:256
    frame #18: 0x000000010006bed9 cc1gm2`::M2Code_Code() at M2Code.c:470
    frame #19: 0x000000010006c760 cc1gm2`::Compile(s=0x0000000106c1ed80) at
M2Comp.c:211
    frame #20: 0x000000010006d4db
cc1gm2`::M2Comp_compile(filename=0x00007ffeefbffa6a) at M2Comp.c:760
    frame #21: 0x00000001000454b7
cc1gm2`init_PerCompilationInit(filename="/source/test/hello.mod") at
init.cc:195
    frame #22: 0x0000000100002115
cc1gm2`::gm2_parse_input_files(filenames=0x0000000106819cc0, filename_count=1)
at gm2-lang.cc:451
    frame #23: 0x0000000100002146 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:458
    frame #24: 0x0000000101cc353a cc1gm2`::compile_file() at toplev.cc:444
    frame #25: 0x0000000101cc6f7f cc1gm2`::do_compile(no_backend=false) at
toplev.cc:2125
    frame #26: 0x0000000101cc74bd cc1gm2`toplev::main(this=0x00007ffeefbff4da,
argc=37, argv=0x00007ffeefbff518) at toplev.cc:2277
    frame #27: 0x000000010251ecd2 cc1gm2`main(argc=37, argv=0x00007ffeefbff518)
at main.cc:39

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
note that these symbols seem to appear right at the end of the list - after the
HelloWorld ones (which _are_ correctly non-external).  Not sure if that's
relevant information.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, the way to see what's creating some tree is breaking on the 'return
result;' line in ggc_internal_alloc conditional on result being the tree
(or other GC allocated) object.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
So we do set _M2_termios_ctor Symbol to extern.

But then here:

      PreAddModGcc (Sym, BuildEndFunctionDeclaration (begin, end,
                                                      KeyToCharStar
(GetFullSymName (Sym)),
                                                      returnType,
                                                      IsExternal (Sym),  (*
Extern relative to the main module.  *)
                                                      IsProcedureGccNested
(Sym),
                                                      (* Exported from the
module where it was declared.  *)
                                                      IsExported
(GetModuleWhereDeclared (Sym), Sym) OR IsExtern (Sym))) ;
      PopBinding(scope) ;

"IsExternal (Sys)" returns false, because it thinks that the scope of
_M2_termios_ctor is HelloMod.

(lldb) p SymbolTable_GetScope(Sym)
(unsigned int) $5 = 155
(lldb) p M2GCCDeclare_PrintSym(155)
information about symbol: 155
==============================
sym 155 IsModule (HelloWorld)
(lldb) p Sym
(unsigned int) $6 = 6114

(lldb) p M2GCCDeclare_PrintSym(6114)
information about symbol: 6114
==============================
sym 6114 IsProcedure (_M2_termios_ctor) scope HelloWorld:1 155 extern ctor
declared in /source/test/hello.mod:1

So we create the decl assuming it exists in the TU .. which is the source of
the wrong code.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
It looks to me that we never check if Sym is a definition/implementation - only
that the containing scope is.

I probably miss something subtle - but perhaps

   IF NOT IsDefImp(Sym)
     RETURN ( TRUE )

before the mod := line
?

(*
   IsExternal -
*)

PROCEDURE IsExternal (sym: CARDINAL) : BOOLEAN ;
VAR
   mod: CARDINAL ;
BEGIN
   mod := GetScope(sym) ;
   REPEAT
      IF mod=NulSym
      THEN
         RETURN( FALSE )
      ELSIF IsDefImp(mod)
      THEN
         RETURN( mod#GetMainModule() )
      END ;
      mod := GetScope(mod)
   UNTIL mod=NulSym ;
   RETURN( FALSE )
END IsExternal ;

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #11 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Many thanks for the analysis.  Taking your idea and assuming
that Sym 6114 is a procedure then I think the correction is:

PROCEDURE IsExternal (sym: CARDINAL) : BOOLEAN ;
VAR
   mod: CARDINAL ;
BEGIN
   (* new code starts here.  *)
   IF IsProcedure (sym) AND IsExtern (sym)
   THEN
      RETURN TRUE
   END ;
   (* end of new code.  *)
   mod := GetScope(sym) ;
   REPEAT
      IF mod=NulSym
      THEN
         RETURN( FALSE )
      ELSIF IsDefImp(mod)
      THEN
         RETURN( mod#GetMainModule() )
      END ;
      mod := GetScope(mod)
   UNTIL mod=NulSym ;
   RETURN( FALSE )
END IsExternal ;


In gcc/m2/gm2-compiler/SymbolTable.mod procedures can be queried as IsExtern.
The ctors are special case created in gcc/m2/gm2-compiler/M2Scaffold.mod.
It looks as if the special case might not have been tested in IsExternal.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
With the change above (and adding an assert that the function is not
defined/implemented) -- NOTE: plus a number of other hacks to workaround other
PRs in progress ... we now have something more reasonable for m32 darwin.

test time is large - primarily because a significant number of the fails are
timeouts.


=== x86-64 Darwin with a 32b multilib.

                === gm2 Summary for unix/-m32 ===

# of expected passes            11820
# of unexpected failures        48

                === gm2 Summary for unix/-m64 ===

# of expected passes            11818
# of unexpected failures        50

                === gm2 Summary ===

# of expected passes            23638
# of unexpected failures        98

Compiler version: gcc gm2 
Platform: x86_64-apple-darwin17

==== i686-darwin with a 64b multilib.

                === gm2 Summary for unix/-m32 ===

# of expected passes            11833
# of unexpected failures        35

                === gm2 Summary for unix/-m64 ===

# of expected passes            12957
# of unexpected failures        63

                === gm2 Summary ===

# of expected passes            24790
# of unexpected failures        98

Compiler version: gcc gm2 
Platform: i686-apple-darwin9

===== powerpc-darwin

                === gm2 Summary for unix/-m32 ===

# of expected passes            11817
# of unexpected failures        51

                === gm2 Summary for unix/-m32 ===

# of expected passes            11817
# of unexpected failures        51

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---

oops - pasto on the power results:

                === gm2 Summary for unix/-m64 ===

# of expected passes            11809
# of unexpected failures        59

                === gm2 Summary ===

# of expected passes            23626
# of unexpected failures        110

Compiler version: gcc gm2 
Platform: powerpc-apple-darwin9

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
coming back to this code:
===

extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_dep (void)
{
}

struct _M2_termios_ctor { _M2_termios_ctor (); } _M2_termios_ctor;

_M2_termios_ctor::_M2_termios_ctor (void)
{
//  M2RTS_RegisterModule ("termios", _M2_termios_init, _M2_termios_fini,
//                      _M2_termios_dep);
}

====

I think this is not currently doing what is expected (it's certainly
inconsistent with the compiler's PoV .. from my debugging).

----

The declaration in the compiler thinks that _M2_termios_ctor is the symbol for
a function.  Where (because of the way this shim is written) it's actually the
name of a static variable.  Which means if it was ever called "boom". 

However, my current understanding us that M2_link() is just a mechanism to
ensure that all the library code is pulled in (so perhaps it would never be
called).  Actually, that should not be necessary if the decls are correctly
marked as "used".

Furthermore, the initialisation code for the static instance will be entered
automatically into the startup (so it's out of your control).

=====

What about, instead:

extern "C" void
_M2_termios_init (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_fini (int, char *[], char *[])
{
}

extern "C" void
_M2_termios_dep (void)
{
}

extern "C" void
_M2_termios_ctor (void)
{
  M2RTS_RegisterModule ("termios", _M2_termios_init, _M2_termios_fini,
                        _M2_termios_dep);
}

== now the symbol will indeed refer to the CTOR that causes the module to be
registered.  As it is written that CTOR will not be called unless you do it.

IFF you want it to be called "automatically" at program startup .. you can mark
it
__attribute__((constructor))

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #15 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Yes the proposed changes to the C module ctor works well and matches the
declaration in the compiler scaffold.  I'd advocate adding the attribute to
match the expected behaviour for all modules.  The startup sequence of the
ctors shouldn't matter (as mentioned elsewhere) as M2Dependent.mod self
initializes on the first call to an external procedure.

It would make sense to remove M2_link () as it was only used to pull in
dependent modules.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 54170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54170&action=edit
Patch registration constructors

This modifies the registration CTORs that are currently defined in C++ to be
defined as 'extern "C"' and registered to be run at program load time.

This is as described in comments #14 and 15.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #16)
> Created attachment 54170 [details]
> Patch registration constructors
> 
> This modifies the registration CTORs that are currently defined in C++ to be
> defined as 'extern "C"' and registered to be run at program load time.
> 
> This is as described in comments #14 and 15.

I did not post this yet - because I was wondering if there is more needed

 (i.e. that the code-gen should also do something similar when .mods are
compiled).  For example, if I take a random test case, and examine the symbols
- I see these CTORs - but I do not see any CTORs for non-library modules.

Of course, that could also be a separate patch - don't think I know the m2
sources well enough to attempt it at present, tho.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:d423e8dc59045d8f281dcb1a02559cb6f91456bf

commit r13-4943-gd423e8dc59045d8f281dcb1a02559cb6f91456bf
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Dec 21 09:05:32 2022 +0000

    modula2: Ensure that module registration constructors are 'extern'
[PR108183].

    The symbols for module registration constructors need to be external
    or we get wrong code generated for targets that allow direct access to
    local symbol definitions.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

            PR modula2/108183

    gcc/m2/ChangeLog:

            * gm2-compiler/M2GCCDeclare.mod: Module registration constructors
are
            externs to the builder of m2_link.

    Co-Authored-By: Gaius Mulley <gaiusmod2@gmail.com>

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108259,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108261

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
the initial part of this is now fixed on trunk, but the follow-on
questions/patch and subsidiary issues remain.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-January
                   |                            |/609299.html

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
posted the second patch, as I now figured out the open question about CTORs
generated from ,mod files.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:ec6d1fc09faea4a6be4df74babb73dca6b50ff0c

commit r13-4996-gec6d1fc09faea4a6be4df74babb73dca6b50ff0c
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Fri Dec 30 19:46:13 2022 +0000

    modula-2: Fix registration of modules via constructors [PR108183].

    This reworks the mechanism used for module registration to use init-
    time constructors.  The order of registration is not important, the
    actual initialization dependency tree will be computed early in the
    execution (all that matters is that we have registered before that).

    This fixes a potential issue in which the external name known to the
    m2 system is of the form _M2_XXXXXX_ctor() but the C++ code was
    producing a static variable instance with the same name.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

            PR modula2/108183

    gcc/m2/ChangeLog:

            * gm2-libs-ch/UnixArgs.cc (_M2_UnixArgs_ctor): Rework to use
            an extern "C" function with 'constructor' attribute.
            * gm2-libs-ch/dtoa.cc (_M2_dtoa_ctor): Likewise.
            * gm2-libs-ch/ldtoa.cc (_M2_ldtoa_ctor): Likewise.

    libgm2/ChangeLog:

            * libm2cor/KeyBoardLEDs.cc (_M2_KeyBoardLEDs_ctor): Rework to use
            an extern "C" function with 'constructor' attribute.
            * libm2iso/ErrnoCategory.cc (_M2_ErrnoCategory_ctor): Likewise.
            * libm2iso/RTco.cc (_M2_RTco_ctor): Likewise.
            * libm2pim/Selective.cc (_M2_Selective_ctor): Likewise.
            * libm2pim/SysExceptions.cc (_M2_SysExceptions_ctor): Likewise.
            * libm2pim/UnixArgs.cc (_M2_UnixArgs_ctor): Likewise.
            * libm2pim/cgetopt.cc (_M2_cgetopt_ctor): Likewise.
            * libm2pim/dtoa.cc (_M2_dtoa_ctor): Likewise.
            * libm2pim/errno.cc (_M2_errno_ctor): Likewise.
            * libm2pim/ldtoa.cc (_M2_ldtoa_ctor): Likewise.
            * libm2pim/sckt.cc (_M2_sckt_ctor): Likewise.
            * libm2pim/termios.cc (_M2_termios_ctor): Likewise.
            * libm2pim/wrapc.c: Add a new line to the file end.

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> ---
I think this is now fixed.