troublesome change

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

I've been finding that EGCS snapshots output inline functions when
other older releases would not at all.  I noticed it was happening as
a result of an inline whose definition appeared within' another
function and thus was nested.  This helped me track it down to this
change:

Fri May 15 18:49:30 1998  Mark Mitchell  <mmitchell@usa.net>

	* toplev.c (rest_of_compilation): Don't defer nested functions.

and this bit of code:

      if (! current_function_contains_functions
	  && ! decl_function_context (decl)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is breaking a few bits of code which I test EGCS with, in
particular the glibc-2.0.x sources on the Sparc.  The problem case is
the following:

/* Return the run-time load address of the shared object.  */
static __inline__ Elf32_Addr __attribute__ ((unused))
elf_machine_load_address (void)
{
  register Elf32_Addr pc __asm("%o7"), pic __asm("%l7"), got;

  /* Utilize the fact that a local .got entry will be partially
     initialized at startup awaiting its RELATIVE fixup.  */

  __asm("sethi %%hi(.Load_address),%1\n"
        ".Load_address:\n\t"
        "call 1f\n\t"
        "or %1,%%lo(.Load_address),%1\n"
        "1:\tld [%2+%1],%1"
        : "=r"(pc), "=r"(got) : "r"(pic));

  return pc - got;
}

This gets inlined into various parts of the dynamic linker on the
Sparc in glibc.  The output of the inline function code results in
that assembler sequence appearing twice, something which we knew was
impossible with gcc when that bit of code was written.  But now two
instances of the .Load_address symbol appear and the assembler
complains loudly.  For the trick we are using above it is absolutely
crucial that the symbol appears only once, and thus the inline
function code gets output only once.

This is a bug, even if only because it breaks compatability with
previous egcs and gcc releases.

Richard Henderson informed me that the g77 people have been hit by
this change and have "worked around" it by hiding statement functions
from the backend completely based upon some set of conditions.  This
is gross. :-(

This really is quite wrong, and the fact that now it affects multiple
front ends suggests that whatever bug necessitated that workaround
change should be what is fixed and the workaround removed.

If someone can explain to me the bug which this fixed, I'd be more
than happy to help fix the real problem so that this bandaid can
disappear.

Later,
David S. Miller
davem@dm.cobaltmicro.com