llvm dev - Jan 2015 - [LLVMdev] GCMetadataPrinter::finishAssembly called twice

Hello Philip,

it seems like r226311 [1] introduced a bug which causes finishAssembly() 
to be called multiple times, even if there is only one strategy.  For 
each function, GCModuleInfo::getFunctionInfo() adds the strategy to the 
StrategyList instance variable.  AsmPrinter::doFinalization() calls 
finishAssembly() for each strategy in this list.

-Manuel

[1] http://reviews.llvm.org/rL226311

On 01/25/2015 03:42 AM, Manuel Jacob wrote:
> Hello Philip,
>
> it seems like r226311 [1] introduced a bug which causes 
> finishAssembly() to be called multiple times, even if there is only 
> one strategy.  For each function, GCModuleInfo::getFunctionInfo() adds 
> the strategy to the StrategyList instance variable.  
> AsmPrinter::doFinalization() calls finishAssembly() for each strategy 
> in this list.
>
> -Manuel
>
> [1] http://reviews.llvm.org/rL226311
You're absolutely right.  That's a bug.  Odd that none of the unit tests
caught that.

I'm actually going to end up reverting most of that change for a 
different reason.  I've already got the change ready to commit and plan 
on doing it first thing in the morning.  I'll try to make sure I fix 
this issue in that change as well.

Sorry for the breakage and thanks for the bug report.

Philip

This should be resolved in 227109.

Philip

On 01/25/2015 09:43 PM, Philip Reames wrote:
> On 01/25/2015 03:42 AM, Manuel Jacob wrote:
>> Hello Philip,
>>
>> it seems like r226311 [1] introduced a bug which causes 
>> finishAssembly() to be called multiple times, even if there is only 
>> one strategy.  For each function, GCModuleInfo::getFunctionInfo() 
>> adds the strategy to the StrategyList instance variable.  
>> AsmPrinter::doFinalization() calls finishAssembly() for each strategy 
>> in this list.
>>
>> -Manuel
>>
>> [1] http://reviews.llvm.org/rL226311
> You're absolutely right.  That's a bug.  Odd that none of the unit 
> tests caught that.
>
> I'm actually going to end up reverting most of that change for a 
> different reason.  I've already got the change ready to commit and 
> plan on doing it first thing in the morning.  I'll try to make sure I 
> fix this issue in that change as well.
>
> Sorry for the breakage and thanks for the bug report.
>
> Philip
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev