lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

Toon Moene toon@moene.org
Sat May 15 09:47:00 GMT 2010


On 05/14/2010 03:40 PM, Richard Guenther wrote:

> On Fri, May 14, 2010 at 3:34 PM, Toon Moene<toon@moene.org>  wrote:

>> On 04/25/2010 01:24 PM, Toon Moene wrote:
>>
>>> Richard Guenther wrote:
>>
>> [ Concerning this assert ]
>>
>>>> It is checking that for one symbol we only have one definition.
>>>>
>>>> You are using -fuse-linker-plugin?
>>>
>>> Indeed, I do (all of our code ends up in libraries - .a files - so I
>>> have to, to make -flto -fwhole-program be meaningful).
>>>
>>> Is it a problem with COMMON ? Those typically have umpteen definitions,
>>> which all have to match ...
>>
>> I decided to change the following in lto-symtab.c to help me pinpoint this
>> culprit:
>>
>> Index: lto-symtab.c
>> ===================================================================
>> --- lto-symtab.c        (revision 159389)
>> +++ lto-symtab.c        (working copy)
>> @@ -603,8 +603,15 @@
>>    /* Assert it's the only one.  */
>>    if (prevailing)
>>      for (e = prevailing->next; e; e = e->next)
>> -      gcc_assert (e->resolution != LDPR_PREVAILING_DEF_IRONLY
>> -&&  e->resolution != LDPR_PREVAILING_DEF);
>> +      {
>> +      if (!(e->resolution != LDPR_PREVAILING_DEF_IRONLY
>> +&&  e->resolution != LDPR_PREVAILING_DEF))
>> +        {
>> +         debug_tree(prevailing->decl);
>> +         debug_tree(e->decl);
>> +         gcc_assert(0);
>> +        }
>> +      }
>>
>>    /* If there's not a prevailing symbol yet it's an external reference.
>>       Happens a lot during ltrans.  Choose the first symbol with a
>>
>> That resulted in the following messages in my compile log:
>>
>>   <function_decl 0x2b9d3a4af900 convect_satmixratio
>>     type<function_type 0x2b9d3a471000
>>         type<void_type 0x2b9d3548dd20 VOID
>>             align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
>>             pointer_to_this<pointer_type 0x2b9d3548ddc8>>
>>         QI
>>         size<integer_cst 0x2b9d3547e758 constant 8>
>>         unit size<integer_cst 0x2b9d3547e780 constant 1>
>>         align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000>
>>     public external QI file bkfconv.f90 line 7712 col 0 align 8>
>>   <function_decl 0x2b9d3a4af200 convect_satmixratio
>>     type<function_type 0x2b9d3a471000
>>         type<void_type 0x2b9d3548dd20 VOID
>>             align 8 symtab 0 alias set -1 canonical type 0x2b9d3548dd20
>>             pointer_to_this<pointer_type 0x2b9d3548ddc8>>
>>         QI
>>         size<integer_cst 0x2b9d3547e758 constant 8>
>>         unit size<integer_cst 0x2b9d3547e780 constant 1>
>>         align 8 symtab 0 alias set -1 canonical type 0x2b9d3a471000>
>>     public external QI file bkfconv.f90 line 6525 col 0 align 8>
>> lto1: internal compiler error: in lto_symtab_merge_decls_1, at
>> lto-symtab.c:612
>>
>> bkconv.f90:7712:
>>
>>    7711 !
>>    7712        CALL CONVECT_SATMIXRATIO( KLON, ZWORK1, ZTELCL, ZWORK3, ZLV,
>> ZLS, ZCPH )
>>
>> bkfconv.f90:6525:
>>    6524 !
>>    6525      CALL CONVECT_SATMIXRATIO( KLON, ZPLCL, ZTLCL, ZWORK1, ZLV,
>> ZWORK2, ZCPH )
>>
>> The only thing I can see is that CONVECT_SATMIXRATIO is called from two
>> different routines in one file (bkfconv.f90:6260 CONVECT_TRIGGER_SHAL and
>> bkfconv.f90:7258 CONVECT_CLOSURE_SHAL)
>>
>> Any suggestions how I can further chase this down ?  Are the arguments to
>> the subroutine an issue (kind, array size, etc.) ?
>
> No, the lto-plugin or gold provides you with broken symbol resolution.
>
> Try 1) update gold, 2) file a bugreport and CC Ian and Cary.

The gold is relatively new (5/6/10), so I did 2 - it's PR lto/44149.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran



More information about the Gcc mailing list