[llvm-commits] [llvm-gcc-4.2] r43655 - in /llvm-gcc-4.2/trunk: configure configure.in

[Bill Wendling]

On 11/2/07, Bill Wendling <isanbard at gmail.com> wrote:
> Author: void
> Date: Fri Nov  2 20:01:16 2007
> New Revision: 43655
>
> URL: http://llvm.org/viewvc/llvm-project?rev=43655&view=rev
> Log:
> Remove the use of the "-fkeep-inline-functions" flag. LLVM inlines
> everything, and, because some files here use LLVM headers and those
> headers have inlined functions in them, keeping them non-inlined in
> the LLVM-GCC part results in undefined symbol problems.
>
Some clarification. I was getting "undefined symbols" errors when
compiling LLVM-GCC 4.2 the "Apple way" for these methods:

inline void PATypeHandle::addUser() {
  assert(Ty && "Type Handle has a null type!");
  if (Ty->isAbstract())
    Ty->addAbstractTypeUser(User);
}
inline void PATypeHandle::removeUser() {
  if (Ty->isAbstract())
    Ty->removeAbstractTypeUser(User);
}

// Define inline methods for PATypeHolder...

inline void PATypeHolder::addRef() {
  if (Ty->isAbstract())
    Ty->addRef();
}

inline void PATypeHolder::dropRef() {
  if (Ty->isAbstract())
    Ty->dropRef();
}

I talked with Dale and he said that the flag wouldn't prevent inlining
from happening, but it will keep around a copy of the function that
was inlined. This reduces this fix to a hack. I'm not sure of the root
cause of the undefined symbols. I can guess at a few things, though.

Once we get LLVM-GCC 4.2 building the Apple Way, then we can redress
this issue if people have worries about it.

-bw