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|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Bug ID: 108182
Summary: gm2 driver mishandles target and multilib options
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #9 from Iain Sandoe ---
mystery solved.
The symbols are also undefined on Linux, but the linux linker silently allows
this.
To do this on Darwin, we have to add -Wl,-undefined,dynamic_lookup
However, this mode is looking like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #8 from Iain Sandoe ---
I did a little more poking - some of the missing symbols are in
m2/gm2-libs-boot/libgm2.a
adding that to the failing link line results in some more missing symbols,
these look mainly like wrappers around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #7 from Iain Sandoe ---
same result on x86_64 darwin21 - under rosetta 2.
BTW: this seems a bit odd to me I see the plugin specified like this:
plugin/m2rte$(exeext)$(soext) (.so without Rainer's patch).
Why $(exeext)?
Won't you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #6 from Iain Sandoe ---
hmm .. some odd things.
With Rainer's patch actually the plugin build succeeded on x86_64-darwin19
(Catalina)
so then the plugin fails to load because it is missing the libstdc++ version
needed (since that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107607
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2022-12-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #5 from Iain Sandoe ---
sorry about the duplicate comment - not quite sure what BZ did there.
Note: dynamic lookups might become an issue for Darwin2* (I expect that there
is a move towards requiring that symbols are resolved to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #4 from Iain Sandoe ---
(In reply to Rainer Orth from comment #1)
> Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable:
>
> cc1gm2: fatal error: inaccessible plugin file
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072
--- Comment #12 from Iain Sandoe ---
hmm:
std::unique_ptr type = nullptr;
if (lexer.peek_token ()->get_id () == COLON)
{
lexer.skip_token ();
// parse type, which is now required
type = parse_type ();
if (type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2022-12-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #6 from Iain Sandoe ---
since this effects upstream *-*-darwin21+ the bug is now tracked here (I've
closed the arm64 duvet branch dup)
I am considering amending the darwin host module to add
-Wno-error=deprecated-declarations to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768
--- Comment #8 from Iain Sandoe ---
posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608262.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #7
301 - 400 of 934 matches
Mail list logo
