This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/52737] New: [avr]: -mtiny-stack shall not influence multilib selection
- From: "gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 27 Mar 2012 11:27:08 +0000
- Subject: [Bug target/52737] New: [avr]: -mtiny-stack shall not influence multilib selection
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52737
Bug #: 52737
Summary: [avr]: -mtiny-stack shall not influence multilib
selection
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: gjl@gcc.gnu.org
Target: avr
The current (4.7.0) behaviour is:
-mtiny-stack acts as multilib-option for 16-bit SP targets in avr2 and avr25,
i.e. with that switch will trigger multi-lib from ./tiny-stack resp.
./avr25/tiny-stack
The problem is that the tiny-stack multilibs mix 16-bit SP targets that are
treated as 8-bit SP, and targets with 8-bit SP.
The currect implementation assumes SP.H = 0 in tiny-stack mlibs in order to
properly initialize the frame pointer, e.g. in __prologue_saves.
This is no good for 16-bit SP targets.
Solution:
Restore the behaviour for the 16-bit SP targets as was, i.e. -mtiny-stack does
not affect multilib selection for these targets, but if specified on the
command line, the resulting code will only change SP.L and assume SP.H never
changes.
For the 8-bit SP targets, -mtiny-stack should remain as in 4.7.0, i.e. used
internally to trigger tiny-stack multilibs. Specifying -mtiny-stack on the
command line will be redundant for these targets and have no effect.