[llvm-bugs] [Bug 28794] error: definition of 'S' must be imported from module 'XXX' before it is required
https://llvm.org/bugs/show_bug.cgi?id=28794 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Vassil Vassilev --- Fixed in r279164. -- 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 28967] No relocation emitted for hidden visibility using lld -r
https://llvm.org/bugs/show_bug.cgi?id=28967 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r279220 -- 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 29051] New: Himeno performance regression since r243460
https://llvm.org/bugs/show_bug.cgi?id=29051 Bug ID: 29051 Summary: Himeno performance regression since r243460 Product: libraries Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lukebe...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Himeno Benchmark v 3.0 performance decreases by ~13% after r243460. Steps to reproduce: $ export CC=clang $ export CFLAGS="-O3 -march=native" $ phoronix-test-suite run pts/himeno Or you should be able to use the llvm test suite version: https://llvm.org/svn/llvm-project/test-suite/trunk/SingleSource/Benchmarks/Misc/himenobmtxpa.c On my system, gcc 5.4 : 1122.2 clang 243459: 946.7 clang 243460: 840.6 I bisected the regression down to this commit: http://llvm.org/viewvc/llvm-project?view=revision&revision=243460 -- 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 29041] Incorrect conversion from float to char to int
https://llvm.org/bugs/show_bug.cgi?id=29041 James Molloy changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from James Molloy --- This is slightly more involved; I'm going to resolve this as FIXED but actually your testcase has undefined behaviour. Your case converts a float directly to an unsigned char, which has undefined behaviour on overflow. It is therefore correct to assume the result of the FP-to-UI conversion leaves the uppermost 24 bits zeroed. Now, we were doing a faulty transform where we converted the FP-to-UINT into a FP-to-SINT and then not informing the rest of the optimizer that the resulting int was sign extended not zero extended. This resulted in: fcvtzs w0, s0 ret Fixing this bug causes the expected output: fcvtzs w0, s0 and w0, w0, #0xff ret However, we're only doing that mask because we've decided to create a signed conversion. If we undo that dodgy heuristic, we produce an unsigned conversion: fcvtzu w0, s0 ret // Note no mask! We don't need to mask because conversion from float->uint8_t is undefined if the integer part of the float value is not representable in uint8_t. Therefore we can assume this doesn't happen! If you want the explicit mask (perhaps because you want to handle out of range inputs by truncating mod 256), you should make the conversion convert from float to uint32_t then truncate that: unsigned char charVal = (unsigned char)(unsigned int)infloatVal; This then produces: fcvtzu w0, s0 and w0, w0, #0xff ret (Note, the above is with the dodgy heuristic fixed which isn't in trunk. So you will just see the signed conversion and the mask as above which *does work* for your case but only because the compiler is doing something stupid and shouldn't be relied upon). Cheers, James Codegen fix in r279223. -- 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 29052] New: 'ran out of registers' error when selecting mips32r6 as target.
https://llvm.org/bugs/show_bug.cgi?id=29052 Bug ID: 29052 Summary: 'ran out of registers' error when selecting mips32r6 as target. Product: clang Version: trunk Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: mik...@pixelcarbide.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16995 --> https://llvm.org/bugs/attachment.cgi?id=16995&action=edit self-contained test case. LLVM: Revision 279223 Clang: Revision 279207 When compiling the attached source with the following options, I get the error "ran out of registers during register allocation". clang --std=c++14 -target mipsel -EL -mips32r6 -ffreestanding -c stdio.cpp I can eliminate the error by removing -mips32r6 -- 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 29053] New: HowToUseJIT fails with 'Target does not support MC emission!'
https://llvm.org/bugs/show_bug.cgi?id=29053
Bug ID: 29053
Summary: HowToUseJIT fails with 'Target does not support MC
emission!'
Product: libraries
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: MCJIT
Assignee: unassignedb...@nondot.org
Reporter: l...@henning-thielemann.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
llvm-3.8.1.build$ bin/HowToUseJIT
We just constructed this LLVM module:
; ModuleID = 'test'
define i32 @add1(i32 %AnArg) {
EntryBlock:
%0 = add i32 1, %AnArg
ret i32 %0
}
define i32 @foo() {
EntryBlock:
%0 = tail call i32 @add1(i32 10)
ret i32 %0
}
Running foo: LLVM ERROR: Target does not support MC emission!
--
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 29054] New: clang api gets confused by positional arguments
https://llvm.org/bugs/show_bug.cgi?id=29054 Bug ID: 29054 Summary: clang api gets confused by positional arguments Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: moritz.kie...@purelyfunctional.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Steps to reproduce: Download and compile https://gist.github.com/cocreature/5b511b3de6f2e2e2e08e48ec3ce25dcc and try to run it with a single argument. That file identical to the clang-interpreter example with the exception of one (unused) positional argument added via llvm::cl (and some debug output). Then try to run it and pass an arbitrary C file as the single argument. Expected: It compiles to an LLVM module and then tries to interpret it. Actual behavior: The call to CompilerInstance::ExecuteAction fails with the following error message: clang: Not enough positional command line arguments specified! Must specify at least 1 positional arguments: See: clang -help Comments: Adding an unused argument is obviously not useful but I am encountering this bug in a tool of mine where we actually use positional arguments so just removing them is not an option (or would require us to switch to a different cli arg parser). This is new behavior in 3.9 (3.8 works fine). I assume it is not intended, but if so, is there a way around this? -- 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 29055] New: Improve diagnostic for assigning a type to a variable.
https://llvm.org/bugs/show_bug.cgi?id=29055
Bug ID: 29055
Summary: Improve diagnostic for assigning a type to a variable.
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This:
struct A {};
auto a = decltype(A{});
produces this error:
4 : error: expected '(' for function-style cast or type construction
auto a = decltype(A{});
~^
Either the user meant something like:
auto a = decltype(A{}){};
or it meant "using" instead of "auto":
using a = decltype(A{});
While the current error message is technically correct, it should be more user
friendly. It would be better if it would suggest both options in a note.
--
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 27500] [MSP430] codegen: strange branch instructions
https://llvm.org/bugs/show_bug.cgi?id=27500 Anton Korobeynikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Anton Korobeynikov --- Fixed with r279242 -- 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 29056] New: Assertion Failure
https://llvm.org/bugs/show_bug.cgi?id=29056 Bug ID: 29056 Summary: Assertion Failure Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: TableGen Assignee: unassignedb...@nondot.org Reporter: bobby.pr...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified clang-4.0: /home/pranith/devops/code/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3166: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc&, llvm::EVT, llvm::SDValue): Assertion `VT.getSi zeInBits() == Operand.getValueType().getSizeInBits() && "Cannot BITCAST between types of different sizes!"' failed. #0 0x01be5408 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/clang-4.0+0x1be5408) #1 0x01be2ffe llvm::sys::RunSignalHandlers() (/usr/local/bin/clang-4.0+0x1be2ffe) #2 0x01be3164 SignalHandler(int) (/usr/local/bin/clang-4.0+0x1be3164) #3 0x7fd71bd953d0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x113d0) #4 0x7fd71ab02418 gsignal /build/glibc-GKVZIf/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0 #5 0x7fd71ab0401a abort /build/glibc-GKVZIf/glibc-2.23/stdlib/abort.c:91:0 #6 0x7fd71aafabd7 __assert_fail_base /build/glibc-GKVZIf/glibc-2.23/assert/assert.c:92:0 #7 0x7fd71aafac82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #8 0x022afa09 llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc const&, llvm::EVT, llvm::SDValue) (/usr/local/bin/clang-4.0+0x22afa09) #9 0x02258acd getCopyToParts(llvm::SelectionDAG&, llvm::SDLoc const&, llvm::SDValue, llvm::SDValue*, unsigned int, llvm::MVT, llvm::Value const*, llvm::ISD::NodeType) (/usr/local/bin/clang-4.0+0x2258acd) #10 0x02258f93 llvm::RegsForValue::getCopyToRegs(llvm::SDValue, llvm::SelectionDAG&, llvm::SDLoc const&, llvm::SDValue&, llvm::SDValue*, llvm::Value const*, llvm::ISD::NodeType) const (/usr/local/bin/clan g-4.0+0x2258f93) #11 0x0227e748 llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite) (/usr/local/bin/clang-4.0+0x227e748) #12 0x0228a081 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) (/usr/local/bin/clang-4.0+0x228a081) #13 0x0228ffa9 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (/usr/local/bin/clang-4.0+0x228ffa9) #14 0x022caa08 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) (/usr/local/bin/clang-4.0+0x22caa08) #15 0x022d2f5f llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/bin/clang-4.0+0x22d2f5f) #16 0x022d52c8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/bin/clang-4.0+0x22d52c8) #17 0x011aacf4 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/bin/clang-4.0+0x11aacf4) #18 0x01558205 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/bin/clang-4.0+0x1558205) #19 0x01810103 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/bin/clang-4.0+0x1810103) #20 0x018101bb llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/bin/clang-4.0+0x18101bb) #21 0x01810861 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/bin/clang-4.0+0x1810861) #22 0x01d5b355 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::Back endAction, std::unique_ptr >) (/usr/local/bin/clang-4.0+0x1d5b355) #23 0x0238a2b9 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/bin/clang-4.0+0x238a2b9) #24 0x026bf28a clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/bin/clang-4.0+0x26bf28a) #25 0x0238aa29 clang::CodeGenAction::ExecuteAction() (/usr/local/bin/clang-4.0+0x238aa29) #26 0x02093116 clang::FrontendAction::Execute() (/usr/local/bin/clang-4.0+0x2093116) #27 0x02066406 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/bin/clang-4.0+0x2066406) #28 0x0211d10c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/bin/clang-4.0+0x211d10c) #29 0x0095d028 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/bin/clang-4.0+0x95d028) #30 0x008f8cdd main (/usr/local/bin/clang-4.0+0x8f8cdd) #31 0x7fd71aaed830 __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:325:0 #32 0x009597b9 _start (/usr/local/bin/clang-4.0+0x9597b9) Stack dump: 0. Program arguments: /usr/local/bin/clang-4.0 -cc1 -triple i386-unknown-linux-gnu -emit-obj -disable-free -main-file-name test-i386.c -mrelocation-model static -mthread-model posix -relaxed-aliasing -fmath- errno -masm-verbose -mconstruct
[llvm-bugs] [Bug 28168] [mc][gfx7] v_mqsad_pk_u16_u8 -- implement
https://llvm.org/bugs/show_bug.cgi?id=28168 Artem Tamazov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Artem Tamazov --- Not reproducible at r279231. Probably fixed by > r279126 | 443f72b | wei.ding2 | 2016-08-18 22:51:14 +0300 > AMDGPU : Fix QSAD and MQSAD instructions' incorrect data type. -- 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 29057] New: GVN PRE not respecting the "inbounds" keyword of GEP
https://llvm.org/bugs/show_bug.cgi?id=29057
Bug ID: 29057
Summary: GVN PRE not respecting the "inbounds" keyword of GEP
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: youngju.s...@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Related with: https://llvm.org/bugs/show_bug.cgi?id=28562
As stated, GVN ignores the "inbounds" keyword of GEP during numbering.
And it actually performs PRE on GEP regardless of "inbounds" keyword.
Below is the actual code transformation. (Using 'opt -gvn')
source:
define i32* @foo(i32* %a, i1 %cond) {
entry:
br i1 %cond, label %brA, label %brB
brA:
%xA = getelementptr inbounds i32, i32* %a, i32 10
br label %out
brB:
%xB = getelementptr inbounds i32, i32* %a, i32 10
br label %out
out:
%x = getelementptr i32, i32* %a, i32 10
ret i32* %x
}
target:
define i32* @foo(i32* %a, i1 %cond) {
entry:
br i1 %cond, label %brA, label %brB
brA: ; preds = %entry
%xA = getelementptr inbounds i32, i32* %a, i32 10
br label %out
brB: ; preds = %entry
%xB = getelementptr inbounds i32, i32* %a, i32 10
br label %out
out: ; preds = %brB, %brA
%x.pre-phi = phi i32* [ %xB, %brB ], [ %xA, %brA ]
ret i32* %x.pre-phi
}
This may be problematic because GEP with "inbounds" keyword may produce poison
value while normal one does not, and poison value may produce UB. More behavior
in target code is problematic.
One possible solution may to use "patchAndReplaceAllUsesWith" instead of naive
"replaceAllUsesWith" in "performScalarPRE".
--
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 28908] error: ran out of registers during register allocation
https://llvm.org/bugs/show_bug.cgi?id=28908 Simon Dardis changed: What|Removed |Added CC||simon.dar...@imgtec.com Resolution|WORKSFORME |DUPLICATE --- Comment #5 from Simon Dardis --- *** This bug has been marked as a duplicate of bug 29052 *** -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 28976, which changed state. Bug 28976 Summary: Corrupted section contents when using linker scripts https://llvm.org/bugs/show_bug.cgi?id=28976 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 28976] Corrupted section contents when using linker scripts
https://llvm.org/bugs/show_bug.cgi?id=28976 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from George Rimar --- Fixed in 279264 -- 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 15732] [META] CMake build equivalent to the autotools build
https://llvm.org/bugs/show_bug.cgi?id=15732 Bug 15732 depends on bug 28855, which changed state. Bug 28855 Summary: clang 3.8.1 fails to link i386 macOS due to eprintf.c.o incorrectly being included in libclang_rt.osx.a https://llvm.org/bugs/show_bug.cgi?id=28855 What|Removed |Added Status|REOPENED|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 28855] clang 3.8.1 fails to link i386 macOS due to eprintf.c.o incorrectly being included in libclang_rt.osx.a
https://llvm.org/bugs/show_bug.cgi?id=28855 Chris Bieneman changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Chris Bieneman --- Jeremy, the fix makes clang not link the eprintf library. Removing it from the build is not essential because it is just an unused file, so that change will be in 4.0. This change does resolve the bug that was reported (being unable to link i386 code). Removing eprintf from the x86_64 slice is not strictly required for correctness, and can be tracked in a separate bug which does not justify escalation to 3.9. This bug is resolved, please don't abuse our bug tracker by re-opening bugs when the resolution is not your intended solution. If the problem reported is fixed, the bug is fixed. If there are further changes you want to see, please file new bugs. -- 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 15732] [META] CMake build equivalent to the autotools build
https://llvm.org/bugs/show_bug.cgi?id=15732 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Chris Bieneman --- The Autoconf build system has been removed from tree. I think we can call this fixed in as much as it will be fixed. Future bugs in CMake should not be tracked as attached to this. -- 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 16120] Move Buildbots to CMake
https://llvm.org/bugs/show_bug.cgi?id=16120 Bug 16120 depends on bug 15732, which changed state. Bug 15732 Summary: [META] CMake build equivalent to the autotools build https://llvm.org/bugs/show_bug.cgi?id=15732 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 15732] [META] CMake build equivalent to the autotools build
https://llvm.org/bugs/show_bug.cgi?id=15732 Bug 15732 depends on bug 25753, which changed state. Bug 25753 Summary: compiler-rt is built with the wrong toolchain (bootstrap compiler rather than built clang), linking fails when using clang older than 3.5 (eg: Mavericks and earlier Xcodes) https://llvm.org/bugs/show_bug.cgi?id=25753 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 25753] compiler-rt is built with the wrong toolchain (bootstrap compiler rather than built clang), linking fails when using clang older than 3.5 (eg: Mavericks and earlier Xcodes)
https://llvm.org/bugs/show_bug.cgi?id=25753 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Chris Bieneman --- There are two solutions for this. Either pass LLVM_BUILD_EXTERNAL_COMPILER_RT=On to CMake, or on trunk you can put compiler-rt in the LLVM runtimes subdirectory. -- 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 15732] [META] CMake build equivalent to the autotools build
https://llvm.org/bugs/show_bug.cgi?id=15732 Bug 15732 depends on bug 25059, which changed state. Bug 25059 Summary: CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig https://llvm.org/bugs/show_bug.cgi?id=25059 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 25059] CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig
https://llvm.org/bugs/show_bug.cgi?id=25059 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Chris Bieneman --- This should have been fixed in r252093 -- 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 29058] New: Assert in llvm::SelectionDAG::Legalize()
https://llvm.org/bugs/show_bug.cgi?id=29058 Bug ID: 29058 Summary: Assert in llvm::SelectionDAG::Legalize() Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: babo...@gmail.com CC: llvm-bugs@lists.llvm.org, vsevolod.livins...@frtk.ru Classification: Unclassified Created attachment 17004 --> https://llvm.org/bugs/attachment.cgi?id=17004&action=edit reproducer Fresh trunk fails with an assert in llvm::SelectionDAG::Legalize() The source contains several warnings, but this is all legal C++. > clang --version clang version 4.0.0 (trunk 279250) Target: x86_64-unknown-linux-gnu Thread model: posix > clang++ -c pr.cpp -O2 -w clang-4.0: /export/users/dybaboki/llvm/llvm-trunk/include/llvm/CodeGen/SelectionDAGNodes.h:666: const llvm::SDValue &llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. #0 0x01143335 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1143335) #1 0x01143a06 SignalHandler(int) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1143a06) #2 0x7f1b7df61100 __restore_rt (/lib64/libpthread.so.0+0xf100) #3 0x7f1b7cb595f7 __GI_raise (/lib64/libc.so.6+0x355f7) #4 0x7f1b7cb5ace8 __GI_abort (/lib64/libc.so.6+0x36ce8) #5 0x7f1b7cb52566 __assert_fail_base (/lib64/libc.so.6+0x2e566) #6 0x7f1b7cb52612 (/lib64/libc.so.6+0x2e612) #7 0x01823076 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1823076) #8 0x018209c6 llvm::SelectionDAG::Legalize() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18209c6) #9 0x018d1039 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18d1039) #10 0x018cfc41 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18cfc41) #11 0x018cb5cd llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18cb5cd) #12 0x00782271 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x782271) #13 0x00ab36e6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xab36e6) #14 0x00d5e84f llvm::FPPassManager::runOnFunction(llvm::Function&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5e84f) #15 0x00d5ea9b llvm::FPPassManager::runOnModule(llvm::Module&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5ea9b) #16 0x00d5ef85 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5ef85) #17 0x012c4204 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x12c4204) #18 0x01999bfc clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1999bfc) #19 0x01da2c66 clang::ParseAST(clang::Sema&, bool, bool) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1da2c66) #20 0x01682635 clang::FrontendAction::Execute() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1682635) #21 0x0164b1e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x164b1e1) #22 0x0171653a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x171653a) #23 0x006d63a3 cc1_main(llvm::ArrayRef, char const*, void*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d63a3) #24 0x006d48b9 main (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d48b9) #25 0x7f1b7cb45b15 __libc_start_main (/lib64/libc.so.6+0x21b15) #26 0x006d1dc5 _start (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d1dc5) -- 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 29059] New: Assert in llvm::SelectionDAG::Legalize()
https://llvm.org/bugs/show_bug.cgi?id=29059 Bug ID: 29059 Summary: Assert in llvm::SelectionDAG::Legalize() Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: babo...@gmail.com CC: llvm-bugs@lists.llvm.org, vsevolod.livins...@frtk.ru Classification: Unclassified Created attachment 17005 --> https://llvm.org/bugs/attachment.cgi?id=17005&action=edit reproducer Fresh trunk fails with an assert in llvm::SelectionDAG::Legalize() The source contains several warnings, but this is all legal C++. > clang --version clang version 4.0.0 (trunk 279250) Target: x86_64-unknown-linux-gnu Thread model: posix > clang++ -c pr.cpp -O2 -w clang-4.0: /export/users/dybaboki/llvm/llvm-trunk/include/llvm/CodeGen/SelectionDAGNodes.h:666: const llvm::SDValue &llvm::SDNode::getOperand(unsigned int) const: Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed. #0 0x01143335 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1143335) #1 0x01143a06 SignalHandler(int) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1143a06) #2 0x7f1b7df61100 __restore_rt (/lib64/libpthread.so.0+0xf100) #3 0x7f1b7cb595f7 __GI_raise (/lib64/libc.so.6+0x355f7) #4 0x7f1b7cb5ace8 __GI_abort (/lib64/libc.so.6+0x36ce8) #5 0x7f1b7cb52566 __assert_fail_base (/lib64/libc.so.6+0x2e566) #6 0x7f1b7cb52612 (/lib64/libc.so.6+0x2e612) #7 0x01823076 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1823076) #8 0x018209c6 llvm::SelectionDAG::Legalize() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18209c6) #9 0x018d1039 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18d1039) #10 0x018cfc41 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18cfc41) #11 0x018cb5cd llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x18cb5cd) #12 0x00782271 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x782271) #13 0x00ab36e6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xab36e6) #14 0x00d5e84f llvm::FPPassManager::runOnFunction(llvm::Function&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5e84f) #15 0x00d5ea9b llvm::FPPassManager::runOnModule(llvm::Module&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5ea9b) #16 0x00d5ef85 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0xd5ef85) #17 0x012c4204 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x12c4204) #18 0x01999bfc clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1999bfc) #19 0x01da2c66 clang::ParseAST(clang::Sema&, bool, bool) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1da2c66) #20 0x01682635 clang::FrontendAction::Execute() (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x1682635) #21 0x0164b1e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x164b1e1) #22 0x0171653a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x171653a) #23 0x006d63a3 cc1_main(llvm::ArrayRef, char const*, void*) (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d63a3) #24 0x006d48b9 main (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d48b9) #25 0x7f1b7cb45b15 __libc_start_main (/lib64/libc.so.6+0x21b15) #26 0x006d1dc5 _start (/export/users/dybaboki/llvm/bin-trunk/bin/clang-4.0+0x6d1dc5) -- 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 9739] Please change the license of cmake/modules/LLVMParseArguments.cmake
https://llvm.org/bugs/show_bug.cgi?id=9739 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #1 from Chris Bieneman --- This file no longer exists in tree, so I think it is safe to mark this as resolved. -- 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 13014] LLVM_DEFAULT_TARGET_TRIPLE can't be set at cmake invocation time
https://llvm.org/bugs/show_bug.cgi?id=13014 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #2 from Chris Bieneman --- This was fixed ages ago. -- 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 16290] compiler-rt can not be compiled by cmake
https://llvm.org/bugs/show_bug.cgi?id=16290 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #1 from Chris Bieneman --- Yang, The problem you were encountering is that the Compiler-RT CMake build used to require being configured as part of an LLVM build. Today this is no longer true, however you do need to have an LLVM source directory or installation in order to use all features of the system. Since this bug is years old, and I know the workflow is currently supported I'm going to mark it as resolved. If you have further issues when working on LLVM 3.9 or LLVM trunk please file new bugs, and I promise we'll try to be more prompt. -- 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 16179] CMake Error: Error: generator : Unix Makefiles
https://llvm.org/bugs/show_bug.cgi?id=16179 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #2 from Chris Bieneman --- The error on the original message here indicates that CMake was previously run in the same build directory with "-G Ninja" and was being re-run with "-G Unix Makefiles". Changing generators is not supported by CMake, so you need to clean out your build directory if you are going to do that. WRT the second comment from Pedro, that seems like a separate issue. If you're still encountering it please file a separate bug report. -- 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 29060] New: alloc/dealloc mismatch caught by ASAN
https://llvm.org/bugs/show_bug.cgi?id=29060
Bug ID: 29060
Summary: alloc/dealloc mismatch caught by ASAN
Product: libc++
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: alex.zavo...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Created attachment 17006
--> https://llvm.org/bugs/attachment.cgi?id=17006&action=edit
Test code that reproduces the error.
This simple code produces an alloc-dealloc-mismatch report when run with
address sanitization enabled:
#include
int main()
{
try {
throw std::runtime_error("");
} catch (std::exception const&) {
}
}
Command line used for compilation:
clang++ -fsanitize=address --stdlib=libc++ alloc_dealloc_mismatch_repro.cpp
Produces, on execution:
=
==11344==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs
operator delete) on 0x6030efe0
#0 0x4f2740 (/tmp/repro/a.out+0x4f2740)
#1 0x7ff6d213cf00 (/usr/lib/x86_64-linux-gnu/libc++.so.1+0xc3f00)
#2 0x7ff6d20f6a30 (/usr/lib/x86_64-linux-gnu/libc++.so.1+0x7da30)
#3 0x4f5028 (/tmp/repro/a.out+0x4f5028)
#4 0x7ff6d118ff44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#5 0x419d65 (/tmp/repro/a.out+0x419d65)
0x6030efe0 is located 0 bytes inside of 25-byte region
[0x6030efe0,0x6030eff9)
allocated by thread T0 here:
#0 0x4f2290 (/tmp/repro/a.out+0x4f2290)
#1 0x7ff6d213194c (/usr/lib/x86_64-linux-gnu/libc++.so.1+0xb894c)
#2 0x7ff6d118ff44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/tmp/repro/a.out+0x4f2740)
==11344==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==11344==ABORTING
This reproduces reliably using clang-3.8, on Ubuntu 14.04.
NOTE: the problem does not reproduce with --stdlib=libstdc++.
NOTE: this appears to be a duplicate of bug ID 17379, which is marked as fixed,
but as mentioned still repros on clang-3.8.
--
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 18331] [cmake] Please make compiler-rt's build system stand-alone
https://llvm.org/bugs/show_bug.cgi?id=18331 Chris Bieneman changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #4 from Chris Bieneman --- This does work today, and it is extensively used. That said, it is important to understand that you do not need clang to build compiler-rt. Compiler-RT is used with GCC as well as Clang (which is part of why the standalone build is so important). There are two ways to have in-tree "standalone" builds which use the just-built clang. The mechanism Samsonov commented on "-DLLVM_BUILD_EXTERNAL_COMPILER_RT=On" is more mature, and well supported. Additionally Compiler-RT can be placed in the new LLVM/runtimes subdirectory if you have an LLVM tree. The new runtimes subdirectory seeks to solve a wider problem of enabling building all runtime projects and managing inter-project dependencies. Marking as resolved, if there are further issues please let me know. -- 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 29061] New: Inline assembly: 1 byte passed with constraint S" moved into DH instead of ESI
https://llvm.org/bugs/show_bug.cgi?id=29061
Bug ID: 29061
Summary: Inline assembly: 1 byte passed with constraint S"
moved into DH instead of ESI
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: philipp.kl...@web.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This code
void test(char c)
{
__asm__("" : : "S"(c));
}
creates this disassembled output:
:
0: 56 push %esi
1: 8a 74 24 08 mov0x8(%esp),%dh
5: 5e pop%esi
6: c3 ret
--
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 20668] cmake build of compiler-rt on Mac fails when LDFLAGS are set
https://llvm.org/bugs/show_bug.cgi?id=20668 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #2 from Chris Bieneman --- Hans, This should not be an issue if you use either the LLVM runtimes subdirectory or -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On. I'm really hopeful that sometime in the near future these will be the only supported ways to build compiler-rt in-tree. Please let me know if that sufficiently covers your needs. -- 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 29062] New: Multiple issues with #pragma bss_seg
https://llvm.org/bugs/show_bug.cgi?id=29062
Bug ID: 29062
Summary: Multiple issues with #pragma bss_seg
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: richard.bar...@arm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Reproduce all of the below with:
clang -c -fms-extensions test.c
llvm-objdump -t -section-headers test.o
The first bug is that bss_seg does not result in a section of the correct type:
#pragma bss_seg(".bss2")
int a2;
a2 is correctly placed in a section called .bss2, however the resulting .bss2
section is marked DATA and not BSS.
3 .bss2 0004 DATA
...
g .bss2 0004 a2
Removing the pragma causes the variable to be emitted as a common variable.
The second bug is that bss_seg is ignored for some zi data:
#pragma bss_seg(".bss2")
int b2 = 0;
This results in b2 being created as a zi variable, but in the default .bss
section rather than the special .bss2 section, which is not created at all.
3 .bss 0004 BSS
...
g .bss0004 b2
Combining the above two examples shows a2 going in the correct section but with
the wrong attributes, whilst b2 ends up in the wrong section but with the
correct attributes!
The third issue as that when the #pragma does work, it appears to not respect
ordering and apply across the whole file:
int a1;
#pragma bss_seg(".bss2")
int a2;
The #pragma should only apply to subsequent declarations, so a1 should be a
common symbol and a2 should end up in .bss2. Instead both a1 and a2 ending up
in .specialzi.
g .bss2 0004 a1
0004 g .bss2 0004 a2
If you pop or reset the pragma bss_seg after a2 is declared then both variables
end up as common symbols:
int a1;
#pragma bss_seg(".bss2")
int a2;
#pragma bss_seg()
0004 g *COM* 0004 a1
0004 g *COM* 0004 a2
It seems that the last pragma bss_seg value wins the day and applies to all zi
data.
Finally, some zi data can be affected by the data_seg pragma:
int b1 = 0;
#pragma data_seg("specialrw")
int b2 = 0;
I would expect that given b1 is zi data, then b2 would end up in the same place
as the pragma should not apply. Instead b2 goes in "specialrw"
3 .bss 0004 BSS
4 specialrw 0004 DATA
...
g .bss0004 b1
g specialrw 0004 b2
--
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 13260] CMake-generated projects cannot run single test suite
https://llvm.org/bugs/show_bug.cgi?id=13260
Chris Bieneman changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||chris.biene...@me.com
Resolution|--- |FIXED
--- Comment #3 from Chris Bieneman ---
Jordan,
I believe this is now fully resolved for non-IDE generators. In r268806 Justin
Bogner added a feature that generates check targets for every subdirectory
under the tests directories. The targets follow the format
check-${project}-${subdir}, where subdir is the name of the subdirectories
under the test directory with slashes replaced by dashes.
This follows exactly what Takumi commented where the target
check-clang-Analysis runs the tests under clang/test/Analysis. Additionally
check-clang-Analysis-objc runs the tests under clang/test/Analysis/objc.
This workflow is not supported in multi-configuration generators (i.e. Visual
Studio & Xcode) because IDEs seem to have a problem with excessive numbers of
targets being generated, but it works great if you use Ninja or Make.
Is this sufficient for your needs?
--
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 29063] New: __eprintf should only be provided for i386
https://llvm.org/bugs/show_bug.cgi?id=29063 Bug ID: 29063 Summary: __eprintf should only be provided for i386 Product: compiler-rt Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: jerem...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Followup to bug #28855. In older versions of compiler-rt, __eprintf was only provided in libclang_rt.eprintf.a and only for i386. See r114509 (clang git mirror 885b1dbc6e48db318f7a6b72c1592e8fb46b081a). The cmake build transition incorrectly added __eprintf to libclang_rt.osx.a and did so for all architectures (bug #28855). The resolution for bug #28855 did not resolve the regression in compiler-rt but instead updated clang to no longer link libclang_rt.eprintf.a. If the intended direction is to include __eprintf in libclang_rt.osx.a, then compiler-rt needs to be updated to: 1) Stop building libclang_rt.eprintf.a 2) Only include __eprintf in the i386 slice -- 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 29064] New: Clang hangs compiling part of Chromium on Mac
https://llvm.org/bugs/show_bug.cgi?id=29064 Bug ID: 29064 Summary: Clang hangs compiling part of Chromium on Mac Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org, r...@google.com, seb...@gmail.com Classification: Unclassified Created attachment 17008 --> https://llvm.org/bugs/attachment.cgi?id=17008&action=edit repro Reproduction with the attached source: $ clang -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 253.3 -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=lldb -stdlib=libc++ -O2 -std=c++11 -fdeprecated-macro -fvisibility hidden -fvisibility-inlines-hidden -stack-protector 1 -fblocks -fno-rtti -fno-threadsafe-statics -fobjc-runtime=macosx-10.7.0 -fencode-extended-block-signature -fmax-type-align=16 -vectorize-loops -vectorize-slp -o /dev/null -x c++ /tmp/b.ii I think this was triggered by a change in libc++: r278356, which added __always__inline__ on the basic_string<>::__init methods. The function being compiled, _Z23PopulateIpcMessageNamesRN10ipc_fuzzer12MessageNamesE is constructing a very large number of strings, so it might be that this change pushed the compile time from very slow to glacial by hitting some quadratic algorithm (MemoryDependenceAnalysis?) The stack from where clang is spending time looks like this: #0 InsertIntoBucketImpl (TheBucket=0x1c15a560, Lookup=@0x7fffa870: 0x15a01a18, Key=@0x7fffa870: 0x15a01a18, this=0x7fffaed0) at ../include/llvm/ADT/DenseMap.h:487 #1 InsertIntoBucket (Key=@0x7fffa870: 0x15a01a18, TheBucket=0x1c15a560, this=0x7fffaed0) at ../include/llvm/ADT/DenseMap.h:450 #2 FindAndConstruct (Key=@0x7fffa870: 0x15a01a18, this=0x7fffaed0) at ../include/llvm/ADT/DenseMap.h:267 #3 operator[] (Key=@0x7fffa870: 0x15a01a18, this=0x7fffaed0) at ../include/llvm/ADT/DenseMap.h:271 #4 llvm::OrderedBasicBlock::comesBefore (this=0x7fffaed0, A=0x14ef32a8, B=0x15a142c8) at ../lib/Analysis/OrderedBasicBlock.cpp:50 #5 0x0148ca2c in llvm::OrderedBasicBlock::dominates (this=, A=, B=B@entry=0x15a142c8) at ../lib/Analysis/OrderedBasicBlock.cpp:84 #6 0x0140052e in (anonymous namespace)::CapturesBefore::isSafeToPrune (this=this@entry=0x7fffacd0, I=0x15a142c8) at ../lib/Analysis/CaptureTracking.cpp:90 #7 0x014007b8 in (anonymous namespace)::CapturesBefore::shouldExplore (this=0x7fffacd0, U=) at ../lib/Analysis/CaptureTracking.cpp:124 #8 0x01400abb in llvm::PointerMayBeCaptured (V=V@entry=0x15e37d28, Tracker=Tracker@entry=0x7fffacd0) at ../lib/Analysis/CaptureTracking.cpp:226 #9 0x01401c29 in llvm::PointerMayBeCapturedBefore (V=V@entry=0x15e37d28, ReturnCaptures=ReturnCaptures@entry=true, StoreCaptures=StoreCaptures@entry=true, I=I@entry=0x14ef32a8, DT=DT@entry=0xd5bcfe0, IncludeI=IncludeI@entry=true, OBB=OBB@entry=0x7fffaed0) at ../lib/Analysis/CaptureTracking.cpp:202 #10 0x013c80a5 in llvm::AAResults::callCapturesBefore (this=0x1a061c10, I=I@entry=0x14ef32a8, MemLoc=..., DT=0xd5bcfe0, OBB=OBB@entry=0x7fffaed0) at ../lib/Analysis/AliasAnalysis.cpp:448 #11 0x0147e620 in llvm::MemoryDependenceResults::getSimplePointerDependencyFrom (this=this@entry=0x17668e70, MemLoc=..., isLoad=isLoad@entry=false, ScanIt=..., BB=0x14597c70, QueryInst=0x0) at ../lib/Analysis/MemoryDependenceAnalysis.cpp:652 #12 0x0147e6af in llvm::MemoryDependenceResults::getPointerDependencyFrom (this=this@entry=0x17668e70, MemLoc=..., isLoad=isLoad@entry=false, ScanIt=..., BB=BB@entry=0x14597c70, QueryInst=QueryInst@entry=0x0) at ../lib/Analysis/MemoryDependenceAnalysis.cpp:341 #13 0x01a48e93 in eliminateDeadStores (BB=..., AA=AA@entry=0x1a061c10, MD=MD@entry=0x17668e70, DT=DT@entry=0xd5bcfe0, TLI=TLI@entry=0x8297c80) at ../lib/Transforms/Scalar/DeadStoreElimination.cpp:1143 #14 0x01a4a5cd in eliminateDeadStores (F=..., AA=0x1a061c10, MD=0x17668e70, DT=0xd5bcfe0, TLI=0x8297c80) at ../lib/Transforms/Scalar/DeadStoreElimination.cpp:1166 #15 0x0185114b in llvm::FPPassManager::runOnFunction (this=this@entry=0x14893850, F=...) at ../lib/IR/LegacyPassManager.cpp:1522 #16 0x0243e280 in RunPassOnSCC (DevirtualizedCall=, CallGraphUpToDate=, CG=..., CurSCC=..., P=0x14893850, this=) at ../lib/Analysis/CallGraphSCCPass.cpp:151 #17 RunAllPassesOnSCC (DevirtualizedCall=, CG=..., CurSCC=..., this=) at ../lib/Analysis/CallGraphSCCPass.cpp:420 #18 (anonymous namespace)::CGPassManager::runOnModule (this=, M=...) at ../lib/Analysis/CallGr
[llvm-bugs] [Bug 29065] New: [SCEV] scev expansion generates redundent code in memcheck during vectorization
https://llvm.org/bugs/show_bug.cgi?id=29065
Bug ID: 29065
Summary: [SCEV] scev expansion generates redundent code in
memcheck during vectorization
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: w...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase 1.c:
---
#define COMBP(d, s, m) ( ((d) & ~(m)) | ((s) & (m)) )
void foo(unsigned *dd, int dw, int dh, unsigned *ds, int dp, int sp, int sx,
int sy, int dx, int dy, unsigned lwmask) {
int i, j;
unsigned *ls, *ld;
int nw = dw >> 5;
int lwbits = dw & 31;
unsigned *psd = ds + sp * sy + (sx >> 5);
unsigned *pdd = dd + dp * dy + (dx >> 5);
for (i = 0; i < dh; i++) {
ls = psd + i * sp;
ld = pdd + i * dp;
for (j = 0; j < nw; j++) {
*ld = (*ls & *ld);
ld++;
ls++;
}
}
}
For the memcheck of innerloop vectorization, we expect the code like this:
ls = psd + i * sp;
ld = pdd + i * dp;
if (ls < ld + nw || ld < ls + nw)
goto conflict.
However, some computation defining psd and pdd are regenerated inside preheader
of innerloop, and these redundent computations cannot be cleaned up in later
pass.
for.body: ; preds = %for.inc21,
%for.body.lr.ph
%indvars.iv = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next, %for.inc21
]
%10 = mul i64 %0, %indvars.iv
%11 = add i64 %5, %10
%scevgep = getelementptr i32, i32* %dd, i64 %11 ==> The add involving %dd
has been computed outside of loop when defining pdd. why not directly use pdd
here.
%scevgep51 = bitcast i32* %scevgep to i8*
%12 = add i64 %7, %10
%scevgep52 = getelementptr i32, i32* %dd, i64 %12 ==> The add involving %dd
has been computed outside of loop when defininng pdd. why not directly use pdd
here.
%scevgep5253 = bitcast i32* %scevgep52 to i8*
%13 = mul i64 %1, %indvars.iv
%14 = add i64 %8, %13
%scevgep54 = getelementptr i32, i32* %ds, i64 %14 ==> The add involving %ds
has been computed outside of loop when defining psd. why not directly use psd
here.
%scevgep5455 = bitcast i32* %scevgep54 to i8*
%15 = add i64 %9, %13
%scevgep56 = getelementptr i32, i32* %ds, i64 %15 ==> The add involving %ds
has been computed outside of loop when defining psd. why not directly use psd
here.
%scevgep5657 = bitcast i32* %scevgep56 to i8*
br i1 %cmp1742, label %for.body18.preheader, label %for.inc21
...
vector.memcheck: ; preds = %min.iters.checked
%bound0 = icmp ule i8* %scevgep51, %scevgep5657
%bound1 = icmp ule i8* %scevgep5455, %scevgep5253
%found.conflict = and i1 %bound0, %bound1
%memcheck.conflict = and i1 %found.conflict, true
Final assembly for the memcheck:
# BB#5: # %vector.memcheck
# in Loop: Header=BB0_2 Depth=1
movq%r9, %r10
movq%r13, %r9
movq%rbp, %r13
movq-48(%rsp), %rdx # 8-byte Reload
leaq(%rdx,%rbx), %rbp
leaq(%r13,%rbp,4), %r15
movq-56(%rsp), %rdx # 8-byte Reload
leaq(%rdx,%rax), %rdx
movq-104(%rsp), %rbp# 8-byte Reload
leaq(%rbp,%rdx,4), %rdx
cmpq%rdx, %r15
movq-104(%rsp), %rbp# 8-byte Reload
ja .LBB0_8
# BB#6: # %vector.memcheck
# in Loop: Header=BB0_2 Depth=1
addq-72(%rsp), %rbx # 8-byte Folded Reload
leaq(%r13,%rbx,4), %rdx
addq-64(%rsp), %rax # 8-byte Folded Reload
leaq(%rbp,%rax,4), %rax
cmpq%rdx, %rax
ja .LBB0_8
When the iteration number of innerloop is not large enough, the preparation
code for vectorization/unroll in the preheader of innerloop matters. Such
preparation code to compute loop iteration number or generate runtime check is
often generated by SCEV expansion. Here the redundency exists because SCEV
expansion doesn't reuse existing value psd and pdd.
* D12090 and D21313 relieved the reuse problem of SCEV expansion somewhat, but
why they are defeated here?
New SCEV expr is created after decomposition and combination of original
SCEVs, without those SCEVs appearing inside of the new SCEV expr. An example,
an old SCEVAddExpr S which is {a + b} has an existing value v = a + b
associated with it. When we generate SCEV for expr S + c, a new SCEVAddExpr
with three operands will be created {a + b + c} and no S can be found in the
new SCEVAddExpr. When we expand the new SCEV, it will only generate a + b + c
instead of v + c.
* Wh
[llvm-bugs] [Bug 21903] Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor
https://llvm.org/bugs/show_bug.cgi?id=21903 Volkan Keles changed: What|Removed |Added Status|REOPENED|RESOLVED CC||vlkn...@gmail.com Resolution|--- |FIXED --- Comment #23 from Volkan Keles --- r275201 (BranchFolding: Use LivePhysReg to update live in lists) fixes this. -- 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 26391] Invalid defs/uses of the FPSW register after register allocation
https://llvm.org/bugs/show_bug.cgi?id=26391 Bug 26391 depends on bug 21903, which changed state. Bug 21903 Summary: Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor https://llvm.org/bugs/show_bug.cgi?id=21903 What|Removed |Added Status|REOPENED|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 29066] New: clang crashes on (valid?) code with inlined assembly: Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed
https://llvm.org/bugs/show_bug.cgi?id=29066
Bug ID: 29066
Summary: clang crashes on (valid?) code with inlined assembly:
Assertion `CastInst::castIsValid(opc, C, Ty) &&
"Invalid constantexpr cast!"' failed
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is a regression from 3.8.x, which accepts the code.
The code is rejected by GCC, however.
$ clang -v
clang version 4.0.0 (trunk 279116)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-3.8 -c small.c
$
$ gcc-6.1 -c small.c
small.c: In function ‘foo’:
small.c:5:3: error: inconsistent operand constraints in an ‘asm’
__asm__ ("": "=t" (a):"0" (0));
^~~
$
$ clang -c small.c
clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/IR/Constants.cpp:1462:
static llvm::Constant* llvm::ConstantExpr::getCast(unsigned int,
llvm::Constant*, llvm::Type*, bool): Assertion `CastInst::castIsValid(opc, C,
Ty) && "Invalid constantexpr cast!"' failed.
#0 0x01de8dd5 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/clang-trunk/bin/clang-4.0+0x1de8dd5)
#1 0x01de6ebe llvm::sys::RunSignalHandlers()
(/usr/local/clang-trunk/bin/clang-4.0+0x1de6ebe)
#2 0x01de7020 SignalHandler(int)
(/usr/local/clang-trunk/bin/clang-4.0+0x1de7020)
#3 0x7f8eeb2df340 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#4 0x7f8eea0d0cc9 gsignal
/build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7f8eea0d40d8 abort
/build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7f8eea0c9b86 __assert_fail_base
/build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0
#7 0x7f8eea0c9c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32)
#8 0x019cf676 llvm::ConstantExpr::getCast(unsigned int,
llvm::Constant*, llvm::Type*, bool)
(/usr/local/clang-trunk/bin/clang-4.0+0x19cf676)
#9 0x01f89b3d
clang::CodeGen::CodeGenFunction::EmitAsmStmt(clang::AsmStmt const&)
(/usr/local/clang-trunk/bin/clang-4.0+0x1f89b3d)
#10 0x01f8f45f
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/usr/local/clang-trunk/bin/clang-4.0+0x1f8f45f)
#11 0x01fb6422
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) (/usr/local/clang-trunk/bin/clang-4.0+0x1fb6422)
#12 0x01fc12e6
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
(/usr/local/clang-trunk/bin/clang-4.0+0x1fc12e6)
#13 0x01fe0c46
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/clang-trunk/bin/clang-4.0+0x1fe0c46)
#14 0x01ff14f1
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/clang-trunk/bin/clang-4.0+0x1ff14f1)
#15 0x01ff28b0
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
(/usr/local/clang-trunk/bin/clang-4.0+0x1ff28b0)
#16 0x01ff303d
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone
.part.6429] (/usr/local/clang-trunk/bin/clang-4.0+0x1ff303d)
#17 0x025841a
[llvm-bugs] [Bug 29067] New: building numpy on AARCH64 Android fails
https://llvm.org/bugs/show_bug.cgi?id=29067 Bug ID: 29067 Summary: building numpy on AARCH64 Android fails Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: geo...@comma.ai CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17010 --> https://llvm.org/bugs/attachment.cgi?id=17010&action=edit failing source file fatal error: error in backend: Cannot select: 0x7f98861e40: i32 = AArch64ISD::FCCMP 0x7f988d1000, 0x7f988d1000, Consta nt:i32<1>, Constant:i32<6>, 0x7f989bf260 0x7f988d1000: f128,ch = CopyFromReg 0x7f9b4d9fb0, Register:f128 %vreg1 0x7f98b3e720: f128 = Register %vreg1 0x7f988d1000: f128,ch = CopyFromReg 0x7f9b4d9fb0, Register:f128 %vreg1 0x7f98b3e720: f128 = Register %vreg1 0x7f988cf390: i32 = Constant<1> 0x7f988d1980: i32 = Constant<6> 0x7f989bf260: f128 = AArch64ISD::FCMP 0x7f98b3e4c0, 0x7f98b3e4c0 0x7f98b3e4c0: f128,ch = CopyFromReg 0x7f9b4d9fb0, Register:f128 %vreg3 0x7f98862d10: f128 = Register %vreg3 0x7f98b3e4c0: f128,ch = CopyFromReg 0x7f9b4d9fb0, Register:f128 %vreg3 0x7f98862d10: f128 = Register %vreg3 In function: CLONGDOUBLE_compare clang-3.8: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.8.1 (tags/RELEASE_381/final) Target: aarch64--linux-android Thread model: posix InstalledDir: /data/data/com.termux/files/usr/bin clang-3.8: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.8: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.8: note: diagnostic msg: /data/data/com.termux/files/usr/tmp/arraytypes-61df7f.c clang-3.8: note: diagnostic msg: /data/data/com.termux/files/usr/tmp/arraytypes-61df7f.sh clang-3.8: note: diagnostic msg: Contents of /data/data/com.termux/files/usr/tmp/arraytypes-61df7f.sh # Crash reproducer for clang version 3.8.1 (tags/RELEASE_381/final) # Driver args: "-D" "NDEBUG" "-g" "-fwrapv" "-O3" "-Wall" "-Wstrict-prototypes" "-O2" "-lm" "-fPIC" "-D" "HAVE_NPY_CONFIG_H=1" "-D" "_FILE_OFFSET_BITS=64" "-D" "_LARGEFILE_SOURCE=1" "-D" "_LARGEFILE64_SOURCE=1" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "numpy/core/include" "-I" "build/src.linux-aarch64-2.7/numpy/core/include/numpy" "-I" "numpy/core/src/private" "-I" "numpy/core/src" "-I" "numpy/core" "-I" "numpy/core/src/npymath" "-I" "numpy/core/src/multiarray" "-I" "numpy/core/src/umath" "-I" "numpy/core/src/npysort" "-I" "/usr/local/include/python2.7" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-c" "build/src.linux-aarch64-2.7/numpy/core/src/multiarray/arraytypes.c" "-o" "build/temp.linux-aarch64-2.7/build/src.linux-aarch64-2.7/numpy/core/src/multiarray/arraytypes.o" # Original command: "/data/data/com.termux/files/usr/bin/clang-3.8" "-cc1" "-triple" "aarch64--linux-android" "-emit-obj" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "arraytypes.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-fuse-init-array" "-target-cpu" "generic" "-target-feature" "+neon" "-target-abi" "aapcs" "-backend-option" "-aarch64-fix-cortex-a53-835769=1" "-dwarf-column-info" "-debug-info-kind=limited" "-dwarf-version=4" "-debugger-tuning=gdb" "-coverage-file" "/data/data/com.termux/files/home/build/numpy-1.11.1/build/temp.linux-aarch64-2.7/build/src.linux-aarch64-2.7/numpy/core/src/multiarray/arraytypes.o" "-resource-dir" "/data/data/com.termux/files/usr/bin/../lib/clang/3.8.1" "-D" "NDEBUG" "-D" "HAVE_NPY_CONFIG_H=1" "-D" "_FILE_OFFSET_BITS=64" "-D" "_LARGEFILE_SOURCE=1" "-D" "_LARGEFILE64_SOURCE=1" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "numpy/core/include" "-I" "build/src.linux-aarch64-2.7/numpy/core/include/numpy" "-I" "numpy/core/src/private" "-I" "numpy/core/src" "-I" "numpy/core" "-I" "numpy/core/src/npymath" "-I" "numpy/core/src/multiarray" "-I" "numpy/core/src/umath" "-I" "numpy/core/src/npysort" "-I" "/usr/local/include/python2.7" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-I" "build/src.linux-aarch64-2.7/numpy/core/src/private" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/data/data/com.termux/files/usr/bin/../lib/clang/3.8.1/include" "-internal-externc-isystem" "/data/data/com.termux/files/usr/include" "-O2" "-Wall" "-Wstrict-
