https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119779
--- Comment #11 from Zbigniew ---
(* gm2 exampleadd2.mod -o exampleadd2 -masm=intel *)
MODULE exampleadd2 ;
FROM libc IMPORT printf, exit ;
PROCEDURE Example (foo, bar: LONGCARD) : CARDINAL ;
VAR
myout: LONGCARD ;
BEGIN
ASM VOLATIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119779
--- Comment #10 from Zbigniew ---
Even "better"... :(
I'm seriously afraid it won't be possible to switch somehow to GAS, regarding
assembly, instead of C-inline?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119779
--- Comment #8 from Zbigniew ---
I modified somewhat the example and it seems to be working using RAX too (BTW:
does there exist any way — any „pragma” or anything — to switch from that
atrocious AT&T syntax to Intel syntax?):
MODULE examplead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119779
--- Comment #7 from Zbigniew ---
I mean: the arith limit doesn't bother me that much — 32-bit is quite enough —
but being limited to 32-bit registers while working in 64-bit OS means PUSH/POP
cannot be used, and all these new, additional R* regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119779
Zbigniew changed:
What|Removed |Added
CC||zbigniew2011 at gmail dot com
--- Comment #6
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 #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
--- 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 #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 #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=119750
--- Comment #2 from Zbigniew ---
Indeed, I didn't try any other compilation since that time. It reports:
gcc hw.c -o hw.o
Assembler messages:
Internal error (Illegal instruction).
Please report this bug.
Well I did compilation of GCC 11.5 on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119751
Bug ID: 119751
Summary: There's a need to tidy up m2 subdirectories' contents
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119750
Bug ID: 119750
Summary: Unable to compile GCC 14.2 using GCC 11.5 — on 32-bit
x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
15 matches
Mail list logo
