Re: Bug in Gcc 2.5.8

[Thomas Schulze <ts@uni-paderborn.de>]

Hello everybody,

concerning this *damned* gcc-2.5.8 (and 2.6.x) bug Ole Arndt
posted the following on maus.mint today:


[some blurb deleted, he just claimed he found the bug and inserts
 his email to eric. Since he posted it I think its ok to post it
 here, too. Remember, this comes from Ole_Arndt@of2.maus.de (Ole Arndt)]

--- beginning of included message

Hello Eric,

in your readme file to the mint sources you write:

>COMPILER NOTES:
>
>gcc 2.3.3 works fine
>
>gcc 2.5.x causes problems in proc.c; MiNTs compiled with gcc 2.5.x don't
>    work with MultiTOS (and probably have other problems, too)

This circumstance has been very annoying to me since long time ago.
After reading this, I compiled proc.c with '-save-temps' on, using gcc
2.5.8 and gcc 2.3.3 and what did I see:
Gcc 2.5.8 produces assembler output like this (in newproc()):

    lea     _kmalloc,a2
    jsr     a2@
    movel   d0,d2
    addql   #4,sp
    jne     L2          | <- testing zero flag set by addq
    moveql  #0,d0
    rts
L2:
 
while gcc 2.3.3 at the same place outputs:

    lea     _kmalloc,a2
    jsr     a2@
    movel   d0,a2
    addql   #4,sp
    cmpal   #0,a2
    jne     L2
    moveql  #0,d0
    rts
L2:

so I tried to build it again with gcc 2.5.8 and '-fno-defer-pop' and
everything was allright:

    lea     _kmalloc,a2
    jsr     a2@
    addql   #4,sp
    movel   d0,d2
    jne     L2          | <- now testing the right one
    moveql  #0,d0
    rts
L2:

I rebuilded all MiNT with '-fno-defer-pop' and it seems to work ok with
AES 4.1. There must have been the same situation in rendez.c which screwed
up a semaphore, because the Screen manager used to lock up, but you could
still give the active application keystrokes and work on the virtual
consoles.


cheers, Ole.

--- end of included message

I really hope this fixes the problem...

Just to inform you, Thomas.