This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch,AVR] Fix PR51345: split multilibs for SPH / no-SPH devices
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: Joerg Wunsch <joerg_wunsch at uriah dot heep dot sax dot de>
- Cc: gcc-patches at gcc dot gnu dot org, Denis Chertykov <chertykov at gmail dot com>, Eric Weddington <eric dot weddington at atmel dot com>
- Date: Thu, 15 Dec 2011 18:43:11 +0100
- Subject: Re: [Patch,AVR] Fix PR51345: split multilibs for SPH / no-SPH devices
- References: <4EEA048A.4070005@gjlay.de> <20111215170440.GG2063@uriah.heep.sax.de>
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