llvm dev - Mar 2009 - [LLVMdev] [LLVMDev] trouble building gcc-frontend from source

On Fri, Mar 13, 2009 at 8:09 PM, John Criswell <criswell at cs.uiuc.edu>
wrote:
> Gautam Sewani wrote:
>> On Fri, Mar 13, 2009 at 2:38 PM, Duncan Sands <baldrick at
free.fr> wrote:
>>
>>> Hi, the versions of llvm-gcc and llvm you are using are
>>> not synchronized.  Probably one is from subversion while
>>> the other is not.
>>>
> I've run into this, too.  The problem is that the inliner pass uses a
30
> bit integer to store the inline cost; the code that calculates the
> inline cost generates a cost that is too large, and so you hit the
> assertion.
>
> I haven't yet distilled a test case for this yet (had some problems
with
> bugpoint for some mysterious reason), but I do have a work-around: go
> into include/llvm/Transforms/Utils/InlineCost.h and make the following
> change:
>
>
> Index: InlineCost.h
> ==================================================================> ---
InlineCost.h        (revision 66848)
> +++ InlineCost.h        (working copy)
> @@ -37,8 +37,13 @@
>       Never
>     };
>
> +#if 0
>     int Cost : 30;
>     unsigned Type :  2;
> +#else
> +    int Cost;
> +    unsigned Type :  2;
> +#endif
>
>     InlineCost(int C, int T) : Cost(C), Type(T) {
>       assert(Cost == C && "Cost exceeds InlineCost
precision");
>
> Basically, you're changing the inline cost variable from 30 to 32 bits.
> After that, do a RELEASE build of LLVM and retry building llvm-gcc.
>
> -- John T.
>
That worked like a charm. Thanks a lot!

Gautam

On Mar 13, 2009, at 10:45 PM, Gautam Sewani wrote:
> On Fri, Mar 13, 2009 at 8:09 PM, John Criswell  
> <criswell at cs.uiuc.edu> wrote:
>> Gautam Sewani wrote:
>>> On Fri, Mar 13, 2009 at 2:38 PM, Duncan Sands <baldrick at
free.fr>
>>> wrote:
>>>
>>>> Hi, the versions of llvm-gcc and llvm you are using are
>>>> not synchronized.  Probably one is from subversion while
>>>> the other is not.
>>>>
>> I've run into this, too.  The problem is that the inliner pass uses
>> a 30
>> bit integer to store the inline cost; the code that calculates the
>> inline cost generates a cost that is too large, and so you hit the
>> assertion.
>>
>> I haven't yet distilled a test case for this yet (had some problems
>> with
>> bugpoint for some mysterious reason), but I do have a work-around: go
>> into include/llvm/Transforms/Utils/InlineCost.h and make the  
>> following
>> change:
Glad that works for you, but it means that if the 32-bit cost  
computation overflows, we won't be told about it.   I think the right  
thing is to make sure the computation saturates at 30 bits instead of  
overflowing.  Am I going to talk myself into overloading operator+ ?
>> Index: InlineCost.h
>>
==================================================================>> ---
InlineCost.h        (revision 66848)
>> +++ InlineCost.h        (working copy)
>> @@ -37,8 +37,13 @@
>>      Never
>>    };
>>
>> +#if 0
>>    int Cost : 30;
>>    unsigned Type :  2;
>> +#else
>> +    int Cost;
>> +    unsigned Type :  2;
>> +#endif
>>
>>    InlineCost(int C, int T) : Cost(C), Type(T) {
>>      assert(Cost == C && "Cost exceeds InlineCost
precision");
>>
>> Basically, you're changing the inline cost variable from 30 to 32  
>> bits.
>> After that, do a RELEASE build of LLVM and retry building llvm-gcc.
>>
>> -- John T.
>>
>
> That worked like a charm. Thanks a lot!
>
> Gautam
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi,
> Glad that works for you, but it means that if the 32-bit cost  
> computation overflows, we won't be told about it.   I think the right  
> thing is to make sure the computation saturates at 30 bits instead of  
> overflowing.  Am I going to talk myself into overloading operator+ ?
is this problem really real?  Or has LLVM been miscompiled?
The two people who have reported this were running very similar
systems with broken compiler versions...

Ciao,

Duncan.