2012/3/27 Georg-Johann Lay <a...@gjlay.de>:
> This patch fixes a problem with the -mtiny-stack option:
>
> Architectures avr2 and avr25 mix targets with 8-bit SP and 16-bit SP so that
> -mtiny-stack is no good for multilib selection:
>
> If a frame pointer has to be set up from an 8-bit SP it is a difference if
> there is no SP_H or of the SP is just treated as if it was 8 bits wide.
>
> In the first case the high byte must be set to 0. In the second case SP_H can
> be read.
>
> That is: The patch uses the size of hard SP for multilib selection and
> generation. The user-settable -mtiny-stack is used for size of soft SP for
> optimization purposes, but does not influence multilib selection or generation
> or how FP is deduced from SP.
>
> Notable changes are:
>
> -mtiny-stack is no more a multilib option and its semantics restored as was
> before PR51345 introduced multilibs for 8-bit SP targets.
>
> Multilib selection is performed by a new undocumented option -msp8. This
> option
> is only used internally and need not to be specified on the command line.
> -msp8
> is injected by DRIVER_SELF_SPECS as needed.
>
> There is no avr-specific multilib_raw[] needed any more. This turns
> genmultilib.awk considerably more easy and better to maintain. Much code could
> be kicked off.
>
> -print-multi-lib results are clean now. With the prior approach,
> -print-multi-lib printed phantom configurations like
>
> tiny-stack;@mmcu=at90s2313
> avr25/tiny-stack;@mmcu=attiny13
>
> which could confuse libc implementations like newlib or AVR-Libc during their
> configure stage as they evaluate -print-multilib-lib.
>
> Now -print-multi-lib yields
>
> .;
> avr25;@mmcu=avr25
> avr3;@mmcu=avr3
> avr31;@mmcu=avr31
> avr35;@mmcu=avr35
> avr4;@mmcu=avr4
> avr5;@mmcu=avr5
> avr51;@mmcu=avr51
> avr6;@mmcu=avr6
> avrxmega2;@mmcu=avrxmega2
> avrxmega4;@mmcu=avrxmega4
> avrxmega5;@mmcu=avrxmega5
> avrxmega6;@mmcu=avrxmega6
> avrxmega7;@mmcu=avrxmega7
> tiny-stack;@msp8
> avr25/tiny-stack;@mmcu=avr25@msp8
>
> which is perfect and clean. As you can see, the multilib directory structure
> is
> /unchanged/ i.e. their names are still
> ./avr25/tiny-stack
> etc.
>
> Ok for trunk?
>
> Johann
>
> PR target/52737
> * contrib/gcc_update (files_and_dependencies):
> Remove gcc/config/avr/t-multilib from touch data.
>
> gcc/
> PR target/52737
> * config.gcc (tm_file): Remove avr/multilib.h.
>
> * doc/invoke.texi (AVR Options): Adjust
> documentation of -mtiny-stack.
>
> * config/avr/genmultilib.awk: Remove code to generate multilib.h.
> (BEGIN): Use -msp8 as multilib option instead of -mtiny-stack.
> * config/avr/t-avr: Remove generation of multilib.h.
> * config/avr/t-multilib: Regenerate.
> * config/avr/multilib.h: Remove.
> * config/avr/avr.opt (-msp8): New option.
> (avr_sp8): New variable.
> * config/avr/driver-avr.c (avr_device_to_sp8): New function.
> * config/avr/avr.h (AVR_HAVE_SPH): New define.
> (AVR_HAVE_8BIT_SP): Also set by avr_sp8 i.e. -msp8.
> (avr_device_to_sp8): New prototype.
> (EXTRA_SPEC_FUNCTIONS): Add { "device_to_sp8", avr_device_to_sp8 }
> (DRIVER_SELF_SPECS): New define.
> * config/avr/avr-c.c (avr_cpu_cpp_builtins): New built-in defines:
> __AVR_SP8__, __AVR_HAVE_SPH__.
> * config/avr/avr.c (output_movhi): Use AVR_HAVE_SPH instead of
> AVR_HAVE_8BIT_SP to decide if SP_H is present.
> (avr_file_start): Ditto.
>
> libgcc/
> PR target/52737
> * config/avr/lib1funcs.S: Use __AVR_HAVE_SPH__ for SP_H checks
> instead of __AVR_HAVE_8BIT_SP__.
>
>
>
Approved.
Denis.
