https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #27 from Iain Sandoe ---
great!
we make more progress now - at least past libphobos configure:
we now fail building druntime/core/atomic.d and I am not quite sure how to
interpret the backtrace (from b internal_error).
(lldb) bt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #25 from Iain Sandoe ---
(In reply to ibuclaw from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> > same as Linux).
> I'm still yet to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #23 from Iain Sandoe ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
>
> C++ Darwin 32-bit calling a method that returns an 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #17 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Iain Sandoe from comment #14)
> > So it would seem that we might want to find a reproducer that we can look at
> > the various tree dumps and see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #16 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> (In reply to ibuclaw from comment #13)
> If the caller is passing two regs it seems to me likely that (for some
> reason it thinks that the value is returned via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #14 from Iain Sandoe ---
(In reply to ibuclaw from comment #13)
> Confirmed, D is doing NRVO return whereas C++ isn't.
I am not sure that the NVRO is the issue (it is correct ABI for an 8 byte
struct to be returned in EAX:EDX).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #26 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #25)
> Created attachment 54516 [details]
> Proposed fix version 6
>
> Version 6 (more coroutine tests) and RTint.mod with more descriptive
> variable names.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #11 from Iain Sandoe ---
(In reply to ibuclaw from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > +
> > +/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration
> > SYM.
> > + Set flags to reflect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #8 from Iain Sandoe ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().
+ /* Visibility attributes are used by the debugger. */
+ set_visibility_for_decl (decl->csym, decl);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #7 from Iain Sandoe ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().
>
> Can't see anything odd about the virtual function declaration that would
> suggest there's a mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108835
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
--- Comment #14 from Iain Sandoe ---
please see the Work In Progress here:
https://github.com/iains/gcc-darwin-arm64
this is a functional branch (although with known issues, since it is a
prototype)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #7)
> Hmm,
> https://inbox.sourceware.org/gcc-patches/B4F496F4-F31D-41D2-8942-
> 1f0aefbd7...@sandoe-acoustics.co.uk/
>
> Seems didn't get installed even though it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108553
--- Comment #7 from Iain Sandoe ---
(In reply to Richard Biener from comment #6)
> (In reply to CVS Commits from comment #5)
> > The master branch has been updated by Iain D Sandoe :
>
> You should now see an unused variable diagnostic about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555
--- Comment #5 from Iain Sandoe ---
Created attachment 54355
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54355=edit
Partch under test - partial reversion of r13-5373-g80cf2c5e8f496b
This reverts the part of r13-5373-g80cf2c5e8f496b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555
Iain Sandoe changed:
What|Removed |Added
Assignee|gaius at gcc dot gnu.org |iains at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108555
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108553
--- Comment #3 from Iain Sandoe ---
I'm trying to reproduce this - in the meantime does the obvious fix solve the
problem for you?
diff --cc gcc/m2/gm2-lang.cc
index 4d9cae205a7,4d9cae205a7..a30e626620c
--- a/gcc/m2/gm2-lang.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108553
--- Comment #2 from Iain Sandoe ---
(In reply to Richard Biener from comment #1)
> diagnosing options in gm2_langhook_init_options is probably not the way to
> go.
>
> Looks like this creeped in by recent refactoring?
Yeah, there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108493
--- Comment #1 from Iain Sandoe ---
I can reproduce this with C - so it's not specifically a module-2 issue (but
the use of traditional-cpp does trigger it .. and for keywords within (* *) so
we need to figure out what the intended semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108493
Bug ID: 108493
Summary: Interaction with implicit includes and
-traditional-cpp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108493
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Attachment #54289|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108480
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
--- Comment #6 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #5)
> I've committed the patch above - since the source tree without it definitely
> has a mismatched prototype. The exit issue needs to be resolved before
> this PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Attachment #54261|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
--- Comment #2 from Iain Sandoe ---
Created attachment 54289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54289=edit
Patch for discussion
This applies on top of the patch for PR108182 (and will most likely not work
without those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107629
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
--- Comment #4 from Iain Sandoe ---
Works for me - now the failing test cases produce a diagnostic;
/src-local/gcc-master/libgm2/libm2iso/RTco.cc:373:in initThread has caused
failed to set stack size attribute
Although it does not seem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405
--- Comment #2 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #1)
> note that a default size of 8Mb is not enough for either Linux or Arm64
> Darwin (both have PTHREAD_STACK_MIN of 16384).
this is, of course, rubbish .. the default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-darwin
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405
Bug ID: 108405
Summary: modula-2: Testsuite fails: concurrentstore.mod,
contimer.mod, tinytimer.mod on Darwin (and likely
elsewhere)
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
Bug ID: 108404
Summary: M2RTS_Halt fails with a segv (it should emit a
diagnostic and exit).
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> Created attachment 54261 [details]
> Updated patch that honours the order of include use.
>
> This is V5 ...
>
> ... so here we collect the incoming search
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Attachment #54220|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #19 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #18)
> For the runtime perspective then your layered approach is much cleaner.
indeed ..
> It would be good to allow users to be able to use pim and some iso
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #13 from Iain Sandoe ---
Created attachment 54248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54248=edit
Revised fix
This essentially makes Modula-2 build its include paths in the Front End (which
is how all the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #16 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Gaius Mulley from comment #11)
> > > > when a module has the same name but a different interface are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > (In reply to Iain Sandoe from comment #12)
> > > (In reply to Gaius Mulley from comment #11)
> > > > > when a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Gaius Mulley from comment #11)
> > > > when a module has the same name but a different interface are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #13 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #12)
> (In reply to Gaius Mulley from comment #11)
> > > when a module has the same name but a different interface are the
> > symbols distinct (i.e. mangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #12 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #11)
> > when a module has the same name but a different interface are the
> symbols distinct (i.e. mangled differently)?
>
> no. So, as you say, the ordering of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #12 from Iain Sandoe ---
unfortunately, neither this nor the v4.1 (WIP) is still quite right.
Using LIBDIR in the computation of the include paths means that the compiler
does not work when it is relocated .. the directory prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #10 from Iain Sandoe ---
Initial questions (still digesting the remainder).
when a module has the same name but a different interface are the symbols
distinct (i.e. mangled differently)?
If not:
- then I can see how it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Attachment #54184|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #8 from Iain Sandoe ---
This is good in that it removes the extra -Ls, but ...
1. This will not work in general for targets with spec substitution for library
names - the library names *do* need to be on the driver line,
2. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Gaius Mulley from comment #4)
> > Created attachment 54184 [details]
> > Potential fix for target multilib_dir handling -m and -f.
> >
> > Work in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #8 from Iain Sandoe ---
(In reply to Eric Gallager from comment #6)
> @marxin is this something you checked during the sphinx conversion and
> reversion at all?
(In reply to Martin Liška from comment #7)
> Well, running 'make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #6 from Iain Sandoe ---
and another datum (on x86_64linux):
$ ../gcc-13-0-0p/bin/gm2
/home/iains/gcc-master/src-patched/gcc/testsuite/gm2/coroutines/pim/run/pass/testiotransfer.mod
-flibs=cor,iso,pim -o tio -O
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #5 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54184 [details]
> Potential fix for target multilib_dir handling -m and -f.
>
> Work in progress.
1. (I think) the string you need is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #6 from Iain Sandoe ---
Looking at a current discussion of
https://cplusplus.github.io/CWG/issues/2563.html
it seems that there is agreement that the returned type from
get_return_object() does not need to match the coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #5 from Iain Sandoe ---
this patch exposes the issue by allowing the linker to find the shared libs.
[PATCH] modula-2, driver: Do not add extra '-L' options that shadow
$libdir.
The driver is adding one '-L' option for each path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #12 from Iain Sandoe ---
with Xcode 14.1 CLT and the macOS13 SDK, the build fails without the
work-around and works for this:
time nice make -j10 BOOT_CFLAGS="-O2 -g -Wno-error=deprecated-declarations"
>b.txt 2>e.txt
(jftr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #11 from Iain Sandoe ---
at what stage is it failing?
(and with what error)
.. when I las tried this with the macOS13 SDK it dod work .. I will try to fit
a test run in sometime (stuff is tied up with other testing right now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #9 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #2 from Iain Sandoe ---
computing the multilib_os_dir in the language driver is not going to be
easy/reliably correct, since that code is called very early and the specs
applied later could well modify the command line options.
On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
--- Comment #3 from Iain Sandoe ---
this patch shows the problem - because it removes the shadowing "-L" options.
Obviously, we cannot apply it without creating 'regressions'...
[PATCH] modula-2, driver: Do not add extra '-L' options that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #3 from Iain Sandoe ---
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0001002c728c libm2iso.17.dylib`findChildAndParent at
RTentity.mod:244:13
frame #1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #2 from Iain Sandoe ---
I guess an alternate is to generate a dependent lib with the common code (e.g.
libm2common.so) and then layer the others on top.
However, it's no obvious that the separation into these sub-libraries is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #1 from Iain Sandoe ---
note that these changes would also simplify the driver (to some extent)
although, I guess the includes have to be adapted to the flags in force?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
Bug ID: 108261
Summary: modula-2 module registration process seems to fail
with shared libraries.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2023-01-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
--- Comment #1 from Iain Sandoe ---
Created attachment 54173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54173=edit
Make module registration constructors visible.
The issue here was that the code translating these into "GCC" form was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108259
Bug ID: 108259
Summary: Modula-2 module constructors symbols in (shared)
libraries are hidden
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #17 from Iain Sandoe ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #16 from Iain Sandoe ---
Created attachment 54170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54170=edit
Patch registration constructors
This modifies the registration CTORs that are currently defined in C++ to be
defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106435
--- Comment #11 from Iain Sandoe ---
posted here
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608096.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #14 from Iain Sandoe ---
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)
{
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202
Bug ID: 108202
Summary: [13 Regression] Many new acats fails on 32bit Darwin
hosts.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #13 from Iain Sandoe ---
oops - pasto on the power results:
=== gm2 Summary for unix/-m64 ===
# of expected passes11809
# of unexpected failures59
=== gm2 Summary ===
# of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #12 from Iain Sandoe ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
--- Comment #3 from Iain Sandoe ---
the import places attributes at the end.
so
import module Foo [[]];
it would seem to be symmetrical to have:
export import Foo [[...]];
export module Foo [[...]];
but, ts present, (if I read it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #10 from Iain Sandoe ---
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 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #9 from Iain Sandoe ---
So we do set _M2_termios_ctor Symbol to extern.
But then here:
PreAddModGcc (Sym, BuildEndFunctionDeclaration (begin, end,
KeyToCharStar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #7 from Iain Sandoe ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #6 from Iain Sandoe ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #5 from Iain Sandoe ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #4 from Iain Sandoe ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #10 from Iain Sandoe ---
I fixed the plugin build to avoid linking libstdc++ (small additions to
Rainer's patch)
* linking libstdc++ causes the build to fail because the plugin cannot find
the libstdc++ because it is not yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
--- Comment #3 from Iain Sandoe ---
FAOD, I am not expecting that the patch is the correct one - it is a
proof-of-principle as to where the issue lies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2022-12-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #1 from Iain Sandoe ---
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
301 - 400 of 950 matches
Mail list logo