HI,
When compiling the open-source software cryptopp
(https://www.cryptopp.com/#download <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_traitsIcEEEERNS_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: O0.ll
Type: application/octet-stream
Size: 12036 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: O2.ll
Type: application/octet-stream
Size: 1728 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0002.html>
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_ > traitsIcEEEERNS_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/20161011/fb03f6a5/attachment.html>
Hi Reid, You can find the preprocess source here: https://reviews.llvm.org/P7928 <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 <mailto:llvm-dev at lists.llvm.org>>wrote: > HI, > > When compiling the open-source software cryptopp (https://www.cryptopp.com/#download <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_traitsIcEEEERNS_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 <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/e2683cdd/attachment.html>
Apparently Analagous Threads
- Clang 5, UBsan, runtime error: addition of unsigned offset to X overflowed to Y
- Determine reason for failure at -O1
- Restrict global constructors to base ISA
- Problem building powerdns from EPEL
- llvm build failed while Linking CXX shared library ../../../lib/libc++.so