GCC 6.2 toolchain for AmigaOS 3

[bebbo]

Originally Posted by guy lateur

I'm using this command, btw:

./toolchain-m68k --prefix=/opt/m68k-amigaos --threads=12 build

Could that prefix thing have anything to do with anything?

that 'anything' defines the destination where to put the files to

[guy lateur]

Originally Posted by bebbo

that 'anything' defines the destination where to put the files to

Oh yeah.
So no, then..

[guy lateur]

Originally Posted by guy lateur

I just did a clean and I'm rebuilding now..

Rebuilding after a clean took a little more than 50 minutes, so we're still making progress. I guess I'll just await my new SSD and do some more testing on that..

[bebbo]

Originally Posted by guy lateur

Rebuilding after a clean took a little more than 50 minutes, so we're still making progress. I guess I'll just await my new SSD and do some more testing on that..

redirecting into a file seems to help too - console is scrolling slowly.

./toolchain-m68k build --threads=8 >& b.log

[Marlon_]

Wait, do you mean that you're pulling the entirety of gcc+ branches each time when you say "fresh pull"? Because gcc is huge (like several GBs) and may take forever depending on how slow your internet connection is.

[bebbo]

Originally Posted by Marlon_

Wait, do you mean that you're pulling the entirety of gcc+ branches each time when you say "fresh pull"? Because gcc is huge (like several GBs) and may take forever depending on how slow your internet connection is.

If you pull you do a

git pull

.

I only ment: pull again - do not rely on your pull 5 sconds ago.

[Marlon_]

Originally Posted by bebbo

If you pull you do a

git pull

.

I only ment: pull again - do not rely on your pull 5 sconds ago.

It was meant as a question to guy_lateur.

[guy lateur]

Originally Posted by Marlon_

It was meant as a question to guy_lateur.

Hehe, I thought so. No, I meant just pulling bebbo's github repository again, into an new amigaos-cross-toolchain directory. So my first command was this:

git clone git://github.com/bebbo/amigaos-cross-toolchain.git

Downloading the 'entirety of gcc+ branches' was only done once, using the apt-cyg command, as described in the readme. If I run this again, it just says everything is already installed, and it doesn't download anything.

Anyway, I'll be doing further timing test from a clean build (and so not downloading anything, I guess). I'd like this process to time itself, though, so I wrote a script to do this. I also redirected the ouput to null, which is probably even more efficient than to a file. Here's my script:

#!/bin/bash
start=$(date +%s)
 
./toolchain-m68k build --threads=12 >&/dev/null
 
end=$(date +%s)
runtime=$(python -c "print '%u:%02u' % ((${end} - ${start})/60, (${end} - ${start})%60)")
echo "Runtime was $runtime"

What y'all think? Should I just go for it?

[Marlon_]

Originally Posted by guy lateur

Hehe, I thought so. No, I meant just pulling bebbo's github repository again, into an new amigaos-cross-toolchain directory.

Bebbo's repository includes the gcc6 repository as a submodule, which is large. So everytime you make a new clone of the repository and run the toolchain command, you re-download the entire gcc6 repository too, which is probably why it takes so long for you each time.

[guy lateur]

Originally Posted by Marlon_

Bebbo's repository includes the gcc source as a submodule, which is large. So everytime you make a new clone of the repository and run the toolchain command, you re-download the entire gcc6 repository too, which is probably why it takes so long for you each time.

Ok, I didn't know bebbo's repository included the huge gcc source, thanks pointing that out.

As mentioned above though, I no longer do that, and when I build from a clean source, it still takes about 50 minutes -- which apparently is way more than expected on my rig. I'm still trying to figure out why that is..

[Marlon_]

Originally Posted by guy lateur

Ok, I didn't know bebbo's repository included the huge gcc source, thanks pointing that out.

As mentioned above though, I no longer do that, and when I build from a clean source, it still takes about 50 minutes -- which apparently is way more than expected on my rig. I'm still trying to figure out why that is..

How do you mean "clean source"?

[guy lateur]

Originally Posted by Marlon_

How do you mean "clean source"?

I do a './toolchain-m68k clean' first, and then a './toolchain-m68k build'

[guy lateur]

Ok, I've cleaned the build (took 41 seconds), and I've jus started a (timed) build which redirects its output to /dev/null. I'll let you know the results when it's done.

[Marlon_]

Originally Posted by guy lateur

Ok, I've cleaned the build (took 41 seconds), and I've jus started a (timed) build which redirects its output to /dev/null. I'll let you know the results when it's done.

This is how long it takes for me after ./toolchain-m68k clean:

[marlon@hastur]:~/amigaos-cross-toolchain$ date; m68k-build --threads=8 >& b.log;date
Mon Jun 19 22:11:37 CEST 2017

Mon Jun 19 22:26:59 CEST 2017

Approximately 15 minutes.

But this machine is a dedicated Intel Xeon server, so that might improve the compile time too.

[guy lateur]

Originally Posted by Marlon_

This is how long it takes for me after ./toolchain-m68k clean:

[marlon@hastur]:~/amigaos-cross-toolchain$ date; m68k-build --threads=8 >& b.log;date
Mon Jun 19 22:11:37 CEST 2017

Mon Jun 19 22:26:59 CEST 2017

Approximately 15 minutes.

But this machine is a dedicated Intel Xeon server, so that might improve the compile time too.

Thanks for the reference!

My script just finished, and it took just over 35 minutes. This is way better than what I used to have, but still more than 2 times slower than your time. My specs are here: http://eab.abime.net/showpost.php?p=...&postcount=330 (building on an SSD, btw).

Could our different specs explain our different runtimes, you think?

[Marlon_]

Originally Posted by guy lateur

Thanks for the reference!

My script just finished, and it took just over 35 minutes. This is way better than what I used to have, but still more than 2 times slower than your time. My specs are here: http://eab.abime.net/showpost.php?p=...&postcount=330 (building on an SSD, btw).

Could our different specs explain our different runtimes, you think?

Perhaps. You have more cores and threads than me though. But that doesn't rule out that my processor could be better optimized for multi-threading.

But if Bebbo get 18 mins on his 5 year old laptop, I feel like my server should be able to compile faster than 15 min.

This is the CPU I have: http://ark.intel.com/products/88172/...Cache-3_00-GHz

[guy lateur]

Originally Posted by Marlon_

Perhaps. You have more cores and threads than me though. But that doesn't rule out that my processor could be better optimized for multi-threading.

But if Bebbo get 18 mins on his 5 year old laptop, I feel like my server should be able to compile faster than 15 min.

This is the CPU I have: http://ark.intel.com/products/88172/...Cache-3_00-GHz

I seem to recall you said you're doing this on Linux/osx, while I'm doing it through cygwin-32 on win7-64. That might explain some of the differences, I've heard. I'll be trying this on Linux/win10 as soon as I get my new SSD.

I also feel I should definitely end up below bebbo's laptop time, tbh, even without doing anything!

[Leffmann]

Did you try building on a RAM-drive yet?

Another thing to try is to turn off the real-time protection in your AV software during building. Most AV softwares on Windows will be triggered every time a file is created on disk, and there are lots produced during the build.

[guy lateur]

Originally Posted by Leffmann

Did you try building on a RAM-drive yet?

Another thing to try is to turn off the real-time protection in your AV software during building. Most AV softwares on Windows will be triggered every time a file is created on disk, and there are lots produced during the build.

No, I didn't try the RAM-drive yet, but thanks for reminding me; I should definitely check that out.

I do have to turn off my AVG-free while doing this; otherwise it would pop up more frequently than its layout manager seems to be able to handle..

[Marlon_]

@bebbo
Latest revision of the toolchain makes the compiling of milkytracker broken.
It compiles fine at -O3, but I get "Program aborted" when I try to run it.
It compiles fine at -O2 too, but I haven't gotten around to try to run it yet.

-Os and -O1 gives me compiler errors.

Maybe these errors are related to why I can no longer execute milkytracker when compiled with -O3?

I have not made any significant changes in my code.

-Os:

In file included from ../src/milkyplay/ResamplerFactory.cpp:42:0:
../src/milkyplay/ResamplerAmiga.h: In member function ‘void ResamplerAmiga<filterTable>::addBlockNoCheck(mp_sint32*, ChannelMixer::TMixerChannel*, mp_uint32) [with int filterTable = 0]’:
../src/milkyplay/ResamplerAmiga.h:269:2: error: unrecognizable insn:
  }
  ^
(insn 458 139 140 (set (reg:SI 3 d3 [263])
        (mult:SI (post_inc:SI (reg:SI 3 d3 [261]))
            (mem:SI (reg/f:SI 8 a0 [orig:154 _179 ] [154]) [1 _179->level+0 S4 A16]))) -1
     (nil))
../src/milkyplay/ResamplerAmiga.h:269:2: internal compiler error: in extract_insn, at recog.c:2287
0xdce75b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:108
0xdce79c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:116
0xd82900 extract_insn(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2287
0xd825cf extract_insn_cached(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2178
0xaed844 cleanup_subreg_operands(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:3106
0xaed23a final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2907
0xaeb6d5 final(rtx_insn*, _IO_FILE*, int)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2045
0xaefeaa rest_of_handle_final
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4448
0xaf00a8 execute
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4523

-O1:

In file included from ../src/milkyplay/ResamplerFactory.cpp:42:0:
../src/milkyplay/ResamplerAmiga.h: In member function ‘void ResamplerAmiga<filterTable>::addBlockNoCheck(mp_sint32*, ChannelMixer::TMixerChannel*, mp_uint32) [with int filterTable = 0]’:
../src/milkyplay/ResamplerAmiga.h:269:2: error: unrecognizable insn:
  }
  ^
(insn 541 143 144 (set (reg:SI 7 d7 [289])
        (mult:SI (post_inc:SI (reg:SI 7 d7 [287]))
            (mem:SI (reg/f:SI 9 a1 [orig:163 _184 ] [163]) [1 _184->level+0 S4 A16]))) -1
     (nil))
../src/milkyplay/ResamplerAmiga.h:269:2: internal compiler error: in extract_insn, at recog.c:2287
0xdce75b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:108
0xdce79c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:116
0xd82900 extract_insn(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2287
0xd825cf extract_insn_cached(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2178
0xaed844 cleanup_subreg_operands(rtx_insn*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:3106
0xaed23a final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2907
0xaeb6d5 final(rtx_insn*, _IO_FILE*, int)
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2045
0xaefeaa rest_of_handle_final
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4448
0xaf00a8 execute
        /home/marlon/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4523