GCC 6.2 toolchain for AmigaOS 3

[Marlon_]

Managed to get it to compile and link properly with -noixemul, but trying to launch the binary in UAE results in a lockup. I'm not sure how to debug stuff like that. Any tips?

IT RUNS!

EDIT:
However, there needs to be some tweaking before it's actually usable.

• Playing a track goes full speed with no regards
• Navigating directories doesn't work
• Loading files only works from commandline
• etc

[bebbo]

Originally Posted by Marlon_

Alright, sorted most of them now. The only ones left are PPSingleton<EnvelopeEditor::ClipBoard> and PPSingleton<SampleEditor::ClipBoard>, but when I try to sort it, it complains about the instance being private. I'll probably figure it out soon enough. :P

Also change the header for nested classes and "make more friends":

        friend class PPSingleton<ClipBoard>;
    };
    friend class PPSingleton<EnvelopeEditor::ClipBoard>; // add this line

[Marlon_]

Originally Posted by bebbo

Also change the header for nested classes and "make more friends":

        friend class PPSingleton<ClipBoard>;
    };
    friend class PPSingleton<EnvelopeEditor::ClipBoard>; // add this line

Oh, this approach was much better. I made ClipBoard public then did

template<>
EnvelopeEditor::ClipBoard * PPSingleton<EnvelopeEditor::ClipBoard>::instance = NULL;

in EnvelopeEditor.cpp.

Since I got it to compile and run either way, and there's a lot of tweaks needed, I'll probably go back and change this. Thank you for the help! =)

[bebbo]

Originally Posted by Marlon_

Oh, this approach was much better. I made ClipBoard public then did

template<>
EnvelopeEditor::ClipBoard * PPSingleton<EnvelopeEditor::ClipBoard>::instance = NULL;

in EnvelopeEditor.cpp.

Since I got it to compile and run either way, and there's a lot of tweaks needed, I'll probably go back and change this. Thank you for the help! =)

Why don't you put it on github or somewhere else? ^^

[Marlon_]

I'll probably do that. But I think the proper way to go is to do a fork of the official repo and apply my fixes there.

[alkis]

Build stops on 'configure' libnix.

System: mint (ubuntu based) 64bit

DEBUG: enter directory ".build-m68k/build/libnix"
DEBUG: execute "/home/alex/amiga/amigaos-cross-toolchain/submodules/libnix/configure --prefix=/home/alex/amiga/gcc6/m68k-amigaos/libnix --host=i686-linux-gnu --target=m68k-amigaos"
creating cache ./config.cache
checking for gcc... m68k-amigaos-gcc
checking whether the C compiler (m68k-amigaos-gcc  ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
ERROR: command "/home/alex/amiga/amigaos-cross-toolchain/submodules/libnix/configure --prefix=/home/alex/amiga/gcc6/m68k-amigaos/libnix --host=i686-linux-gnu --target=m68k-amigaos" failed with 1

and the config.log of that

cat .build-m68k/build/libnix/config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:529: checking for gcc
configure:642: checking whether the C compiler (m68k-amigaos-gcc  ) works
configure:658: m68k-amigaos-gcc -o conftest    conftest.c  1>&5
configure:655:1: warning: return type defaults to 'int' [-Wimplicit-int]
/home/alex/amiga/gcc6/lib/gcc/m68k-amigaos/6.3.1d/../../../../m68k-amigaos/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
configure: failed program was:

#line 653 "configure"
#include "confdefs.h"

main(){return(0);}

I am using this

./toolchain-m68k --prefix=/home/alex/amiga/gcc6 --m32 build

[bebbo]

OK. I changed the build order: libgcc is now built before libnix.

[alkis]

It builds correctly now. Thanks!

[alkis]

Is the standard c++ hello world supposed to compile and work?
...or are c++ streams currently not supported?

#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "Hello world\n";
  return 0;
}

(It doesn't compile for me)

[Samurai_Crow]

Originally Posted by alkis

Is the standard c++ hello world supposed to compile and work?
...or are c++ streams currently not supported?

#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "Hello world\n";
  return 0;
}

(It doesn't compile for me)

LibStdC++ isn't done yet, AFAIK.

[Toni Wilen]

Not really 6.2 specific but if this becomes AROS m68k compiler some day.. (Hopefully soon enough)

6.3 (probably earlier 6.x version too) seems to have a bug, at least in 68000 mode:

Source (AROS poseidon.library.c)

/* /// "psdGetAttrsA()" */
AROS_LH3(LONG, psdGetAttrsA,
         AROS_LHA(ULONG, type, D0),
         AROS_LHA(APTR, psdstruct, A0),
         AROS_LHA(struct TagItem *, tags, A1),
         LIBBASETYPEPTR, ps, 22, psd)
{
    AROS_LIBFUNC_INIT
    struct TagItem *ti;
    ULONG count = 0;
    ULONG *packtab = NULL;

    KPRINTF(1, ("psdGetAttrsA(%ld, %p, %p)\n", type, psdstruct, tags));

    if(type <= PGA_LAST)
    {
        packtab = (ULONG *) PsdPTArray[type];
    }

<snip>

Generated code:

4792899C 48e7 3832                MOVEM.L D2-D4/A2-A3/A6,-(A7)
479289A0 2608                     MOVE.L A0,D3
479289A2 2449                     MOVEA.L A1,A2
479289A4 264e                     MOVEA.L A6,A3
; Right shift by 4? D0=1 (PGA_STACK) becomes zero..
; I guess this is optimized "if(type <= PGA_LAST)" test (PGA_LAST = 15) so shift by 4 becomes zero if <=15.
479289A6 e888                     LSR.L #$00000004,D0
479289A8 6600 023a                BNE.W #$023a == $47928be4
; this move should have been before above LSR.L..
; D0 is now always zero
479289AC 2200                     MOVE.L D0,D1
; *4
479289AE d280                     ADD.L D0,D1
479289B0 d281                     ADD.L D1,D1
; packtab = (ULONG *) PsdPTArray[type];
479289B2 41f9 4793 41dc           LEA.L $479341dc,A0
479289B8 2830 1800                MOVE.L (A0, D1.L*1, $00),D4
<snip>

[Fook42]

have encountered a new problem

what shall i do here? (to send a bug-report to the gnu-developers wont be the right way, will it be?)

MAININTRO.c: In function ‘GREATEFFECT’:
MAININTRO.c:426:1: error: unrecognizable insn:
 }
 ^
(insn 2323 2326 1228 (set (strict_low_part (reg:QI 0 d0 [orig:778 AScr ] [778]))
        (mem (reg:SI 10 a2) [0  S0])) -1
     (nil))
MAININTRO.c:426:1: internal compiler error: in extract_insn, at recog.c:2287
0x87cc5ec _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:108
0x87cc615 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:116
0x878a4cf extract_insn(rtx_insn*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2287
0x878a1d1 extract_insn_cached(rtx_insn*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2178
0x852b169 cleanup_subreg_operands(rtx_insn*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:3106
0x852abd4 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2907
0x852928f final(rtx_insn*, _IO_FILE*, int)
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2045
0x852d3ce rest_of_handle_final
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4448
0x852d5a4 execute
        /home/renef/AMIGA/new/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4523
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[bebbo]

Best way is:
1. Create a ticket at https://github.com/bebbo/amigaos-cross-toolchain/issues
2. If you wanna support me more: test if it's one of my optimizers and maybe which one, by compiling/testing with
a) bebbo's optimizers disabled: -fbbb=-
b) watch which optimizers are used: -fbbb=+v
c) test with specific optimizers enabled: -fbbb=aspcemrfbv
(test each single letter or combinations of letters)

An example is https://github.com/bebbo/amigaos-cro...hain/issues/19

[bebbo]

Originally Posted by Toni Wilen

Not really 6.2 specific but if this becomes AROS m68k compiler some day.. (Hopefully soon enough)

6.3 (probably earlier 6.x version too) seems to have a bug, at least in 68000 mode:

You forgot to mention that you are using -Os.
I built a small test case:

long f(register unsigned type asm("d0"))
{
  if(type <= PGA_LAST)
  {
    unsigned const * p = PsdPTArray[type];
    return *p;
  }      
  return -1;
}

and can reproduce that bug only with -Os .

That bug is presumably caused by the register parameter since using a stack parameter let's that weird LSR instruction vanish.

Not sure if I can fix that.

[Fook42]

Originally Posted by bebbo

Best way is:
1. Create a ticket at https://github.com/bebbo/amigaos-cross-toolchain/issues

..done

hope that helps you - if there is anything more i need to provide, please let me know

[wawa]

im trying to update to test what toni requests, but i ran into:

error: no such remote ref 9e1dd52e9e1bdb1ca9af945c5853b9d5b3a9fb46
Fetched in submodule path 'submodules/gcc-6', but it did not contain 9e1dd52e9e1bdb1ca9af945c5853b9d5b3a9fb46. Direct fetching of that commit failed.

does it currently build? perhaps i need to delete everytning and start over clean?

[bebbo]

dang - sorry - i published a wrong commit...
... merged it back now - hope I did not mess it totally up now...

/duck

[wawa]

Originally Posted by bebbo

dang - sorry - i published a wrong commit...
... merged it back now - hope I did not mess it totally up now...

/duck

thx, it built

[Toni Wilen]

Originally Posted by bebbo

and can reproduce that bug only with -Os .

I forgot that -Os is AROS m68k default. -O1 just fits (only 13k free, vs -Os which leaves ~70k free), -O2 does not fit (26k too big). I haven't done any performance tests. (Note that debugging was disabled but serial logging is enabled)

-O1 does "fix" it. (test is done with normal cmp.w)

[bebbo]

Originally Posted by Toni Wilen

I forgot that -Os is AROS m68k default. -O1 just fits (only 13k free, vs -Os which leaves ~70k free), -O2 does not fit (26k too big). I haven't done any performance tests. (Note that debugging was disabled but serial logging is enabled)

-O1 does "fix" it. (test is done with normal cmp.w)

-Os uses a different optimizer pass named "hoist" instead of "pre".

Maybe you can reach almost the code size of -Os by using -O1 plus disabling some of the size expensive optimizations.