Joerg Wunsch wrote: > As Georg-Johann Lay wrote: > >> With the patch it looks like so: >> >> . >> ./tiny-stack >> ./avr25 >> ./avr25/tiny-stack >> ./avr3 >> ./avr31 >> ./avr35 >> ./avr4 >> ./avr5 >> ./avr51 >> ./avr6 >> >> -mtiny-stack is a partial multilib option now: > > Is there any need to still keep the -mtiny-stack option any longer at > all?
In the proposed patch the option is needed to trigger the appropriate multilib. Different approach would be to add SP=8-only multilibs avr21, avr26 or whatever, but then: * User has no influence as to what multilib he prefers. * This results in bit strange mapping as the linker/assembler don't know (and need not to know) about architectures avr21, avr26, ... It can be mapped by means of specs and initially I followed that approach, but this solution with mtiny-stack is canonical approach. > I think it has only been invented since AVR-GCC always used to code to > handle SPH, regardless of whether the device actually uses SPH or not. > As this is now about to be fixed (thanks!), who would have a need for > -mtiny-stack any longer? As explained above it is the (partial) multilib trigger. The option cold be hidden/undocumented but I don't see benefit of that. Johann
