optimization/2072: SPARC leaf function loses %l7 contents spuriously

[eljay@adobe.com]

>Number:         2072
>Category:       optimization
>Synopsis:       SPARC leaf function loses %l7 contents spuriously
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 23 10:46:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Love-Jensen
>Release:        GCC 2.95.2
>Organization:
>Environment:
Solaris 2.6, 7, 8.
Core in an -fPIC .so.
C++ souce code.
2.10.0 C++ lib.
>Description:
Once in a blue moon, the PMMU has to grab another
virtual page to extend the stack.

The optimizer (and I'm not sure which -fXXX flag it is)
aggresively opimizes the leaf functions
so as not to reload %l7 register (by ubiquitous
convention, the _GLOBAL_OFFSET_TABLE_ address).

%l7 (aka %r23) is a subroutine's local scratch variable.

The optimization figures out that %l7 must have been
already seeded, and need not be seeded again.

Here's were the interplay can occur:  APPARENTLY, when a
routine is entered, if the PMMU has to allocate another
4K (whatever) page of memory to extend the stack,
apparently the %l7 register isn't preserved when
entering the routine.

As far as I can tell, there is no guarantee that the
%l0-7 (%r16-23) registers will be preserved, between
subroutine invocations.  At least, not in the
SYSTEM V ABI (3rd ed) spec.

This is in -fPIC code in particular.  Code that resides in a
static shared object (.so).  (I just found out about the
-mno-app-regs flag, maybe that's the real error -- but
I doubt it.)

The value, in particular, that causes the core happens to
be a literal constant double '2.0' in whatever segment the
literal constants are stored in.  Just a FYI, if that's
an important tidbit of information.
>How-To-Repeat:
Good question, it's an infrequent issue:  it crops up
about once in 10,000 runs of the same binary on the
same computer with other active processes burdening
the PMMU.  I'm trying to find a workaround, or a GCC
flag to disable this "trust %l7 to be pre-set to the
_GLOBAL_OFFSET_TABLE_" optimization.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: