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.