Re: Patch to allow targets to prevent inlining

[Jeffrey A Law <law at cygnus dot com>]

  In message <200002150026.QAA29365@localhost.cygnus.com>you write:
  > > Mailing-List: contact binutils-help@sourceware.cygnus.com; run by ezmlm
  > > List-Unsubscribe: <mailto:binutils-unsubscribe-geoffk=cygnus.com@sourcewa
  > re.cygnus.com>
  > > List-Subscribe: <mailto:binutils-subscribe@sourceware.cygnus.com>
  > > List-Archive: <http://sourceware.cygnus.com/ml/binutils/>
  > > List-Post: <mailto:binutils@sourceware.cygnus.com>
  > > List-Help: <mailto:binutils-help@sourceware.cygnus.com>, <http://sourcewa
  > re.cygnus.com/ml/#faqs>
  > > Date: Mon, 14 Feb 2000 16:15:24 -0800
  > > From: Nick Clifton <nickc@cygnus.com>
  > > CC: binutils@sourceware.cygnus.com
  > > 
  > > Hi Doug,
  > > 
  > > :  > Besides, just because it wouldn't be needed for naked
  > > :  > functions any more, there is no reason to suppose that individual
  > > :  > targets might not have other reasons for suppressing inlining.
  > > : 
  > > : Perhaps.  But complexity should alway be defered as long as possible.
  > > 
  > > True.
  > > 
  > > OK, you win.  But since adding a naked attribute the to generic part
  > > of gcc would increase the overall complexity of the compiler, I doubt
  > > it I would be able to persuade the steering committee to accept it
  > > unless several more ports wanted the feature.  Hmm, mnaybe we could
  > > start a campaign :-)
  > 
  > glibc needs this feature.  There are one or two places where some
  > functions must be inlined, and other functions must not, and they
  > all have to be in one C file (some of the ones that `must not' are the
  > ones that call the `must's :-( ).
Bad bad bad.  Depending on inlining or not inlining is an extremely bad
design.  Someone would fix glibc to not make those kinds of assumptions about
what the compiler will or will not inline.
jeff