[llvm-dev] Landing Pad bug?

[Reid Kleckner via llvm-dev]

I wasn't able to reproduce the issue with a recent clang. If you want to
debug this further, I would recommend emailing llvm-admin to get a bugzilla
account and we can discuss further off list.

I compiled the pre-processed source code like this, after commenting out
some xmmintrin.h prototypes that were recently promoted to builtins:
$ clang -cc1 -fblocks -fexceptions -fcxx-exceptions -triple x86_64-macosx
-O2 integer.cpp -S -emit-llvm -o t.ll

The resulting IR had the landingpads in the right place.

If you can send along the -cc1 command line used to generate the invalid
LLVM IR and the clang version used, that would be helpful. You can get the
-cc1 line by running the normal compilation command and adding -###.


On Wed, Oct 12, 2016 at 6:00 AM, Johan Wehrli <johan.wehrli at strong.codes>
wrote:

> Hi Reid,
>
> You can find the preprocess source here: https://reviews.llvm.org/P7928
>
> This is the compile line used: llvm3.9/bin/clang++ -O2 integer.cpp -E &>
> preprocess.txt
>
> Greetings,
>
> Johan
>
>
> On 11 Oct 2016, at 18:02, Reid Kleckner <rnk at google.com> wrote:
>
> That's an interesting bug. Can you post the pre-processed source code
> somewhere? I can't optimize the O0.ll file because it only contains the
> function, and none of the struct types.
>
> Usually pre-processed source is large, so I wouldn't recommend mailing it
> to the list. I'd suggest our bugzilla, but you can't create new accounts
> right now without mailing llvm-admin.
>
> On Mon, Oct 10, 2016 at 11:30 PM, Johan Wehrli via llvm-dev <
> llvm-dev at lists.llvm.org>wrote:
>
>> HI,
>>
>> When compiling the open-source software cryptopp (
>> https://www.cryptopp.com/#download) version 5.6.4 I found a strange
>> issue with the IR generated.
>>
>> The issue only appears when compiling with -O2 optimisation in the
>> integer.cpp file (the function is _ZN8CryptoPPrsERNSt3__113basic
>> _istreamIcNS0_11char_traitsIcEEEERNS_7IntegerE ->
>> CryptoPP::operator>>(std::__1::basic_istream<char,
>> std::__1::char_traits<char> >&, CryptoPP::Integer&)).
>>
>> The verifier give me these errors:
>>
>> *EH pad cannot be in entry block. %4 = landingpad*
>> *{ i8*, i32 } cleanupLandingPadInst not the first non-PHI instruction in
>> the block. %4 = landingpad { i8*, i32 } cleanup*
>>
>> If I remove the verifier, I am able to compile the whole library and run
>> the test suite without any issue.
>>
>> When you look at the whole IR code for the function:
>>
>> ----------------------
>>
>> ; Function Attrs: ssp uwtable
>> define nonnull dereferenceable(168) %"class.std::__1::basic_istream"*
>> @_ZN8CryptoPPrsERNSt3__113basic_istreamIcNS0_11char_traitsIc
>> EEEERNS_7IntegerE(%"class.std::__1::basic_istream"*
>> dereferenceable(168), %"class.CryptoPP::Integer"* dereferenceable(40))
>> local_unnamed_addr #0 personality i8* bitcast (i32 (...)*
>> @__gxx_personality_v0 to i8*) {
>>   %3 = tail call i8* @_ZN8CryptoPP17UnalignedAllocateEm(i64 16)
>>   %4 = landingpad { i8*, i32 }
>>           cleanup
>>   %5 = icmp eq i8* %3, null
>>   br i1 %5, label %6, label %8, !prof !22
>>
>> ; <label>:6:                                      ; preds = %2
>>   invoke void @__assert_rtn(i8* getelementptr inbounds ([11 x i8], [11 x
>> i8]* @__func__._ZN8CryptoPP20AllocatorWithCleanupIhLb0EE10deallocateEPvm,
>> i64 0, i64 0), i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str.64,
>> i64 0, i64 0), i32 197, i8* getelementptr inbounds ([32 x i8], [32 x i8]*
>> @.str.75, i64 0, i64 0)) #58
>>           to label %7 unwind label %10
>>
>> ; <label>:7:                                      ; preds = %6
>>   unreachable
>>
>> ; <label>:8:                                      ; preds = %2
>>   %9 = tail call { i64, i8* } asm sideeffect "rep stosb",
>> "={cx},={di},{ax},0,1,~{memory},~{dirflag},~{fpsr},~{flags}"(i32 0, i64
>> 16, i8* nonnull %3) #53, !srcloc !1070
>>   invoke void @_ZN8CryptoPP19UnalignedDeallocateEPv(i8* nonnull %3)
>>           to label %13 unwind label %10
>>
>> ; <label>:10:                                     ; preds = %8, %6
>>   %11 = landingpad { i8*, i32 }
>>           catch i8* null
>>   %12 = extractvalue { i8*, i32 } %11, 0
>>   tail call void @__clang_call_terminate(i8* %12) #59
>>   unreachable
>>
>> ; <label>:13:                                     ; preds = %8
>>   resume { i8*, i32 } %4
>> }
>>
>> ----------------------
>>
>> I was not able to understand which optimisation transforms the code like
>> this.
>>
>> I have attached the IR code from the function in O0 and O2.
>>
>> Greetings,
>>
>> Johan
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/b1b6cc72/attachment.html>