[llvm-bugs] [Bug 24631] New: MI Serialization crashes on empty inlineasm
https://llvm.org/bugs/show_bug.cgi?id=24631
Bug ID: 24631
Summary: MI Serialization crashes on empty inlineasm
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: hfin...@anl.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 14795
--> https://llvm.org/bugs/attachment.cgi?id=14795&action=edit
reduced test case
$ cat mirp.ll
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define void @foo() #0 {
entry:
tail call void asm sideeffect "", "~{memory}"() #0
ret void
}
attributes #0 = { nounwind }
$ llc -stop-after=if-converter < mirp.ll
llc: /src/llvm/lib/IR/AsmWriter.cpp:346: void
llvm::printLLVMNameWithoutPrefix(llvm::raw_ostream&, llvm::StringRef):
Assertion `!Name.empty() && "Cannot get empty name!"' failed.
The problem seems related to how llvm::MIPrinter::print handles external
symbols, specifically:
789 case MachineOperand::MO_ExternalSymbol:
790OS << '$';
791printLLVMNameWithoutPrefix(OS, Op.getSymbolName());
792printOffset(Op.getOffset());
793break;
printLLVMNameWithoutPrefix cannot be called with an empty name string, but it
is in this case because the inline asm string is empty:
INLINEASM [sideeffect] [mayload] [maystore] [attdialect]
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24632] New: 3.7: Many tests are failing on powerpc & s390x
https://llvm.org/bugs/show_bug.cgi?id=24632 Bug ID: 24632 Summary: 3.7: Many tests are failing on powerpc & s390x Product: Projects Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Polly Assignee: polly-...@googlegroups.com Reporter: sylves...@debian.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Issues look similar on the two archs. Testing: FAIL: Polly :: DeadCodeElimination/chained_iterations.ll (1 of 387) TEST 'Polly :: DeadCodeElimination/chained_iterations.ll' FAILED Script: -- opt -S -load /«PKGBUILDDIR»/build-llvm/tools/polly/Release/lib/LLVMPolly.so -polly-detect-unprofitable -basicaa -polly-dependences-analysis-type=value-based -polly-ast -analyze -polly-no-early-exit < /«PKGBUILDDIR»/polly/test/DeadCodeElimination/chained_iterations.ll | FileCheck /«PKGBUILDDIR»/polly/test/DeadCodeElimination/chained_iterations.ll opt -S -load /«PKGBUILDDIR»/build-llvm/tools/polly/Release/lib/LLVMPolly.so -polly-detect-unprofitable -basicaa -polly-dependences-analysis-type=value-based -polly-dce -polly-ast -analyze -polly-no-early-exit < /«PKGBUILDDIR»/polly/test/DeadCodeElimination/chained_iterations.ll | FileCheck /«PKGBUILDDIR»/polly/test/DeadCodeElimination/chained_iterations.ll -check-prefix=CHECK-DCE -- Exit Code: 1 Command Output (stderr): -- /«PKGBUILDDIR»/polly/test/DeadCodeElimination/chained_iterations.ll:52:10: error: expected string not found in input ; CHECK: for (int c0 = 0; c0 <= 199; c0 += 1) ^ :1:1: note: scanning from here Printing analysis 'Basic Alias Analysis (stateless AA impl)': ^ :12:2: note: possible intended match here for (int c0 = 0; c0 <= 854698491904; c0 += 1) ^ Full log: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.7&arch=powerpc&ver=1%3A3.7-1&stamp=1440770855 https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.7&arch=s390x&ver=1%3A3.7-1&stamp=1440787739 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24633] New: MI Serialization - parsing fails for undef load access
https://llvm.org/bugs/show_bug.cgi?id=24633
Bug ID: 24633
Summary: MI Serialization - parsing fails for undef load access
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: hfin...@anl.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat miruv.ll
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
; Function Attrs: nounwind
define i8* @mm_update_next_owner() #0 {
entry:
%0 = load i8*, i8** undef, align 8
ret i8* %0
}
attributes #0 = { nounwind "target-cpu"="pwr7" }
$ llc -o /dev/null -stop-after=if-converter miruv.ll > miruv.mir
$ llc -o - miruv.mir -start-after=if-converter
error: miruv.mir:40:48: expected a constant value
%x3 = LD 0, undef %x3 :: (load 8 from `i8** undef`)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24014] PowerPC inline assembly "&" constraint failure
https://llvm.org/bugs/show_bug.cgi?id=24014 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hal Finkel --- Yet another problem with handling early-clobber operands in the AggressiveAntiDepBreaker. r246423, thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24634] New: [Polly] isl based iteration loop modeling accepts infinite loop
https://llvm.org/bugs/show_bug.cgi?id=24634 Bug ID: 24634 Summary: [Polly] isl based iteration loop modeling accepts infinite loop Product: Projects Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Polly Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14796 --> https://llvm.org/bugs/attachment.cgi?id=14796&action=edit The broken test case Hi, it seems the isl based loop modeling accepts infinite loops. This breaks our code generation as we currently do not expect infinite loops. I propose to not model infinite loops for now. $ polly-opt -polly-codegen -polly-no-early-exit named.ll opt: /home/grosser/Projects/polly/git/tools/polly/lib/CodeGen/IslNodeBuilder.cpp:63: isl_ast_expr *IslNodeBuilder::getUpperBound(isl_ast_node *, ICmpInst::Predicate &): Assertion `isl_ast_expr_get_type(Cond) == isl_ast_expr_op && "conditional expression is not an atomic upper bound"' failed. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24635] New: MultiSource/Benchmarks/PAQ8p times out randomly on AArch64
https://llvm.org/bugs/show_bug.cgi?id=24635 Bug ID: 24635 Summary: MultiSource/Benchmarks/PAQ8p times out randomly on AArch64 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: renato.go...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/118 I'll disable the test on AArch64 until I can understand why it's failing the bot randomly. The extra noise it generates for everyone is not worth the value it gives for AArch64. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24636] New: PowerPC setcc pattern missing
https://llvm.org/bugs/show_bug.cgi?id=24636 Bug ID: 24636 Summary: PowerPC setcc pattern missing Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: an...@samba.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14798 --> https://llvm.org/bugs/attachment.cgi?id=14798&action=edit Testcase csmith hit what looks like another setcc missing pattern: # llc bugpoint-reduced-simplified.ll LLVM ERROR: Cannot select: 0x100061d2a48: i32 = setcc 0x100061ce9a0, 0x100061ce878, 0x100061ceac8 [ORD=2] [ID=15] 0x100061ce9a0: i64,ch = PPCISD::TOC_ENTRY 0x100061cebf0, 0x100061cef68 [ORD=2] [ID=14] 0x100061cebf0: i64 = TargetGlobalAddress 0 [ORD=2] [ID=11] 0x100061cef68: i64 = Register %X2 [ID=10] 0x100061ce878: i64,ch = PPCISD::TOC_ENTRY 0x100061d27f8, 0x100061cef68 [ORD=2] [ID=13] 0x100061d27f8: i64 = TargetGlobalAddress<[1 x i32]* @b> 0 [ORD=2] [ID=9] 0x100061cef68: i64 = Register %X2 [ID=10] In function: fn2 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24638] New: Taking the address of std::string::c_str causes undefined reference
https://llvm.org/bugs/show_bug.cgi?id=24638 Bug ID: 24638 Summary: Taking the address of std::string::c_str causes undefined reference Product: libc++ Version: 3.6 Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: dasca...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified c_str is defined as force-inline, which causes the compiler to not emit it in any translation unit. It is not included in libc++.dylib either. Taking the address causes an undefined symbol to be emitted regardless, but the compiler does not include the implementation. As far as I can tell the compiler should emit the symbol if it is explicitly used, even if it is marked as force-inline. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24638] Taking the address of std::string::c_str causes undefined reference
https://llvm.org/bugs/show_bug.cgi?id=24638 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marshall Clow (home) --- There's a section in the standard ([member.functions]), which basically says "The only thing the standard library guarantees is that if you call the function with that name with those parameters, it will do what the standard says". *** This bug has been marked as a duplicate of bug 24127 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24639] New: Fuzz llvm-as
https://llvm.org/bugs/show_bug.cgi?id=24639 Bug ID: 24639 Summary: Fuzz llvm-as Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kschi...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24640] New: Buffer overflow in method LLLexer::FP80HexToIntPair
https://llvm.org/bugs/show_bug.cgi?id=24640 Bug ID: 24640 Summary: Buffer overflow in method LLLexer::FP80HexToIntPair Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kschi...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14799 --> https://llvm.org/bugs/attachment.cgi?id=14799&action=edit Assembly test file Test case: bug.ll Using llvm-as-fuzzer (built using lib/Fuzzer), the following address sanitizer bug was found: SUMMARY: AddressSanitizer: heap-buffer-overflow /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:110:30 in FP80HexToIntPair ==6507==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61903b06 at pc 0x00510942 bp 0x7ffc97eb6a90 sp 0x7ffc97eb6a88 READ of size 1 at 0x61903b06 thread T0 #0 0x510941 in FP80HexToIntPair /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:110:30 #1 0x510941 in llvm::LLLexer::Lex0x() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:852 #2 0x50bcb6 in llvm::LLLexer::LexDigitOrNegative() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:914:14 #3 0x4fa6e4 in llvm::LLLexer::LexToken() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:232:12 #4 0x4f9fc7 in llvm::LLLexer::LexToken() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:207:12 #5 0x4f9fc7 in llvm::LLLexer::LexToken() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:207:12 #6 0x4f9fc7 in llvm::LLLexer::LexToken() /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.cpp:207:12 #7 0x51d342 in Lex /workspace/llvm-dev/llvm/lib/AsmParser/LLLexer.h:50:24 #8 0x51d342 in llvm::LLParser::ParseNamedGlobal() /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:479 #9 0x510e14 in llvm::LLParser::ParseTopLevelEntities() /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:224:33 #10 0x510a01 in llvm::LLParser::Run() /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:48:10 #11 0x4f1161 in llvm::parseAssemblyInto(llvm::MemoryBufferRef, llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*) /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:31:10 #12 0x4f242b in parseAssembly /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:41:7 #13 0x4f242b in llvm::parseAssemblyFile(llvm::StringRef, llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::SlotMapping*) /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:59 #14 0x4ed9b1 in main /workspace/llvm-dev/llvm/tools/llvm-as/llvm-as.cpp:96:31 #15 0x7f9bb0976ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 #16 0x424f3b in _start (/workspace/llvm-dev/build-as-test/bin/llvm-as+0x424f3b) -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24641] New: adjustments to the autoconf build system when building on Solaris
https://llvm.org/bugs/show_bug.cgi?id=24641 Bug ID: 24641 Summary: adjustments to the autoconf build system when building on Solaris Product: Build scripts Version: 3.6 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: autoconf Assignee: unassignedb...@nondot.org Reporter: stefan.tele...@oracle.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is a placeholder bug for a patch I will be submitting here very shortly. When building with GCC >= 4.8.2 on Solaris (Intel and SPARC), the autoconf-based build system needs some adjustments. These adjustments are not intrusive, and do not affect any other Operating System or ISA. These changes include the use of a special Solaris Linker map file which handles the folding/coalescing of certain specific Extended ELF Sections for binaries compiled with -ffunction-sections -fdata-sections. Without this linker map file, binaries built with -ffunction-sections -fdata-sections will end up with an insane (greater than 125,000) number of Extended ELF Section Headers (SHT_SYMTAB_SHNDX). This linker map file is specific to the Solaris Linker. It is not needed when linking with the GNU BFD or GNU Gold Linkers. We have a number of clang and llvm patches for Solaris, and we have every intention of contributing them to the project. This is just one of several bugs with follow-up patches that I will be filing. ETA for patches: I will start submitting patches - as attachments - this week, within the next couple of days. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24642] New: clang on Solaris needs its own __cxa_atexit and __cxa_finalize functions
https://llvm.org/bugs/show_bug.cgi?id=24642 Bug ID: 24642 Summary: clang on Solaris needs its own __cxa_atexit and __cxa_finalize functions Product: clang Version: 3.6 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: stefan.tele...@oracle.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is a placeholder bug for a patch I will be submitting here very shortly. When building clang/llvm on Solaris with GCC >= 4.8.2, the Solaris Standard C Library does not provide the __cxa_atexit and __cxa_finalize functions, which are part of the Itanium C++ ABI. I have a patch for this defect, and I will provide it here very shortly. The patch consists of source code for __cxa_atexit and __cxa_finalize, and a Makefile. I don't know if this is appropriate for inclusion in the clang/llvm source code tree, but I thought it would be useful to record it here for reference. This bug states that this patch is for clang 3.6, but the patch is valid for any version of clang >= 3.6.0, including the upcoming 3.7.0. We have a number of clang and llvm patches for Solaris, and we have every intention of contributing them to the project. This is just one of several bugs with follow-up patches that I will be filing. ETA for patches: I will start submitting patches - as attachments - this week, within the next couple of days. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24616] [win] lld-link shouldn't depend on env vars to find libraries optionally
https://llvm.org/bugs/show_bug.cgi?id=24616 Reid Kleckner changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Reid Kleckner --- (In reply to comment #3) > No it doesn't. But how can you find a correct search path if no path is > given via the environment variable? What does clang-cl do? INCLUDE doesn't depend on the target architecture, so we're just getting lucky. Nico, personally I feel like if the user has LIB set then we have to trust it. It's what link.exe does. We can do whatever we want when LIB isn't set, though. Clang currently tries to guess which version of VS you want and which Windows SDK you're using if INCLUDE isn't set. The code and the guesses are pretty bad, but we could make it better and share it with LLD. Users have already hit issues with the Windows 10 SDK paths being stale, for example: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089011.html -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24634] [Polly] isl based iteration loop modeling accepts infinite loop
https://llvm.org/bugs/show_bug.cgi?id=24634 Matthew Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matthew Simpson --- Fixed in r246477. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24643] New: FoldingSetNodeID::AddPointer is unnecessarily slow
https://llvm.org/bugs/show_bug.cgi?id=24643 Bug ID: 24643 Summary: FoldingSetNodeID::AddPointer is unnecessarily slow Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: ben.cr...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified FoldingSetNodeID houses the hash and equality material for FoldingSet's intrusive hash map data structure. The raw material is stored as a SmallVector. The current implementation of AddPointer does a ranged append, like so... Bits.append(reinterpret_cast(&Ptr), reinterpret_cast(&Ptr+1)); This is done in order to support 32-bit and 64-bit pointers. Unfortunately, SmallVector::append with 1 element is slower than SmallVector::push_back with 1 element. Append with 2 elements is also slower than two push_backs. On MSVC, the append call eventually turns into a memmove + some bookkeeping. With push_back, it turns into a memcpy + some bookkeeping. When using the Clang static analyzer, AddPointer ends up being one of the top hits for exclusive / self time. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24644] New: Method Verifier::visitAliaseeSubExpr stack overflows
https://llvm.org/bugs/show_bug.cgi?id=24644 Bug ID: 24644 Summary: Method Verifier::visitAliaseeSubExpr stack overflows Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kschi...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14800 --> https://llvm.org/bugs/attachment.cgi?id=14800&action=edit Assembly file See attached for test case (bug1.ll). This bug was found using afl-fuzz. To see error: build llvm-as using the following steps: % cmake -GNinja -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=YES -DCMAKE_BUILD_TYPE=Release /path/to/llvm % ninja bin/llvm-as Then run: bin/llvm-as bug1.ll -o /dev/null The output is: ASAN:DEADLYSIGNAL = ==24746==ERROR: AddressSanitizer: stack-overflow on address 0x7ffef9709fa0 (pc 0x00b0c4e5 bp 0x7ffef970a090 sp 0x7ffef9709fa0 T0) #0 0xb0c4e4 in (anonymous namespace)::Verifier::VerifyConstantExprBitcastType(llvm::ConstantExpr const*) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:1500 #1 0xb48d23 in (anonymous namespace)::Verifier::visitAliaseeSubExpr(llvm::SmallPtrSetImpl&, llvm::GlobalAlias const&, llvm::Constant const&) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:584:5 #2 0xb491df in (anonymous namespace)::Verifier::visitAliaseeSubExpr(llvm::SmallPtrSetImpl&, llvm::GlobalAlias const&, llvm::Constant const&) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:591:7 ... #249 0xb491df in (anonymous namespace)::Verifier::visitAliaseeSubExpr(llvm::SmallPtrSetImpl&, llvm::GlobalAlias const&, llvm::Constant const&) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:591:7 #250 0xb491df in (anonymous namespace)::Verifier::visitAliaseeSubExpr(llvm::SmallPtrSetImpl&, llvm::GlobalAlias const&, llvm::Constant const&) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:591:7 #251 0xb491df in (anonymous namespace)::Verifier::visitAliaseeSubExpr(llvm::SmallPtrSetImpl&, llvm::GlobalAlias const&, llvm::Constant const&) /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:591:7 SUMMARY: AddressSanitizer: stack-overflow /workspace/llvm-dev/llvm/lib/IR/Verifier.cpp:1500 in (anonymous namespace)::Verifier::VerifyConstantExprBitcastType(llvm::ConstantExpr const*) ==24746==ABORTING -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24596] ud2 instruction is generated with LTO
https://llvm.org/bugs/show_bug.cgi?id=24596 Quentin Colombet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Quentin Colombet --- This should be fixed by Committed revision 246502. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24645] New: Segmentation fault in llvm-as inside LLParser::ParseValueAsMetadata
https://llvm.org/bugs/show_bug.cgi?id=24645
Bug ID: 24645
Summary: Segmentation fault in llvm-as inside
LLParser::ParseValueAsMetadata
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: kschi...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When you run:
echo ' !3=!{%..d04 *asm" !6!={!H)4" ,"" ' | llvm-as - -o /dev/null
You get the following:
#0 0x667656 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/workspace/llvm-dev/install/bin/llvm-as+0x667656)
#1 0x66796b PrintStackTraceSignalHandler(void*)
(/workspace/llvm-dev/install/bin/llvm-as+0x66796b)
#2 0x6660e7 llvm::sys::RunSignalHandlers()
(/workspace/llvm-dev/install/bin/llvm-as+0x6660e7)
#3 0x6665be SignalHandler(int)
(/workspace/llvm-dev/install/bin/llvm-as+0x6665be)
#4 0x7fd548e92340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#5 0x415166 llvm::Type::getSubclassData() const
(/workspace/llvm-dev/install/bin/llvm-as+0x415166)
#6 0x41555e llvm::FunctionType::isVarArg() const
(/workspace/llvm-dev/install/bin/llvm-as+0x41555e)
#7 0x5878a4 llvm::InlineAsm::Verify(llvm::FunctionType*, llvm::StringRef)
(/workspace/llvm-dev/install/bin/llvm-as+0x5878a4)
#8 0x4318c2 llvm::LLParser::ConvertValIDToValue(llvm::Type*, llvm::ValID&,
llvm::Value*&, llvm::LLParser::PerFunctionState*)
(/workspace/llvm-dev/install/bin/llvm-as+0x4318c2)
#9 0x43235a llvm::LLParser::ParseValue(llvm::Type*, llvm::Value*&,
llvm::LLParser::PerFunctionState*)
(/workspace/llvm-dev/install/bin/llvm-as+0x43235a)
#10 0x4314eb llvm::LLParser::ParseValueAsMetadata(llvm::Metadata*&, llvm::Twine
const&, llvm::LLParser::PerFunctionState*)
(/workspace/llvm-dev/install/bin/llvm-as+0x4314eb)
#11 0x4315c0 llvm::LLParser::ParseMetadata(llvm::Metadata*&,
llvm::LLParser::PerFunctionState*)
(/workspace/llvm-dev/install/bin/llvm-as+0x4315c0)
#12 0x43b109
llvm::LLParser::ParseMDNodeVector(llvm::SmallVectorImpl&)
(/workspace/llvm-dev/install/bin/llvm-as+0x43b109)
#13 0x427835 llvm::LLParser::ParseMDTuple(llvm::MDNode*&, bool)
(/workspace/llvm-dev/install/bin/llvm-as+0x427835)
#14 0x41ce3e llvm::LLParser::ParseStandaloneMetadata()
(/workspace/llvm-dev/install/bin/llvm-as+0x41ce3e)
#15 0x41b3f6 llvm::LLParser::ParseTopLevelEntities()
(/workspace/llvm-dev/install/bin/llvm-as+0x41b3f6)
#16 0x41a216 llvm::LLParser::Run()
(/workspace/llvm-dev/install/bin/llvm-as+0x41a216)
#17 0x408307 llvm::parseAssemblyInto(llvm::MemoryBufferRef, llvm::Module&,
llvm::SMDiagnostic&, llvm::SlotMapping*)
(/workspace/llvm-dev/install/bin/llvm-as+0x408307)
#18 0x4083f1 llvm::parseAssembly(llvm::MemoryBufferRef, llvm::SMDiagnostic&,
llvm::LLVMContext&, llvm::SlotMapping*)
(/workspace/llvm-dev/install/bin/llvm-as+0x4083f1)
#19 0x40873c llvm::parseAssemblyFile(llvm::StringRef, llvm::SMDiagnostic&,
llvm::LLVMContext&, llvm::SlotMapping*)
(/workspace/llvm-dev/install/bin/llvm-as+0x40873c)
#20 0x4055f6 main (/workspace/llvm-dev/install/bin/llvm-as+0x4055f6)
#21 0x7fd5482beec5 __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:321:0
#22 0x404579 _start (/workspace/llvm-dev/install/bin/llvm-as+0x404579)
Stack dump:
0.Program arguments: llvm-as - -o /dev/null
Segmentation fault
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24646] New: SEGV on unknown address in :InlineAsm::ConstraintInfo::Parse
https://llvm.org/bugs/show_bug.cgi?id=24646 Bug ID: 24646 Summary: SEGV on unknown address in :InlineAsm::ConstraintInfo::Parse Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kschi...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14801 --> https://llvm.org/bugs/attachment.cgi?id=14801&action=edit Test file bug6.ll The test file bug6.ll is attached. This bug was found using afl-fuzz on llvm-as (with address sanitizer included). When you run: llvm-as bug6.ll -o /dev/null You get the following crash: ASAN:DEADLYSIGNAL = ==18076==ERROR: AddressSanitizer: SEGV on unknown address 0x0020 (pc 0x00982713 bp 0x7fffc88b2210 sp 0x7fffc88b1f40 T0) #0 0x982712 in llvm::InlineAsm::ConstraintInfo::Parse(llvm::StringRef, std::vector >&) /workspace/llvm-dev/llvm/lib/IR/InlineAsm.cpp:164:20 #1 0x9851d8 in llvm::InlineAsm::ParseConstraints(llvm::StringRef) /workspace/llvm-dev/llvm/lib/IR/InlineAsm.cpp:220:9 #2 0x98677b in llvm::InlineAsm::Verify(llvm::FunctionType*, llvm::StringRef) /workspace/llvm-dev/llvm/lib/IR/InlineAsm.cpp:247:38 #3 0x57ab06 in llvm::LLParser::ConvertValIDToValue(llvm::Type*, llvm::ValID&, llvm::Value*&, llvm::LLParser::PerFunctionState*, llvm::LLParser::OperatorConstraint) /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:4132:10 #4 0x5c2290 in llvm::LLParser::ParseCall(llvm::Instruction*&, llvm::LLParser::PerFunctionState&, llvm::CallInst::TailCallKind) /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:5592:7 #5 0x5a583d in llvm::LLParser::ParseInstruction(llvm::Instruction*&, llvm::BasicBlock*, llvm::LLParser::PerFunctionState&) /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:4768:35 #6 0x5a27d9 in llvm::LLParser::ParseBasicBlock(llvm::LLParser::PerFunctionState&) /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:4629:13 #7 0x535804 in llvm::LLParser::ParseFunctionBody(llvm::Function&) /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:4577:9 #8 0x5111d9 in ParseDefine /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:411:10 #9 0x5111d9 in llvm::LLParser::ParseTopLevelEntities() /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:217 #10 0x510ba1 in llvm::LLParser::Run() /workspace/llvm-dev/llvm/lib/AsmParser/LLParser.cpp:48:10 #11 0x4f1151 in llvm::parseAssemblyInto(llvm::MemoryBufferRef, llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*) /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:31:10 #12 0x4f241b in parseAssembly /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:41:7 #13 0x4f241b in llvm::parseAssemblyFile(llvm::StringRef, llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::SlotMapping*) /workspace/llvm-dev/llvm/lib/AsmParser/Parser.cpp:59 #14 0x4ed9a1 in main /workspace/llvm-dev/llvm/tools/llvm-as/llvm-as.cpp:96:31 #15 0x7fbf3027eec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 #16 0x424f2b in _start (/workspace/llvm-dev/build-as-test/bin/llvm-as+0x424f2b) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /workspace/llvm-dev/llvm/lib/IR/InlineAsm.cpp:164:20 in llvm::InlineAsm::ConstraintInfo::Parse(llvm::StringRef, std::vector >&) ==18076==ABORTING -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24636] PowerPC setcc pattern missing
https://llvm.org/bugs/show_bug.cgi?id=24636 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hal Finkel --- Not quite a missing pattern, but close (see the commit message for the details). r246507. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24647] New: -fpie has no effect on code generation when doing LTO
https://llvm.org/bugs/show_bug.cgi?id=24647 Bug ID: 24647 Summary: -fpie has no effect on code generation when doing LTO Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ahata...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -fpie enables optimizations that are valid only when it is known that a position independent code is linked into an executable. However, these optimizations are not enabled when doing LTO since that information is not conveyed to the backend. This can possibly be fixed by using module flags or passing -fpie to the driver's command line. It is also possible to have the linker inform the backend via libLTO or gold plugin whether it is linking an executable or a shared library. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24591] elf/linkerscript/filename-with-wildcards.test very flaky on windows
https://llvm.org/bugs/show_bug.cgi?id=24591 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 22898] the codesourcery.com link in cxxabi.h is broken
https://llvm.org/bugs/show_bug.cgi?id=22898 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Fiselier --- The link in cxxabi.h forwards to the correct website now. Closing this bug. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
