GCC 4.5.0 Amigaos 68k Compiler CYGWIN Hostet

[Piru]

Newer GCC as 2.x can inline over a linked lib.

Could you elaborate a bit? GCC 3 certainly didn't do LTO, if that's what you mean. As far as I can tell it was only added in 4.5.

[Piru]

the Versions are clean GCC builds from offical source.They dont contain the inoffical AOS Hacks that work buggy and so not add in GCC Main source.

I'm not so sure if that was the reason they weren't included. When GCC went thru massive changes no-one just wasn't around to port them and they weren't seen as important enough to keep around.

In fact, now that I think about it: Were they ever even included in the main gcc tree? I remember gcc "amiga" patchsets from long long ago.

[Piru]

LTO is optimizing over whole code.

I know what LTO does. It wasn't included in gcc3.

I have not test LTO on 4.5 if that work.maybe need a special linker.

According to documentation you don't.

but what work since GCC 3 is the inline of a lib func so for short funcs you need no calls and so need not pass the registers on stack or register.

I do tests with the ixemul libc.a some time ago.

the sourcercode in libc.a is this

__attribute__((always_inline)) inline double hypot(double x,double y)
{
 return sqrt(x*x+y*y);
}
 
this is the main source and create a ixemul prog (because only link with -ldebug)

#include
main(int argv,int argc)
{
   double value;
   value=hypot(argc,argv);
   kprintf("%f\n",value);
}


I compile with -O1.

when i load the compiled exe in asm debugger it look as this.You see there is no call do and all is inline.
_main
+0000(10E33D22): LINK    A5,#-$48            
+0004(10E33D26): MOVEM.L D2-D3/A6,-(A7)      
+0008(10E33D2A): BSR.L   ___main      ;10E340
+000E(10E33D30): FMOVE.L $C(A5),FP0          
+0014(10E33D36): FMOVE.L 8(A5),FP1          
+001A(10E33D3C): FMUL.X  FP0,FP0            
+001E(10E33D40): FMUL.X  FP1,FP1            
+0022(10E33D44): FADD.X  FP1,FP0            
+0026(10E33D48): FSQRT.X FP0                
+002A(10E33D4C): FMOVE.D FP0,-(A7)          
+002E(10E33D50): PEA     _moncontrol+4(PC) ;10E33C84
+0032(10E33D54): BSR.L   _kprintf     ;10E33F74

How does that work exactly? If you have a function call to external function (and you don't use LTO), how can it replace the jump to the subroutine with other code?

If you mean you have to introduce all the inline functions in the headers then this is absolutely nothing new over gcc 2.x.

[Piru]

curios X86 have few register, better is maybe for RISC or use PPC always regparm now ?
I remember only warpup and powerup time, with GCC 2.xx.Here i see the parameter are put on stack.

IIRC both use System V ABI, although WarpUP breaks it by having the applications reuse r2. There's a fixed system on how the parameters are passed. See 3-18 Parameter Passing.

[Piru]

the default of the compiler is that FPU return values are always in d0 and d1.the reason is in that way there can work software float.

The linux 68k elf GCC use the FPU for return, i can too switch it easy on(i have get answer in GCC ML what need change), but here must be sure that all libs are fpu version and all libs need recompile.

but when such a big step is do and all libs need make new, then better change AOS GCC that it use elf format.so its more easy to have newest binutils for this.
in elf can also work the LTO.

Well that makes absolutely no sense whatsoever.

Care to explain in simple terms why the binaries would need to be ELF all the sudden?

[Piru]

i think nobody add LTO support for a.out.
sooner or later the old a.out(which amiga use) format in GCC is drop too.

Yeah fine, but why would it require that the final resulting executables be ELF, too?