non-exiting diagnostic handler for LTO code generator

[Rafael Espíndola via llvm-commits]

LGTM. Thanks!

Hans, this is probably a good candidate for 3.7.1.


On 11 September 2015 at 11:48, Gao, Yunzhong
<yunzhong_gao at playstation.sony.com> wrote:
> Fixed. Thanks.
>
> ________________________________________
> From: Rafael Espíndola [rafael.espindola at gmail.com]
> Sent: Friday, September 11, 2015 5:56 AM
> To: Gao, Yunzhong
> Cc: Duncan P. N. Exon Smith (dexonsmith at apple.com); Peter Collingbourne (peter at pcc.me.uk); llvm-commits at lists.llvm.org
> Subject: Re: non-exiting diagnostic handler for LTO code generator
>
> As you point out llvm-lto is just a testing tool, so this is fine.
>
> Can you avoid the code duplication between the two constructors? The
> lambda uses no local state, so it can be converted to a static global
> function, no?
>
>
>
> On 10 September 2015 at 22:02, Gao, Yunzhong
> <yunzhong_gao at playstation.sony.com> wrote:
>> Hi Rafael,
>>
>> Writing a test with llvm-lto turns out to be slightly more tricky than I thought it would be. llvm-lto does something like:
>>   if (!CodeGen.addModule(Module.get()))
>>     return 1;
>> So with my patch, addModule() will no longer call exit(1) on errors in modules, but when it returns to the main()
>> function of llvm-lto, it silently returns 1, and I cannot distinguish between exit(1) and "return 1" within lit. My
>> current attempt (attached) is to make llvm-lto print an extra message before returning 1, so that lit can FileCheck
>> that. Is this acceptable? I think it does make llvm-lto print excessive diagnostics, but hopefully llvm-lto is used only
>> for testing and therefore it does not matter,
>>
>> - Gao
>>
>>
>> ________________________________________
>> From: Rafael Espíndola [rafael.espindola at gmail.com]
>> Sent: Wednesday, September 09, 2015 5:33 AM
>> To: Gao, Yunzhong
>> Cc: Duncan P. N. Exon Smith (dexonsmith at apple.com); Peter Collingbourne (peter at pcc.me.uk); llvm-commits at lists.llvm.org
>> Subject: Re: non-exiting diagnostic handler for LTO code generator
>>
>> I think the included patch is correct. You should be able to write a
>> test for it with llvm-lto, no?
>>
>