TIP: Click on subject to list as thread! ANSI
echo: cis.languages
to: gccoids
from: Carl Kreider 71076,76
date: 1993-08-24 16:54:15
subject: #what the .?.{}

#: 18591 S3/Languages
    24-Aug-93  16:54:15
Sb: #what the *?*{}
Fm: Carl Kreider 71076,76
To: gccoids

Are there any keepers of the gcc faith here?  I'm spoiling for a fight ;)

I just got version 2.4.5, and it sure seems badly broken to me.  I tried to
compile cawf with it to see how it did, and it throws up and causes the
assembler to throw up in any case but -m68000.  For other processors it
generates "tst.l" on address registers.  This is illegal. For example, this
fragment compiled with any optimization:

        char *np;                       /* name pointer */
        if ((np = getenv("CAWFLIB")) != NULL)

generates:

        bsr =getenv *b6
        move.l d0,a2 *m6c
        tst.l a2

An interesting side note is that the r68 that comes with ucc doesn't complain
about it......  Watch your butt if you use Ultra C.

Even more bizarre is this:

    gcc -m68020 -DSTDLIB -DSTDDEF -c pass2.c -o RELS/pass2.r
    pass2.c: In function `Pass2':
    pass2.c:1184: internal error--unrecognizable insn:
    (insn 5244 1870 1871 (set (reg:SI 2 d2)
            (mem/s:SI (plus:SI (reg:SI 1 d1)
                    (plus:SI (symbol_ref:SI ("Nhnr"))
                        (reg:SI 14 a6))))) -1 (nil)
        (nil))
    gcc: Program cc2 got fatal signal 104. (pass2.c)
    make: aborted due to errors

This happens for any processor but -m68000.

Can anybody shed any light?  Can you pass this on to Stephen?

Carl

There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.