M68K codegen problem with `unsigned long long' - showstopper forNetBSD

[Todd Vierling]

[resent because I haven't seen it after a couple days...possibly
misaddressed it.]

>From reports sent me by <is@netbsd.org>, there seems to be a serious codegen
bug affecting `unsigned long long', or possibly even register constraints.
I can't reproduce it with a small test case, but I have attached m68k.tgz
which contains:

- prepro.c, the preprocessed C source which can be run through cc/cc1 to
  produce the resultant assembly/object;
- opt.s, the output of "cc -O -S prepro.c"
- nonopt.s, the output of "cc -S prepro.c"

Target is m68k-netbsd, but I could cause the same codegen on "m68k-coff",
so it seems to affect all m68k variants.

===== From <is@netbsd.org> =====

The relevant portion of the C code is:

==================================================
switch (base) {
                                case OCT:
                                        do {
                                                *--cp = to_char(_uquad & 7);
                                                _uquad >>= 3;
                                        } while (_uquad);
                                        /* handle octal leading 0 */
                                        if (flags & ALT && *cp != '0')
                                                *--cp = '0';
                                        break;
==================================================

Output with -O0 is slooooow, but correct:

==================================================
L160:   
        subql #1,a6@(-24)
        movel a6@(-24),a0
        moveb a6@(-85),d0
        andb #7,d0
        moveb d0,d5
        addb #48,d5
        moveb d5,a0@
        movel a6@(-92),d5
        movel a6@(-88),d6
        lsrl #1,d5
        roxrl #1,d6
        lsrl #1,d5
        roxrl #1,d6
        lsrl #1,d5
        roxrl #1,d6                     
        movel d5,a6@(-92)
        movel d6,a6@(-88)                       
L162:   
        movel a6@(-92),d5
        movel a6@(-88),d6       
        negl d6
        negxl d5
        jne L163
        jra L161
        .even
L163:
        jra L160
        .even
L161:
==================================================
Output with -O is less slow, and buggy:

==================================================
L164:   
        moveb a6@(-481),d0
        andb #7,d0
        addb #48,d0
        moveb d0,a3@-
        movel a6@(-488),d3
        movel a6@(-484),d4
        lsrl #1,d3
        roxrl #1,d4
        lsrl #1,d3 
        roxrl #1,d4
        lsrl #1,d3
        roxrl #1,d4
        movel d3,a6@(-488)
        movel d4,a6@(-484)
        movel d3,d4	<--- these are the bogus lines
        orl d4,d4	<--- these are the bogus lines
        jne L164
        btst #0,d6
        jeq L160
        cmpb #48,a3@
        jeq L160
        moveb #48,a3@-
        jra L160
==================================================
The bogus lines SHOULD read (one line):
        orl d3,d4
==================================================

Actually, the code is still slower than what an assembler beginner would
type, and what egcs-1.0.x did create (with a few renamed registers):
==================================================
        movel a6@(-488),d3
        movel a6@(-484),d4
L164:   
        moveb d4,d0
        andb #7,d0
        addb #48,d0
        moveb d0,a3@-
        lsrl #1,d3
        roxrl #1,d4
        lsrl #1,d3 
        roxrl #1,d4
        lsrl #1,d3
        roxrl #1,d4
        movel d3,d0
        orl d4,d0
        jne L164
        btst #0,d6
        jeq L160
        cmpb #48,a3@
        jeq L160
        moveb #48,a3@-
        jra L160
==================================================

Conclusion:

besides creating slower code than -1.0, egcs-1.1 also breaks quad comparison
to zero.

Regards,
	Ignatios
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m68k.tgz
Type: application/x-gzip
Size: 18419 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/19980828/fc945fdc/attachment.bin>