This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Stack frame problem.


Dear gcc maintainers,

Has there ever been reported problems pertaining
to the extensive use of inline functions into C++
code that gets compiled with gcc ? It seems that
the stack frames get messed up at run time when to
much inlines are used.

As an example , consider the following code.

VOID TLineInfrastructure::AddKiloMeterPoleRegionToConductingLine(FLT32 Start)
{ // TLineInfrastructure::AddKiloMeterPoleRegionToConductingLine

  // if (m_pCurLine->LastKiloMeterPoleRegionLaysBefore(Start)) {

    m_pCurKmPoleReg = new TKiloMeterPoleRegion(Start);

--> m_pCurKmPoleReg->LaysBefore(Start);

    mKmPoleRegColl.Add(m_pCurKmPoleReg,TRUE);
    m_pCurLine->AddKiloMeterPoleRegion(m_pCurKmPoleReg);

#if 0
  }
  else
    exit(EXIT_FAILURE);

#endif

} // TLineInfrastructure::AddKiloMeterPoleRegionToConductingLine

BOOLEAN TKiloMeterPoleRegion::LaysBefore(FLT32 Start)
{
  return Start > mStart + mEquiDistStp * mSeqNr;
}

Special attention has to be payed at the line of
code pointed to with the little arrow. When one
compiles the code with the method "LaysBefore"
declared as inline , unpredictable behaviour
occures. For instance one passes a value of 50.2
to the parameter start. At one deeper level of the
call stack that parameter suddenly has a value of
0 instead of the expected 50.2. If that same
method has been implemented as a normal C++ method
however , the compiled code behaves normally.

Greetings , Pype Pascal.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]