https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #16 from Gaius Mulley ---
RE: ASM examples probably easier to continue this thread over at PR
modula2/119779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #15 from Zbigniew ---
The second example, I mean the one from PDF book, spits out somewhat different
errors. I mean the second one from the section 2.17:
PROCEDURE Example (foo, bar: CARDINAL) : CARDINAL ;
VAR
myout: CARDINAL ;
BEGI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #14 from Gaius Mulley ---
Regarding Comment #8
Yes I believe so, logged as PR modula2/119779
Thanks for spotting this bug!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #13 from Zbigniew ---
And regarding my Comment #8 — about assembler-related problems? Is it a bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2025-04-13
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #11 from Gaius Mulley ---
Replying to comment#7
I think the solution is to extend the ISO attributes (eg <* DIALECT iso10514
*>) to specify the modula-2 dialect and also have another attribute to warn if
the user module is importing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #10 from Gaius Mulley ---
Created attachment 61090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61090&action=edit
Proposed fix to remove gcc/m2/gm2-libs/COROUTINES.mod
The above patch removes gcc/m2/gm2-libs/COROUTINES.mod w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #9 from Sam James ---
(In reply to Zbigniew from comment #8)
That sounds like it belongs in a new bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #8 from Zbigniew ---
I'd like also to note there's also a need to take better care about the docs;
for example: I tried a code snippet from
https://gcc.gnu.org/onlinedocs/gm2/Assembly-language.html („2.17 Interface to
assembly langua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #7 from Zbigniew ---
I'd like to stress it: presently these error messages (I mean without '-fiso'
option) look like compiler was malfunctioning:
coex.mod:8:24: error: In program module 'CoEx': unknown symbol 'COROUTINE'
8 | FRO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #6 from Zbigniew ---
Indeed I confirm 'gm2 -fiso coex.mod -o coex' works in case of GCC 14.2.0. Yes,
the error message could be a bit more specific, if it's feasible.
In case of 12.2.0 there's still an error (below) — but I assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #5 from Gaius Mulley ---
Thanks for the report.
[As an aside gm2 from GCC-12 has a completely different linking mechanism to
gm2 GCC-14.2]
The file gcc/m2/gm2-libs/COROUTINES.def is a definition for "C" and thus has no
accompanying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #4 from Zbigniew ---
Excuse me, but it'll again compile 20 hours or so.
No, it's highly unlikely literally every distro has 'packaging issues' and
exactly with gm2 — maybe the better way would be if you first try the example
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #3 from Andrew Pinski ---
(In reply to Zbigniew from comment #2)
> It is compiled (the whole 14.2 'suite') from the sources. But I doubt
> Slackware's scripts interfere with GM2 subdirectories in any way. You can
> easily check Slack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
--- Comment #2 from Zbigniew ---
It is compiled (the whole 14.2 'suite') from the sources. But I doubt
Slackware's scripts interfere with GM2 subdirectories in any way. You can
easily check Slackware-current scripts, they are available on any Sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-slackware-linux
--- Comment #1 f
16 matches
Mail list logo
