GCC 6.2 toolchain for AmigaOS 3

[bebbo]

1000!

[alkis]

Originally Posted by bebbo

...
2. no idea guess hth313 is right here and it's too simple that even without optimizer that variable is discarded.

generated code

Isn't -8(a5) the 't' variable?

[cdh]

I'm not great at reading 68k assembler, but think it's the a0 value after this statement:

add.l d0,a0

[hth313]

Originally Posted by alkis

Isn't -8(a5) the 't' variable?

Probably, though it can also be an introduced temporary with no real name that happens to behave the same as 't'. Given the quite rudimentary code generation model displayed here, I would however lean towards that you are most likely correct.

In any case, debug information is not done right or incorrectly interpreted on the debugger side.

[hth313]

Originally Posted by cdh

I'm not great at reading 68k assembler, but think it's the a0 value after this statement:

add.l d0,a0

That is the address of it. It is dereferenced on the following line

move.l (a0),-8(a5)

where the value is stored on the stack using the A5 frame pointer.

[_dante_]

Originally Posted by hth313

In any case, debug information is not done right or incorrectly interpreted on the debugger side.

So, very likely it means that debug information generated by gcc 6.4.1 compiler is not or could be not fully compatible with the gdb 8.2.50 debugger and to solve such compatibility issues changes on the compiler side in terms of debug information generation are required

[bebbo]

Originally Posted by _dante_

So, very likely it means that debug information generated by gcc 6.4.1 compiler is not or could be not fully compatible with the gdb 8.2.50 debugger and to solve such compatibility issues changes on the compiler side in terms of debug information generation are required

the debug info is ok:

00000214 <_main>:
#include <stdio.h>

int main(int argc, char **argv) {
     214:       4e55 fff8       link.w a5,#-8
        puts("hello world!");
     218:       487a ffd6       pea 1f0 <___exitcpp+0x18>(pc)
     21c:       4eb9 0000 0bb0  jsr bb0 <_puts>
     222:       588f            addq.l #4,sp
        printf("argc=%ld\r\n", argc);
     224:       2f2d 0008       move.l 8(a5),-(sp)
     228:       487a ffd3       pea 1fd <___exitcpp+0x25>(pc)
     22c:       4eb9 0000 0a94  jsr a94 <_printf>
     232:       508f            addq.l #8,sp
        for (int i = 0; i < argc; ++i) {
     234:       42ad fffc       clr.l -4(a5)
     238:       6024            bra.s 25e <_main+0x4a>
                char *t = argv[i];
     23a:       202d fffc       move.l -4(a5),d0
     23e:       e588            lsl.l #2,d0
     240:       206d 000c       movea.l 12(a5),a0
     244:       d1c0            adda.l d0,a0
     246:       2b50 fff8       move.l (a0),-8(a5)
                printf("arg=%s\r\n", t);
     24a:       2f2d fff8       move.l -8(a5),-(sp)
     24e:       487a ffb8       pea 208 <___exitcpp+0x30>(pc)
     252:       4eb9 0000 0a94  jsr a94 <_printf>
     258:       508f            addq.l #8,sp
        for (int i = 0; i < argc; ++i) {
     25a:       52ad fffc       addq.l #1,-4(a5)
     25e:       202d fffc       move.l -4(a5),d0
     262:       b0ad 0008       cmp.l 8(a5),d0
     266:       6dd2            blt.s 23a <_main+0x26>
        }
        return 0;
     268:       7000            moveq #0,d0
}
     26a:       4e5d            unlk a5
     26c:       4e75            rts

[alkis]

Git pull/make update/make all breaks today on newlib

make[7]: Entering directory '/home/alex/t/amiga-gcc/build-Linux/newlib/libm020/newlib/libc'
rm -f libc.a
rm -rf tmp
mkdir tmp
cd tmp; \
 for i in argz/lib.a stdlib/lib.a ctype/lib.a search/lib.a stdio/lib.a   string/lib.a signal/lib.a time/lib.a locale/lib.a reent/lib.a  errno/lib.a misc/lib.a ssp/lib.a     machine/lib.a sys/lib.a; do \
   m68k-amigaos-ar x ../$i; \
 done; \
m68k-amigaos-ar rc ../libc.a *.o
m68k-amigaos-ar: ../sys/lib.a: No such file or directory
m68k-amigaos-ranlib libc.a
rm -rf tmp
rm -f crt0.o
ln sys/crt0.o crt0.o >/dev/null 2>/dev/null || cp sys/crt0.o crt0.o
cp: cannot stat 'sys/crt0.o': No such file or directory
Makefile:1045: recipe for target 'crt0.o' failed

[bebbo]

Originally Posted by alkis

Git pull/make update/make all breaks today on newlib

make[7]: Entering directory '/home/alex/t/amiga-gcc/build-Linux/newlib/libm020/newlib/libc'
rm -f libc.a
rm -rf tmp
mkdir tmp
cd tmp; \
 for i in argz/lib.a stdlib/lib.a ctype/lib.a search/lib.a stdio/lib.a   string/lib.a signal/lib.a time/lib.a locale/lib.a reent/lib.a  errno/lib.a misc/lib.a ssp/lib.a     machine/lib.a sys/lib.a; do \
   m68k-amigaos-ar x ../$i; \
 done; \
m68k-amigaos-ar rc ../libc.a *.o
m68k-amigaos-ar: ../sys/lib.a: No such file or directory
m68k-amigaos-ranlib libc.a
rm -rf tmp
rm -f crt0.o
ln sys/crt0.o crt0.o >/dev/null 2>/dev/null || cp sys/crt0.o crt0.o
cp: cannot stat 'sys/crt0.o': No such file or directory
Makefile:1045: recipe for target 'crt0.o' failed

you need to run

make clean-prefix

or manually update the header file lib\gcc\m68k-amigaos\6.4.1b\include\c++\cstdlib with amiga-gcc\projects\gcc\libstdc++-v3\include\c_global\cstdlib

[alkis]

Originally Posted by bebbo

you need to run

make clean-prefix

or manually update the header file lib\gcc\m68k-amigaos\6.4.1b\include\c++\cstdlib with amiga-gcc\projects\gcc\libstdc++-v3\include\c_global\cstdlib

Yeap. Worked as a charm. Thanks!

[NovaCoder]

Originally Posted by arti

It just doesn't work for most stuff I tried.

It'a a great effort and I hope it to be usable one day.

I agree with Arti, I've tried using GCC 6.2 to build a few of my old ports and haven't managed to get anything to run properly unfortunately. It works fine with small projects and libraries but no luck with larger projects yet.

[pipper]

That’s a bit hand wavy. Can you elaborate? Does it not compile? Does it not link? Does it not run? Does it run but crash?
In either case please show more details.

I have been compiling large projects like Dopus5 and ScummVM and all my initial problems with the compiler have been ironed out by Bebbo diligently. The last big things I’m hoping for are better debugging and LTO

[NovaCoder]

Originally Posted by pipper

That’s a bit hand wavy. Can you elaborate? Does it not compile? Does it not link? Does it not run? Does it run but crash?
In either case please show more details.

I have been compiling large projects like Dopus5 and ScummVM and all my initial problems with the compiler have been ironed out by Bebbo diligently. The last big things I’m hoping for are better debugging and LTO

I can't provide any detailed debug info that will help unfortunately. I first tried building an SDL library which worked perfectly and then I tried building a version of AmiQuake which although it ran it was having memory issues which resulted in screen glitches. After that I tired compiling my port of DosBox which would just crash immediately on start up.

Not taking anything away from this updated version of GCC which is one the best things to come to classic Amiga development in recent years

[Marlon_]

I've managed to get Milkytracker running, which is a fairly large C++ project. I've also managed to get Robin Hood demo running together with arczi/arti.

The optimization in GCC6 needs to be tweaked though, a lot of the time, lowering to -O0/-O1 can get stuff running, while -O2 and higher does weird things.

I've managed to get Milkytracker stable on -O3 by working together with Bebbo to iron out the bugs. So don't expect stuff to magically happen without working together with Bebbo to figure out what's going wrong.

Arczi and Bebbo are currently looking into why anything above -O1 fails on the Robin Hood demo, afaik.

[NovaCoder]

Originally Posted by Marlon_

I've managed to get Milkytracker running, which is a fairly large C++ project. I've also managed to get Robin Hood demo running together with arczi/arti.

The optimization in GCC6 needs to be tweaked though, a lot of the time, lowering to -O0/-O1 can get stuff running, while -O2 and higher does weird things.

I've managed to get Milkytracker stable on -O3 by working together with Bebbo to iron out the bugs. So don't expect stuff to magically happen without working together with Bebbo to figure out what's going wrong.

Arczi and Bebbo are currently looking into why anything above -O1 fails on the Robin Hood demo, afaik.

That's very interesting, I built everything with -O2 so maybe that's why I was having issues, I'll try again with -OO/O1

Thanks

[alpine9000]

Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

[NovaCoder]

Originally Posted by alpine9000

Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

Great, very helpful. Thanks

[pipper]

...or upload your stuff to github and crowdsource the debugging

[bebbo]

Originally Posted by alpine9000

Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

My usual approach (yes, still happens then and now, prayers do not work out) is
- build all files in folder X
- copy all .o files into folder A
- build all files with -fbbb=- in folder X
- copy all .o files int folder B

now link and test in folder X. With -fbbb=- it should run if not try a different -O* option until files in folders X and B do work

now do a binary search:
1. copy half of the files from A to X
2. link and test
3. if ok repeat at 1. for the remaining files in A
4. if not replace the last copied files with files from B
5. go to 1 and check only the last copied files

at the end you have one file which causes the trouble.
now try the different letters to search which one is the bad guy

start with omitting 'e' then 'r' from the list of letters.

once found the offending letter, create asm files and compare these - maybe that's my job then^^

sometimes I'm still amazed at what my optimizers can do. not bad at all for random hacking

and use the latest version: gcc version 6.4.1b 20190106170304

[Marlon_]

Originally Posted by pipper

...or upload your stuff to github and crowdsource the debugging

+1

Amigans need to get out of the “keep it to myself” mentality, especially when it’s about open source code with licenses that explicitly states the source and its changes need to be shared if an executable is published.