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

[Evan Cheng]

On Nov 2, 2007, at 6:22 PM, Bill Wendling wrote:

> 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.

Should we use "static inline" instead of plain out "inline" to  
prevent copies of the functions?

Evan

>
> Once we get LLVM-GCC 4.2 building the Apple Way, then we can redress
> this issue if people have worries about it.
>
> -bw
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits