Re: ATMega 2560 + RAMPZ + 128Kplus and the realproblem on GCC

> > >Starting with gcc 4.7.x, code
> > >beyond 128 KB works right away provided you link with relaxation turned
> > >on
> > 
> > Why would relaxation needed to be turned on?
> > 
> 
> That was because of PR 14058, which, I just realized, is already fixed

Ah, so.

I put up this question already twice, once on avrfreaks.net, once here, and never received any answer, not even from Georg-Johann who put that remark into the official gcc documentation; so I am assuming that at least he is still uncertain that that was the only issue and that the fix solved it. 

I always deliberately avoided the situations which would result in trampolines in my ATMega256x project (and am still using a 2007-vintage WinAVR as my main tool), so, as a matter of fact, I don't have personal experience with this issue.

Also, purely technically, it's not the compiler version which is pertinent to the trampolines/stubs-related bugs fixes, as they were fixed in the linker (unless there were other related bug fixes in the compiler itself I am not aware of).

> So I guess relaxation in this case only serves to reduce the size of the
> trampoline table then, by not generating stubs for code that is
> reachable directly?

That is the intention at least (although, again purely technically, I would speak of the relaxation process removing the unneeded stubs after they have been created by the "regular" linking process).

JW