From bugzilla-daemon at llvm.org Tue Apr 1 07:20:45 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Apr 2014 14:20:45 +0000 Subject: [LLVMbugs] [Bug 19299] New: recent regression: clang asserts building ITK: "Elements of a VectorType must be a primitive type" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19299 Bug ID: 19299 Summary: recent regression: clang asserts building ITK: "Elements of a VectorType must be a primitive type" Product: new-bugs Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: sean at rogue-research.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12314 --> http://llvm.org/bugs/attachment.cgi?id=12314&action=edit requested files I have some buildbots that build open source projects with my own build of clang. Every once in a while I update my clang build, and when I updated from r203163 to r204925 the other day, my ITK builds started failing in release builds (but not debug). The error persists in r205200. The error is shown here: http://open.cdash.org/viewBuildError.php?buildid=3275542 It outputs: Assertion failed: (isValidElementType(ElementType) && "Elements of a VectorType must be a primitive type"), function get, file /Users/builder/llvm/llvm/lib/IR/Type.cpp, line 707. 0 clang-3.5 0x0000000102d81dd8 llvm::sys::PrintStackTrace(__sFILE*) + 40 1 clang-3.5 0x0000000102d822d4 SignalHandler(int) + 548 2 libsystem_c.dylib 0x00007fff8af2190a _sigtramp + 26 3 libsystem_c.dylib 0x00000000000001a0 _sigtramp + 1963845808 4 clang-3.5 0x0000000102d82096 abort + 22 5 clang-3.5 0x0000000102d82071 __assert_rtn + 81 6 clang-3.5 0x0000000102acffe7 llvm::VectorType::get(llvm::Type*, unsigned int) + 295 7 clang-3.5 0x0000000102e21b3f (anonymous namespace)::BoUpSLP::getTreeCost() + 2447 8 clang-3.5 0x0000000102e1d3c4 (anonymous namespace)::SLPVectorizer::runOnFunction(llvm::Function&) + 10068 9 clang-3.5 0x0000000102aba4bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 347 10 clang-3.5 0x0000000102ae931a (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 1994 11 clang-3.5 0x0000000102abad29 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1081 12 clang-3.5 0x0000000102abb13d llvm::legacy::PassManager::run(llvm::Module&) + 13 13 clang-3.5 0x00000001033596fa clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 5770 14 clang-3.5 0x000000010346daac clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 588 15 clang-3.5 0x0000000103726034 clang::ParseAST(clang::Sema&, bool, bool) + 516 16 clang-3.5 0x000000010346c5da clang::CodeGenAction::ExecuteAction() + 122 17 clang-3.5 0x0000000102f56506 clang::FrontendAction::Execute() + 134 18 clang-3.5 0x0000000102f2ef0d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 973 19 clang-3.5 0x0000000102f8a444 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4372 20 clang-3.5 0x0000000102349df1 cc1_main(char const**, char const**, char const*, void*) + 945 21 clang-3.5 0x0000000102346ace main + 1150 22 libdyld.dylib 0x00007fff8adf77e1 start + 0 Stack dump: 0. Program arguments: /Users/builder/llvm/llvm-rel-install/bin/clang-3.5 -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -disable-free -main-file-name itkTransformFactoryBase.cxx -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -gdwarf-2 -coverage-file /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/IO/TransformBase/src/CMakeFiles/ITKIOTransformBase.dir/itkTransformFactoryBase.cxx.o -resource-dir /Users/builder/llvm/llvm-rel-install/bin/../lib/clang/3.5.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -D _FORTIFY_SOURCE=2 -D NDEBUG -I /Users/builder/external/ITK/Modules/ThirdParty/DoubleConversion/src/double-conversion -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/KWSys/src -I /Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I /Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/vcl -I /Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/core -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/VNL/src/vxl/vcl -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/VNL/src/vxl/core -I /Users/builder/external/ITK/Modules/ThirdParty/VNLInstantiation/include -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/Core/Common -I /Users/builder/external/ITK/Modules/Core/Common/include -I /Users/builder/external/ITK/Modules/Filtering/ImageFilterBase/include -I /Users/builder/external/ITK/Modules/Core/ImageAdaptors/include -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/Netlib -I /Users/builder/external/ITK/Modules/Numerics/Statistics/include -I /Users/builder/external/ITK/Modules/Core/Transform/include -I /Users/builder/external/ITK/Modules/Core/ImageFunction/include -I /Users/builder/external/ITK/Modules/Filtering/ImageGrid/include -I /Users/builder/external/ITK/Modules/Filtering/ImageCompose/include -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/IO/ImageBase -I /Users/builder/external/ITK/Modules/IO/ImageBase/include -I /Users/builder/external/ITK/Modules/Core/Mesh/include -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/ZLIB/src -I /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/ThirdParty/MetaIO/src/MetaIO -I /Users/builder/external/ITK/Modules/ThirdParty/MetaIO/src/MetaIO -I /Users/builder/external/ITK/Modules/Core/SpatialObjects/include -I /Users/builder/external/ITK/Modules/Filtering/ImageStatistics/include -I /Users/builder/external/ITK/Modules/Filtering/Path/include -I /Users/builder/external/ITK/Modules/Filtering/ImageIntensity/include -I /Users/builder/external/ITK/Modules/Filtering/DisplacementField/include -I /Users/builder/external/ITK/Modules/IO/TransformBase/include -O3 -Weverything -Wno-padded -Wno-missing-noreturn -Wno-unused-macros -Wno-missing-prototypes -Wno-sign-conversion -Wno-conversion -Wno-unreachable-code-break -Wno-extra-semi -Wno-weak-vtables -Wno-c++98-compat-pedantic -Wno-global-constructors -Wno-unreachable-code -Wno-documentation -Wno-float-equal -Wno-exit-time-destructors -Wno-implicit-fallthrough -Wno-switch-enum -Wno-covered-switch-default -Wno-missing-variable-declarations -Wno-undef -Wno-weak-template-vtables -Wno-conditional-uninitialized -Wno-unused-member-function -Wno-old-style-cast -Wno-over-aligned -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -std=c++11 -fdebug-compilation-dir /Users/builder/external/ITK-clang-rel-x86_64-static/Modules/IO/TransformBase/src -ferror-limit 19 -fmessage-length 0 -stack-protector 3 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o CMakeFiles/ITKIOTransformBase.dir/itkTransformFactoryBase.cxx.o -x c++ /Users/builder/external/ITK/Modules/IO/TransformBase/src/itkTransformFactoryBase.cxx 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module '/Users/builder/external/ITK/Modules/IO/TransformBase/src/itkTransformFactoryBase.cxx'. 4. Running pass 'SLP Vectorizer' on function '@_ZN3itk20ImageTransformHelperILj3ELj1ELj2EddE32TransformPhysicalPointToIndexRowERKNS_6MatrixIdLj3ELj3EEERKNS_5PointIdLj3EEES9_RS7_RNS_5IndexILj3EEERKNS_7Concept6Detail15UniqueType_boolILb0EEE' clang-3.5: error: unable to execute command: Illegal instruction: 4 clang-3.5: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.5.0 (205200) Target: x86_64-apple-darwin12.5.0 Thread model: posix clang-3.5: 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.5: 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.5: note: diagnostic msg: /var/folders/_j/yk9_m1js2jq67w2sbxfgrxkr0000gn/T/itkTransformFactoryBase-daf49c.cpp clang-3.5: note: diagnostic msg: /var/folders/_j/yk9_m1js2jq67w2sbxfgrxkr0000gn/T/itkTransformFactoryBase-daf49c.sh clang-3.5: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 11:36:31 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Apr 2014 18:36:31 +0000 Subject: [LLVMbugs] [Bug 19300] New: clang-llvm/llvm/lib/CodeGen/SplitKit.cpp:379: llvm::VNInfo* llvm::SplitEditor::defValue(unsigned int, const llvm::VNInfo*, llvm::SlotIndex): Assertion `Edit->getParent().getVNInfoAt(Idx) == ParentVNI && "Bad Parent VNI"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19300 Bug ID: 19300 Summary: clang-llvm/llvm/lib/CodeGen/SplitKit.cpp:379: llvm::VNInfo* llvm::SplitEditor::defValue(unsigned int, const llvm::VNInfo*, llvm::SlotIndex): Assertion `Edit->getParent().getVNInfoAt(Idx) == ParentVNI && "Bad Parent VNI"' failed. Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: clusty1 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12315 --> http://llvm.org/bugs/attachment.cgi?id=12315&action=edit suggested posting file1 Tried compiling clang with gcc 4.1.2. The compile line was: CC=gcc CXX=g++ ../llvm/configure --with-gcc-toolchain=/usr/lib/gcc/x86_64-redhat-linux/4.1.2 --enable-optimized The error message was: COMPILE: clang_linux/full-x86_64/x86_64: /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/lib/muldc3.c clang: /mnt/p4/longueuil/clang-llvm/llvm/lib/CodeGen/SplitKit.cpp:379: llvm::VNInfo* llvm::SplitEditor::defValue(unsigned int, const llvm::VNInfo*, llvm::SlotIndex): Assertion `Edit->getParent().getVNInfoAt(Idx) == ParentVNI && "Bad Parent VNI"' failed. 0 clang 0x0000000002d14b52 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 clang 0x0000000002d15877 2 libpthread.so.0 0x00000034e5e0e4c0 3 libc.so.6 0x00000034e5230215 gsignal + 53 4 libc.so.6 0x00000034e5231cc0 abort + 272 5 libc.so.6 0x00000034e5229696 __assert_fail + 246 6 clang 0x00000000026aacaf llvm::SplitEditor::defValue(unsigned int, llvm::VNInfo const*, llvm::SlotIndex) + 703 7 clang 0x00000000026ab260 llvm::SplitEditor::defFromParent(unsigned int, llvm::VNInfo*, llvm::SlotIndex, llvm::MachineBasicBlock&, llvm::MachineBasicBlock::bundle_iterator >) + 688 8 clang 0x00000000026ab6fc llvm::SplitEditor::leaveIntvAfter(llvm::SlotIndex) + 780 9 clang 0x00000000026b07be llvm::SplitEditor::splitRegInBlock(llvm::SplitAnalysis::BlockInfo const&, unsigned int, llvm::SlotIndex) + 1006 10 clang 0x000000000266a5cc 11 clang 0x000000000266b539 12 clang 0x000000000266e7aa 13 clang 0x000000000266ec72 14 clang 0x000000000277748b llvm::RegAllocBase::allocatePhysRegs() + 299 15 clang 0x00000000026663f7 16 clang 0x00000000025e2dc5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 53 17 clang 0x0000000002c8b7c5 llvm::FPPassManager::runOnFunction(llvm::Function&) + 677 18 clang 0x0000000002c8b85b llvm::FPPassManager::runOnModule(llvm::Module&) + 43 19 clang 0x0000000002c8b2bf llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1087 20 clang 0x0000000002c8b50d llvm::legacy::PassManager::run(llvm::Module&) + 13 21 clang 0x0000000000951909 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1961 22 clang 0x000000000094e183 23 clang 0x0000000000b91167 clang::ParseAST(clang::Sema&, bool, bool) + 391 24 clang 0x000000000094beac clang::CodeGenAction::ExecuteAction() + 60 25 clang 0x000000000071e4e9 clang::FrontendAction::Execute() + 297 26 clang 0x00000000006f4a2e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 350 27 clang 0x00000000006cb65a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 890 28 clang 0x00000000006c2bf4 cc1_main(char const**, char const**, char const*, void*) + 1284 29 clang 0x00000000006c9977 main + 5303 30 libc.so.6 0x00000034e521d974 __libc_start_main + 244 31 clang 0x00000000006c18a9 Stack dump: 0. Program arguments: /mnt/p4/longueuil/clang-llvm/build/Release+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name muldc3.c -mrelocation-model pic -pic-level 2 -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.17.50.0.6 -momit-leaf-frame-pointer -coverage-file /mnt/p4/longueuil/clang-llvm/build/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/muldc3.o -resource-dir /mnt/p4/longueuil/clang-llvm/build/Release+Asserts/bin/../lib/clang/3.4 -isysroot /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/SDKs/linux -internal-isystem /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/SDKs/linux/usr/local/include -internal-isystem /mnt/p4/longueuil/clang-llvm/build/Release+Asserts/bin/../lib/clang/3.4/include -internal-externc-isystem /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/SDKs/linux/include -internal-externc-isystem /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/SDKs/linux/usr/include -O3 -Wall -Werror -fdebug-compilation-dir /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt -ferror-limit 19 -fmessage-length 162 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /mnt/p4/longueuil/clang-llvm/build/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/muldc3.o -x c /mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/lib/muldc3.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt/lib/muldc3.c'. 4. Running pass 'Greedy Register Allocator' on function '@__muldc3' clang: error: unable to execute command: Aborted clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.4 (tags/RELEASE_34/final) Target: x86_64-unknown-linux-gnu Thread model: posix clang: 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: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/muldc3-776a4c.c clang: note: diagnostic msg: /tmp/muldc3-776a4c.sh clang: note: diagnostic msg: ******************** make[5]: *** [/mnt/p4/longueuil/clang-llvm/build/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/muldc3.o] Error 254 make[5]: Leaving directory `/mnt/p4/longueuil/clang-llvm/llvm/projects/compiler-rt' make[4]: *** [BuildRuntimeLibraries] Error 2 make[4]: Leaving directory `/mnt/p4/longueuil/clang-llvm/build/tools/clang/runtime/compiler-rt' make[3]: *** [compiler-rt/.makeall] Error 2 make[3]: Leaving directory `/mnt/p4/longueuil/clang-llvm/build/tools/clang/runtime' make[2]: *** [all] Error 1 make[2]: Leaving directory `/mnt/p4/longueuil/clang-llvm/build/tools/clang' make[1]: *** [clang/.makeall] Error 2 make[1]: Leaving directory `/mnt/p4/longueuil/clang-llvm/build/tools' make: *** [all] Error 1 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 11:58:11 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Apr 2014 18:58:11 +0000 Subject: [LLVMbugs] [Bug 19301] New: Missing kernel intrinsics Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19301 Bug ID: 19301 Summary: Missing kernel intrinsics Product: clang Version: 3.4 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: sgraf at resolutech.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12316 --> http://llvm.org/bugs/attachment.cgi?id=12316&action=edit An example driver and build batch files that has tests for the three intrinsics The following kernel mode only intrinsics appear to be incomplete: * __readmsr * __readcr3 * __writecr3 I am attaching the device driver I augmented in order to test these intrinsics. We used Visual Studio 2010 and LLVM 3.4 and Clang 3.4 for our testing. We were using the intrin.h file from r203816. We are also using the Windows XP DDK, which can be downloaded from https://dl.dropboxusercontent.com/u/17668567/1830_usa_ddk.iso -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 13:32:04 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Apr 2014 20:32:04 +0000 Subject: [LLVMbugs] [Bug 19302] New: Undefined behavior in v1/__tree and v1/list Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19302 Bug ID: 19302 Summary: Undefined behavior in v1/__tree and v1/list Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: octoploid at yandex.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified While debugging a gold linker issue I came across the following -fsanitize=undefined runtime error: /usr/include/c++/v1/list:218:19: runtime error: downcast of address 0x7fffa93b8e88 with insufficient space for an object of type 'std::__1::__list_node' 0x7fffa93b8e88: note: pointer points here 00 00 00 00 50 94 3b a9 ff 7f 00 00 20 3b d1 02 00 00 00 00 00 00 00 81 ff ff ff ff 01 00 00 00 ^ /usr/include/c++/v1/list:219:19: runtime error: downcast of address 0x7fffa93b8e88 with insufficient space for an object of type 'std::__1::__list_node' 0x7fffa93b8e88: note: pointer points here 00 00 00 00 88 8e 3b a9 ff 7f 00 00 20 3b d1 02 00 00 00 00 00 00 00 81 ff ff ff ff 01 00 00 00 ^ /usr/include/c++/v1/list:592:25: runtime error: downcast of address 0x7fffa93b8ed0 with insufficient space for an object of type 'std::__1::__list_node' 0x7fffa93b8ed0: note: pointer points here ff 7f 00 00 30 2e 04 03 00 00 00 00 30 2e 04 03 00 00 00 00 01 00 00 00 00 00 00 00 70 89 65 03 ^ /usr/include/c++/v1/__tree:834:16: runtime error: downcast of address 0x7fffa93b8e00 with insufficient space for an object of type 'std::__1::__tree_node, std::__1::allocator >, gold::Output_segment *>, void *>' 0x7fffa93b8e00: note: pointer points here 00 00 00 00 40 21 0a 03 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 See: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031213.html for an analysis of the issue by Richard Smith. Basically one should use use reinterpret_cast instead of static_cast to avoid the undefined behavior. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 14:59:51 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 01 Apr 2014 21:59:51 +0000 Subject: [LLVMbugs] [Bug 19303] New: Warnings for Unused Parameters in llvm header files (when function is = delete) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19303 Bug ID: 19303 Summary: Warnings for Unused Parameters in llvm header files (when function is = delete) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: matsp.llvm at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12317 --> http://llvm.org/bugs/attachment.cgi?id=12317&action=edit Much simplified source file to show problem. When compiling my toy pascal compiler, including the header files from llvm (d73449481daee33615d907608a3a08548ce2ba65), I get warnings like this: /usr/local/llvm-debug/include/llvm/Support/MathExtras.h:223:15: error: unused parameter 'Val' [-Werror,-Wunused-parameter] findLastSet(T Val, ZeroBehavior ZB = ZB_Max) LLVM_DELETED_FUNCTION; ^ /usr/local/llvm-debug/include/llvm/Support/MathExtras.h:223:33: error: unused parameter 'ZB' [-Werror,-Wunused-parameter] findLastSet(T Val, ZeroBehavior ZB = ZB_Max) LLVM_DELETED_FUNCTION; preprocessed output of the source shows that "LLVM_DELETED_FUNCTION" translates to = delete: template typename std::enable_if::is_integer && std::numeric_limits::is_signed, T>::type findLastSet(T Val, ZeroBehavior ZB = ZB_Max) = delete; My compile command looks like this: clang++ -g -Wall -Werror -Wextra -Wno-unused-private-field -std=c++11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I `/usr/local/llvm-debug/bin/llvm-config --includedir` -c -o lexer.o lexer.cpp where lexer.cpp has been simplified to the file attached (one line of #include...) (There are multiple errors like this one - I fixed them temporarily by commenting out the offending variable name, leaving the type declaration in place, which fixes the warning). I'm not convinced whether this is a bug in LLVM or clang++, but I feel that I should report it somewhere, and expect it can be "moved" to the appropriate place if necessary. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 17:18:23 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 00:18:23 +0000 Subject: [LLVMbugs] [Bug 19304] New: Variable template confuses name lookup Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19304 Bug ID: 19304 Summary: Variable template confuses name lookup Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++1y Assignee: unassignedclangbugs at nondot.org Reporter: tommitissari at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified template struct Foo; template constexpr int bar = Foo::bar; template <> struct Foo { static constexpr int bar = 222; // Error [1] }; [1] Redefinition of 'bar' as different kind of symbol -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 1 17:29:41 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 00:29:41 +0000 Subject: [LLVMbugs] [Bug 19304] Variable template confuses name lookup In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19304 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |WORKSFORME --- Comment #1 from Richard Smith --- This works for me with Clang trunk. If you can repro with trunk, please reopen. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 00:33:03 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 07:33:03 +0000 Subject: [LLVMbugs] [Bug 19305] New: bogus unused variable warning for C++1y variable templates Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19305 Bug ID: 19305 Summary: bogus unused variable warning for C++1y variable templates Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++1y Assignee: unassignedclangbugs at nondot.org Reporter: kremenek at apple.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This looks like a bogus -Wunused-const-variable warning: $ cat test.cpp #include template constexpr const T pi(3.141592654); int main(int argc, const char * argv[]) { std::cout << pi << std::endl; return 0; } $ clang -std=c++1y c.cpp -Wunused-const-variable -fsyntax-only test.cpp:4:19: warning: unused variable 'pi' [-Wunused-const-variable] constexpr const T pi(3.141592654); ^ 1 warning generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 01:15:12 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 08:15:12 +0000 Subject: [LLVMbugs] [Bug 19307] New: Variables optimized too aggressively Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19307 Bug ID: 19307 Summary: Variables optimized too aggressively Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: joerg at NetBSD.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12318 --> http://llvm.org/bugs/attachment.cgi?id=12318&action=edit Test case Variables currently have a too short live time, making debugging more difficult. See comment at the start of the test case for how to reproduce. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 06:31:26 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 13:31:26 +0000 Subject: [LLVMbugs] [Bug 19291] Clang miscompiles the code with loop unrolling (-m32/-O2) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19291 Rafael Ávila de Espíndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rafael.espindola at gmail.com Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r205416. The problem were relocations like 0000007f 00000709 R_386_GOTOFF 00000000 .rodata.cst16 and gold not correctly updating them when the constants in .rodata.cst16 were merged. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 07:38:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 14:38:55 +0000 Subject: [LLVMbugs] [Bug 19309] New: __attribute__((no_sanitize_address)) should only be allowed at definitions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19309 Bug ID: 19309 Summary: __attribute__((no_sanitize_address)) should only be allowed at definitions Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: timurrrr at google.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I believe __attribute__((no_sanitize_address)) should only be allowed at function/method definitions. Consider a code like this: --- x.h --- class X { void f(); __attribute__((no_sanitize_address)) void g(); }; ----------- -- x.cpp -- #include "x.h" __attribute__((no_sanitize_address)) void X::f() { ... } void X::g() { ... } ----------- I've spent half a day analyzing a file like x.cpp before I looked at x.h. I think we should disallow __attribute__((no_sanitize_address)) at declaraions because: - it's more consistent - it's much more readable, there's no "implicit attribute applied somewhere else" when looking at the code of a function/method. - applying/removing the attribute would usually result in fewer recompilations -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 11:28:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 18:28:53 +0000 Subject: [LLVMbugs] [Bug 19305] bogus unused variable warning for C++1y variable templates In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19305 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Fixed in r205448. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 13:45:11 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 20:45:11 +0000 Subject: [LLVMbugs] [Bug 19312] New: [ARM64] APInt(128b, 0u 0s)LLVM ERROR: Cannot select: 0x249f338: f128 = ConstantFP [ID=1] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19312 Bug ID: 19312 Summary: [ARM64] APInt(128b, 0u 0s)LLVM ERROR: Cannot select: 0x249f338: f128 = ConstantFP [ID=1] Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case: ---------------------------------------------------------- target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128" target triple = "arm64-none-linux-gnu" define void @test() { entry: %call14 = tail call fp128 @gen_ldouble(fp128 0xL00000000000000000000000000000000) ret void } declare fp128 @gen_ldouble(fp128) ---------------------------------------------------------- Reproduce with: llc -O3 test.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 15:14:05 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 22:14:05 +0000 Subject: [LLVMbugs] [Bug 19313] New: [ARM64] ARM64InstrInfo.cpp:1343: Assertion `0 && "unimplemented reg-to-reg copy"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19313 Bug ID: 19313 Summary: [ARM64] ARM64InstrInfo.cpp:1343: Assertion `0 && "unimplemented reg-to-reg copy"' failed Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: apazos at codeaurora.org, grosbach at apple.com, llvmbugs at cs.uiuc.edu, t.p.northover at gmail.com Classification: Unclassified Test case: --------------------------------------------------------- target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128" target triple = "arm64--linux-gnu" @.str2 = external unnamed_addr constant [51 x i8], align 1 define void @t() { entry: %conv = fptosi fp128 undef to i32 tail call void (i8*, ...)* @f(i8* getelementptr inbounds ([51 x i8]* @.str2, i64 0, i64 0), i32 %conv, i32 24) ret void } declare void @f(i8*, ...) --------------------------------------------------------- Reproduce with: llc -O3 test.ll Complete failure backtrace: llc: llvm/lib/Target/ARM64/ARM64InstrInfo.cpp:1343: virtual void llvm::ARM64InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned int, bool) const: Assertion `0 && "unimplemented reg-to-reg copy"' failed. 0 llc 0x0000000000ced7f2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 llc 0x0000000000ced414 2 libpthread.so.0 0x00007f7fded9c8f0 3 libc.so.6 0x00007f7fde07ab25 gsignal + 53 4 libc.so.6 0x00007f7fde07e670 abort + 384 5 libc.so.6 0x00007f7fde0739f1 __assert_fail + 241 6 llc 0x00000000006fa168 llvm::ARM64InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::bundle_iterator >, llvm::DebugLoc, unsigned int, unsigned int, bool) const + 5352 7 llc 0x00000000007b552b 8 llc 0x0000000000a775ff llvm::FPPassManager::runOnFunction(llvm::Function&) + 655 9 llc 0x0000000000a77acb llvm::FPPassManager::runOnModule(llvm::Module&) + 43 10 llc 0x0000000000a77e0d llvm::legacy::PassManagerImpl::run(llvm::Module&) + 797 11 llc 0x0000000000501002 12 llc 0x0000000000502310 main + 272 13 libc.so.6 0x00007f7fde065c4d __libc_start_main + 253 14 llc 0x00000000004f9ba9 Stack dump: 0. Program arguments: llc -O3 test.ll 1. Running pass 'Function Pass Manager' on module 'test.ll'. 2. Running pass 'Post-RA pseudo instruction expansion pass' on function '@t' -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 16:05:27 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 23:05:27 +0000 Subject: [LLVMbugs] [Bug 19314] New: [ARM64] Use of __sincos_stret on non-Darwin platforms. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19314 Bug ID: 19314 Summary: [ARM64] Use of __sincos_stret on non-Darwin platforms. Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: apazos at codeaurora.org, bob.wilson at apple.com, grosbach at apple.com, llvmbugs at cs.uiuc.edu, t.p.northover at gmail.com Classification: Unclassified >From ARM64ISelLowering.cpp: ----------------------------------------------------------------------- // For iOS, we don't want to the normal expansion of a libcall to // sincos. We want to issue a libcall to __sincos_stret to avoid memory // traffic. setOperationAction(ISD::FSINCOS, MVT::f64, Custom); setOperationAction(ISD::FSINCOS, MVT::f32, Custom); ----------------------------------------------------------------------- This code needs to be conditionalized to accommodate non-Darwin platforms. This is causing link-time failures for a few SPEC benchmarks when using the –fno-math-errno flag, which is required for peak performance. I believe it suffices to just expand these on non-Darwin platforms: - setOperationAction(ISD::FSINCOS, MVT::f64, Custom); - setOperationAction(ISD::FSINCOS, MVT::f32, Custom); + setOperationAction(ISD::FSINCOS, MVT::f64, Expand); + setOperationAction(ISD::FSINCOS, MVT::f32, Expand); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 16:18:11 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 23:18:11 +0000 Subject: [LLVMbugs] [Bug 19264] -fms-extensions should always emit 'extern inline' functions and give them weak_odr linkage In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19264 David Majnemer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Majnemer --- Fixed in r205485. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 16:18:13 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 23:18:13 +0000 Subject: [LLVMbugs] [Bug 13707] [meta] VCPP compatibility issues In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13707 Bug 13707 depends on bug 19264, which changed state. Bug 19264 Summary: -fms-extensions should always emit 'extern inline' functions and give them weak_odr linkage http://llvm.org/bugs/show_bug.cgi?id=19264 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 16:18:15 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 23:18:15 +0000 Subject: [LLVMbugs] [Bug 18887] [META] Compiling Chromium on Windows with clang-cl In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18887 Bug 18887 depends on bug 19264, which changed state. Bug 19264 Summary: -fms-extensions should always emit 'extern inline' functions and give them weak_odr linkage http://llvm.org/bugs/show_bug.cgi?id=19264 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 16:38:07 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 02 Apr 2014 23:38:07 +0000 Subject: [LLVMbugs] [Bug 19315] New: scalar evolution crashes on function with many loops Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19315 Bug ID: 19315 Summary: scalar evolution crashes on function with many loops Product: new-bugs Version: 3.3 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: skye at cloudera.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12327 --> http://llvm.org/bugs/attachment.cgi?id=12327&action=edit repro LLVM appears to be infinitely recursing (or at least recursing way too much) on a function with 100s of inlined loops. I attached a small repro application. When I run opt -O2 on the compiled program, I get the following stack snippet: [...] #16540 0x000000000147b340 in llvm::ScalarEvolution::createNodeForGEP (this=0x358e2f0, GEP=0x35533a0) at ScalarEvolution.cpp:3183 #16541 0x0000000001479174 in llvm::ScalarEvolution::createSCEV (this=0x358e2f0, V=0x35533a0) at ScalarEvolution.cpp:3824 #16542 0x0000000001477517 in llvm::ScalarEvolution::getSCEV (this=0x358e2f0, V=0x35533a0) at ScalarEvolution.cpp:2725 #16543 0x000000000147ac9c in llvm::ScalarEvolution::createNodeForPHI (this=0x358e2f0, PN=0x3547ec0) at ScalarEvolution.cpp:3074 #16544 0x0000000001479195 in llvm::ScalarEvolution::createSCEV (this=0x358e2f0, V=0x3547ec0) at ScalarEvolution.cpp:3827 #16545 0x0000000001477517 in llvm::ScalarEvolution::getSCEV (this=0x358e2f0, V=0x3547ec0) at ScalarEvolution.cpp:2725 #16546 0x000000000147b340 in llvm::ScalarEvolution::createNodeForGEP (this=0x358e2f0, GEP=0x3550cd0) at ScalarEvolution.cpp:3183 #16547 0x0000000001479174 in llvm::ScalarEvolution::createSCEV (this=0x358e2f0, V=0x3550cd0) at ScalarEvolution.cpp:3824 #16548 0x0000000001477517 in llvm::ScalarEvolution::getSCEV (this=0x358e2f0, V=0x3550cd0) at ScalarEvolution.cpp:2725 #16549 0x000000000147ac9c in llvm::ScalarEvolution::createNodeForPHI (this=0x358e2f0, PN=0x35452e0) at ScalarEvolution.cpp:3074 #16550 0x0000000001479195 in llvm::ScalarEvolution::createSCEV (this=0x358e2f0, V=0x35452e0) at ScalarEvolution.cpp:3827 #16551 0x0000000001477517 in llvm::ScalarEvolution::getSCEV (this=0x358e2f0, V=0x35452e0) at ScalarEvolution.cpp:2725 #16552 0x0000000001483422 in llvm::ScalarEvolution::computeSCEVAtScope (this=0x358e2f0, V=0x359cbb0, L=0x35ae5f0) at ScalarEvolution.cpp:5186 #16553 0x000000000147f190 in llvm::ScalarEvolution::getSCEVAtScope (this=0x358e2f0, V=0x359cbb0, L=0x35ae5f0) at ScalarEvolution.cpp:5041 #16554 0x0000000001483f36 in llvm::ScalarEvolution::computeSCEVAtScope (this=0x358e2f0, V=0x359cbf0, L=0x35ae5f0) at ScalarEvolution.cpp:5309 #16555 0x000000000147f190 in llvm::ScalarEvolution::getSCEVAtScope (this=0x358e2f0, V=0x359cbf0, L=0x35ae5f0) at ScalarEvolution.cpp:5041 #16556 0x0000000001483440 in llvm::ScalarEvolution::computeSCEVAtScope (this=0x358e2f0, V=0x359cb10, L=0x35ae5f0) at ScalarEvolution.cpp:5187 #16557 0x000000000147f190 in llvm::ScalarEvolution::getSCEVAtScope (this=0x358e2f0, V=0x359cb10, L=0x35ae5f0) at ScalarEvolution.cpp:5041 #16558 0x000000000147df68 in llvm::ScalarEvolution::ComputeExitLimitFromICmp (this=0x358e2f0, L=0x35ae5f0, ExitCond=0x3548a40, TBB=0x354b6d0, FBB=0x354e490, IsSubExpr=false) at ScalarEvolution.cpp:4538 #16559 0x000000000147dcb2 in llvm::ScalarEvolution::ComputeExitLimitFromCond (this=0x358e2f0, L=0x35ae5f0, ExitCond=0x3548a40, TBB=0x354b6d0, FBB=0x354e490, IsSubExpr=false) at ScalarEvolution.cpp:4489 #16560 0x000000000147d549 in llvm::ScalarEvolution::ComputeExitLimit (this=0x358e2f0, L=0x35ae5f0, ExitingBlock=0x354e490) at ScalarEvolution.cpp:4394 #16561 0x000000000147c6f5 in llvm::ScalarEvolution::ComputeBackedgeTakenCount (this=0x358e2f0, L=0x35ae5f0) at ScalarEvolution.cpp:4307 #16562 0x000000000147bfb2 in llvm::ScalarEvolution::getBackedgeTakenInfo (this=0x358e2f0, L=0x35ae5f0) at ScalarEvolution.cpp:4064 #16563 0x000000000147bd1f in llvm::ScalarEvolution::getBackedgeTakenCount (this=0x358e2f0, L=0x35ae5f0) at ScalarEvolution.cpp:4027 #16564 0x000000000111fd60 in (anonymous namespace)::IndVarSimplify::runOnLoop (this=0x358dda0, L=0x35ae5f0, LPM=...) at IndVarSimplify.cpp:1755 #16565 0x00000000013ec63a in llvm::LPPassManager::runOnFunction (this=0x358ee70, F=...) at LoopPass.cpp:228 #16566 0x000000000170fa5b in llvm::FPPassManager::runOnFunction (this=0x3586ac0, F=...) at PassManager.cpp:1530 #16567 0x00000000013429b2 in (anonymous namespace)::CGPassManager::RunPassOnSCC (this=0x3585090, P=0x3586ac0, CurSCC=..., CG=..., CallGraphUpToDate=@0x7fff1315b32e: true, DevirtualizedCall=@0x7fff1315b3cb: false) at CallGraphSCCPass.cpp:148 #16568 0x0000000001342371 in (anonymous namespace)::CGPassManager::RunAllPassesOnSCC (this=0x3585090, CurSCC=..., CG=..., DevirtualizedCall=@0x7fff1315b3cb: false) at CallGraphSCCPass.cpp:404 #16569 0x0000000001341cc5 in (anonymous namespace)::CGPassManager::runOnModule (this=0x3585090, M=...) at CallGraphSCCPass.cpp:460 #16570 0x000000000171016a in llvm::MPPassManager::runOnModule (this=0x3567ed0, M=...) at PassManager.cpp:1608 #16571 0x000000000171091e in llvm::PassManagerImpl::run (this=0x3567be0, M=...) at PassManager.cpp:1703 #16572 0x0000000001710b71 in llvm::PassManager::run (this=0x7fff1315ba40, M=...) at PassManager.cpp:1738 #16573 0x0000000000657152 in main (argc=4, argv=0x7fff1315bc98) at opt.cpp:824 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 19:31:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 02:31:52 +0000 Subject: [LLVMbugs] [Bug 19317] New: [ARM] instrumentation code injection has user visible side-effects Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19317 Bug ID: 19317 Summary: [ARM] instrumentation code injection has user visible side-effects Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: compnerd at compnerd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When compiling with -pg, the instrumentation code injection appears to cause user-visible side-effects. This, in particular, breaks compiling Linux via clang. Consider the following minimal test case: // RUN: %clang_cc1 -triple=armv7-linux -S %s -o - | FileCheck %s void function(int i) { __asm__ __volatile__ (".ifnc %0, r0 ; .error \"ABI mismatch\" ; .endif" : : "r"(i)); } This translates to: define void arm_aapcscc @function(i32 %i) { entry: tail call void asm sideeffect ".ifnc $0, r0 ; .error \22ABI mismatch\22 ; .endif", "r"(i32 %i) ret void } Awesome: argument i is being passed along to the function, which is going to be in register r0 as per the AAPCS CC. However, compiling this with profiling (-pg) does a slightly different thing which is mostly correct: declare void @mcount() define void arm_aapcscc @function(i32 %i) { entry: tail call void @mcount() tail call void asm sideeffect ".ifnc $0, r0 ; .error \22ABI mismatch\22 ; .endif", "r"(i32 %i) ret void } This looks reasonable: the inserted mcount is what you would expect due to the profiling. And the argument is still passed along. However, when target lowering: you end up with the following: push {r4, r11, lr} add r11, sp, #4 mov r4, r0 bl mcount @APP .ifnc r4, r0 ; .error "ABI mismatch" ; endif @NO_APP pop {r4, r11, pc} So, we adjust the stack, save the parameters (since we have no idea what mcount will do) and call mcount. Now, we use the saved register (r4 is callee saved, so we know it has the right value at this point) and pass it along to the side effect (inline asm). This is now visible to the user. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 20:52:14 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 03:52:14 +0000 Subject: [LLVMbugs] [Bug 19318] New: Assertion during Peephole Optimization Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19318 Bug ID: 19318 Summary: Assertion during Peephole Optimization Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedbugs at nondot.org Reporter: rtrieu at google.com CC: lhames at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12329 --> http://llvm.org/bugs/attachment.cgi?id=12329&action=edit Preprocessed source mapper.cpp: include using std::map; using std::pair; template class Allocator { public: typedef T value_type; typedef unsigned size_type; typedef T* pointer; typedef const T* const_pointer; typedef T& reference; typedef const T& const_reference; template Allocator(X x) { } void deallocate(void* memory, size_type size) { if ( memory == pointer1 ) { pointer2 = pointer1; } } template struct rebind { typedef Allocator other; }; void destroy(void*) {} char* pointer1; char* pointer2; }; class MapWrapper { public: ~MapWrapper(); typedef map, Allocator > > Map; Map map_; }; MapWrapper::~MapWrapper() {} Commandline: clang -g -O2 mapper.cpp Output: clang-3.5: ../include/llvm/CodeGen/MachineOperand.h:265: unsigned int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. 0 clang-3.5 0x0000000001803b2e llvm::sys::PrintStackTrace(_IO_FILE*) + 46 1 clang-3.5 0x0000000001803e0b 2 clang-3.5 0x000000000180552e 3 libpthread.so.0 0x00007fef83178cb0 4 libc.so.6 0x00007fef823b6425 gsignal + 53 5 libc.so.6 0x00007fef823b9b8b abort + 379 6 libc.so.6 0x00007fef823af0ee 7 libc.so.6 0x00007fef823af192 8 clang-3.5 0x0000000000917cca 9 clang-3.5 0x0000000001f0509c llvm::MachineOperand::setReg(unsigned int) + 28 10 clang-3.5 0x0000000001f2cb20 llvm::MachineRegisterInfo::markUsesInDebugValueAsUndef(unsigned int) const + 192 11 clang-3.5 0x0000000001f75c83 12 clang-3.5 0x0000000001f0480e llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110 13 clang-3.5 0x00000000014921bb llvm::FPPassManager::runOnFunction(llvm::Function&) + 427 14 clang-3.5 0x00000000014924c8 llvm::FPPassManager::runOnModule(llvm::Module&) + 104 15 clang-3.5 0x0000000001492b8a 16 clang-3.5 0x000000000149277e llvm::legacy::PassManagerImpl::run(llvm::Module&) + 302 17 clang-3.5 0x0000000001493151 llvm::legacy::PassManager::run(llvm::Module&) + 33 18 clang-3.5 0x000000000209bb7c 19 clang-3.5 0x000000000209b4a2 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 114 20 clang-3.5 0x00000000020986d0 21 clang-3.5 0x0000000002b4674c clang::ParseAST(clang::Sema&, bool, bool) + 796 22 clang-3.5 0x00000000019f2f09 clang::ASTFrontendAction::ExecuteAction() + 345 23 clang-3.5 0x0000000002097b42 clang::CodeGenAction::ExecuteAction() + 1474 24 clang-3.5 0x00000000019f262f clang::FrontendAction::Execute() + 191 25 clang-3.5 0x00000000019bcc4d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 797 26 clang-3.5 0x0000000001b217e4 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1044 27 clang-3.5 0x000000000090b5ca cc1_main(char const**, char const**, char const*, void*) + 698 28 clang-3.5 0x0000000000902d27 main + 759 29 libc.so.6 0x00007fef823a176d __libc_start_main + 237 30 clang-3.5 0x00000000009028d5 Stack dump: 0. Program arguments: /usr/local/clang/qual/llvm/llvm_build/bin/clang-3.5 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name mapper.cpp -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -g -resource-dir /usr/local/clang/qual/llvm/llvm_build/bin/../lib/clang/3.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/x86_64-linux-gnu/c++/4.6 -internal-isystem /usr/local/include -internal-isystem /usr/local/clang/qual/llvm/llvm_build/bin/../lib/clang/3.5.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdeprecated-macro -fdebug-compilation-dir /usr/local/clang/qual/llvm/llvm_build -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/mapper-8a215e.o -x c++ mapper.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'mapper.cpp'. 4. Running pass 'Peephole Optimizations' on function '@_ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiE9AllocatorIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E' clang-3.5: error: unable to execute command: Aborted (core dumped) clang-3.5: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.5.0 (205487) Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.5: 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.5: 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.5: note: diagnostic msg: /tmp/mapper-dfa86a.cpp clang-3.5: note: diagnostic msg: /tmp/mapper-dfa86a.sh clang-3.5: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 21:07:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 04:07:53 +0000 Subject: [LLVMbugs] [Bug 19319] New: LoopVectorize does not check if function should be optimized at all Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19319 Bug ID: 19319 Summary: LoopVectorize does not check if function should be optimized at all Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: newchief at king.net.pl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Most of passes that inherit FunctionPass start their implementation of runOnFunction() like this (code taken from SLPVectorizer.cpp in the same directory): bool runOnFunction(Function &F) override { if (skipOptnoneFunction(F)) return false; ... For some reason LoopVectorizer.cpp does not contain such checking in its runOnFunction() method. Shouldn't it be added? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 22:03:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 05:03:52 +0000 Subject: [LLVMbugs] [Bug 19318] Assertion during Peephole Optimization In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19318 Lang Hames changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Lang Hames --- Yep - this was me. Fixed in r205511. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 22:53:21 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 05:53:21 +0000 Subject: [LLVMbugs] [Bug 19313] [ARM64] ARM64InstrInfo.cpp:1343: Assertion `0 && "unimplemented reg-to-reg copy"' failed In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19313 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tim Northover --- Yep, that case works for me now. Sorry I didn't comment myself sooner, GMail seems to have decided bugzilla is spam. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 2 23:58:02 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 06:58:02 +0000 Subject: [LLVMbugs] [Bug 19317] [ARM] instrumentation code injection has user visible side-effects In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19317 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |rnk at google.com Resolution|--- |INVALID --- Comment #1 from Reid Kleckner --- I don't think this is a bug. Users can't rely on parameters being in the registers specified by the ABI in inline asm. That's not modeled as part of the inline asm constraints. If they want it in r0, they should say so. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 00:06:42 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 07:06:42 +0000 Subject: [LLVMbugs] [Bug 19314] [ARM64] Use of __sincos_stret on non-Darwin platforms. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19314 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tim Northover --- Thanks Chad. I think I've fixed this in r205514 (following your suggestion). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 00:30:39 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 07:30:39 +0000 Subject: [LLVMbugs] [Bug 19312] [ARM64] APInt(128b, 0u 0s)LLVM ERROR: Cannot select: 0x249f338: f128 = ConstantFP [ID=1] In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19312 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Northover --- Thanks for reporting this. Chandler seems to have fixed it in r205161, and all three of the tests now pass. Resolving. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 02:26:42 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 09:26:42 +0000 Subject: [LLVMbugs] [Bug 19294] [ARM64] Cannot select: 0x5378c60: i32 = rotr 0x535df10, 0x535dbf8 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19294 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tim Northover --- This should be fixed in r205519. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 03:30:54 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 10:30:54 +0000 Subject: [LLVMbugs] [Bug 19320] New: Gnu Assembler compatibility fails on ldrd r12, [...] Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19320 Bug ID: 19320 Summary: Gnu Assembler compatibility fails on ldrd r12, [...] Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: stpworld at narod.ru CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12331 --> http://llvm.org/bugs/attachment.cgi?id=12331&action=edit Test case GNU Assembler compatibility fails on several commands: ldrd r12, [r0, #32] strd r12, [r0, #32] The trouble as in ARMAsmParser, in ParseInstruction method. It assumes that ARM::R12 + 1 == ARM::SP. It is wrong, since ARM:: codes are generated by tablegen and actually could be any random numbers. I think its critical misbehaviour. So first fast fix patch will be sent to LLVM-Commits. While actually I would like get rid of // GNU Assembler extension (compatibility) ... in further commits. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 04:00:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 11:00:28 +0000 Subject: [LLVMbugs] [Bug 19321] New: __attribute__((cleanup)) does not respect __block qualifier Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19321 Bug ID: 19321 Summary: __attribute__((cleanup)) does not respect __block qualifier Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: csdavec at swan.ac.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following simple test program: #include #include #include #include typedef int (^block_t)(void); static void freestr(char **s) { if (s) { printf("Freeing block: %s\n", *s); free(*s); *s = 0; } } block_t getCounter(char *name) { __attribute__((cleanup(freestr))) __block char *n = strdup(name); __block int c=0; return Block_copy(^() { printf("%s called %d times\n", n, ++c); return c; }); } int main(void) { block_t counter = getCounter("A counter"); counter(); counter(); counter(); counter(); Block_release(counter); return 0; } When run, produces: Freeing block: A counter (null) called 1 times (null) called 2 times (null) called 3 times (null) called 4 times The lifetime of the bound variable is the lifetime of the block, but the cleanup code runs sooner. The analogous C++ example (an object with a destructor) runs correctly. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 05:17:42 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 12:17:42 +0000 Subject: [LLVMbugs] [Bug 19317] [ARM] instrumentation code injection has user visible side-effects In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19317 Renato Golin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #5 from Renato Golin --- I get it now. The point here is not the inline assembly mess up, but the profiling on ARM. Yes, the inline asm is broken, but the profiler mcount should preserve R0~R3, at least according to this document: http://doc.ironwoodlabs.com/arm-arm-none-eabi/html/getting-started/arm-mcount.html Maybe we need to call __gnu_mcount_nc on ARM on gnueabi mode? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 05:36:37 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 12:36:37 +0000 Subject: [LLVMbugs] [Bug 19322] New: abort in static analysis Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19322 Bug ID: 19322 Summary: abort in static analysis Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: apostolos_1 at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified It aborts during static analysis. Sorry but I can't upload the file due to company policy. clang++: /Projects/LLVM/llvm/tools/clang/lib/StaticAnalyzer/Checkers/CastSizeChecker.cpp:61: bool evenFlexibleArraySize(clang::ASTContext &, clang::CharUnits, clang::CharUnits, clang::QualType): Assertion `Last && "empty structs should already be handled"' failed. 0 clang++ 0x0000000001e0cb05 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1 clang++ 0x0000000001e0d273 2 libpthread.so.0 0x00000034b8a0ef90 3 libc.so.6 0x00000034b82359e9 gsignal + 57 4 libc.so.6 0x00000034b82370f8 abort + 328 5 libc.so.6 0x00000034b822e956 6 libc.so.6 0x00000034b822ea02 7 clang++ 0x0000000000e9a834 8 clang++ 0x0000000000eca214 clang::ento::CheckerManager::runCheckersForStmt(bool, clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet const&, clang::Stmt const*, clang::ento::ExprEngine&, bool) + 884 9 clang++ 0x0000000000edf93d clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 4637 10 clang++ 0x0000000000edcd37 clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt, clang::ento::ExplodedNode*) + 839 11 clang++ 0x0000000000edc93c clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) + 188 12 clang++ 0x0000000000ed328e clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, clang::ento::ExplodedNode*) + 142 13 clang++ 0x0000000000ed2d30 clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*, clang::ProgramPoint, clang::ento::WorkListUnit const&) + 336 14 clang++ 0x0000000000ed2691 clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr) + 545 15 clang++ 0x0000000000dbd82a 16 clang++ 0x0000000000dbcb1e 17 clang++ 0x0000000000db9bf1 18 clang++ 0x000000000098e373 clang::ParseAST(clang::Sema&, bool, bool) + 515 19 clang++ 0x000000000065e4d1 clang::FrontendAction::Execute() + 113 20 clang++ 0x0000000000639b1d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 909 21 clang++ 0x000000000061f95f clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3087 22 clang++ 0x0000000000616f79 cc1_main(char const**, char const**, char const*, void*) + 569 23 clang++ 0x000000000061d795 main + 9621 24 libc.so.6 0x00000034b8221b45 __libc_start_main + 245 25 clang++ 0x0000000000616c71 Stack dump: 0. Program arguments: /opt/clang35_1/bin/clang++ -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name snmp_interface.cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=cplusplus -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-output plist -w -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.23.52.0.1 -momit-leaf-frame-pointer -resource-dir /opt/clang35_1/bin/../lib/clang/3.5.0 -D GTEST -D LINUX -D USE_SNMP_PP -D NDEBUG -I /Projects/REST/rest_proto/include -I /tmp/usr/local/include -I /Projects/REST/rest_proto/src/boards/wibas_ip/include -I /Projects/REST/rest_proto/src/controllers -I /Projects/REST-SDK/casablanca/Release/include -I /Projects/REST/rest_proto/src/. -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2 -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward -internal-isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/x86_64-redhat-linux/c++/4.8.2 -internal-isystem /usr/local/include -internal-isystem /opt/clang35_1/bin/../lib/clang/3.5.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -Wno-unknown-pragmas -Wno-reorder -Wno-attributes -std=c++0x -fdeprecated-macro -fdebug-compilation-dir /Projects/REST/rest_proto/build_analysis/src -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -analyzer-checker alpha.core.BoolAssignment -analyzer-checker alpha.core.CastSize -analyzer-checker alpha.core.CastToStruct -analyzer-checker alpha.core.FixedAddr -analyzer-checker alpha.core.PointerArithm -analyzer-checker alpha.core.PointerSub -analyzer-checker alpha.core.SizeofPtr -analyzer-checker alpha.cplusplus.NewDeleteLeaks -analyzer-checker alpha.cplusplus.VirtualCall -analyzer-checker alpha.deadcode.UnreachableCode -analyzer-checker alpha.security.ArrayBoundV2 -analyzer-checker alpha.security.MallocOverflow -analyzer-checker alpha.security.ReturnPtrRange -analyzer-checker alpha.security.taint.TaintPropagation -analyzer-checker alpha.unix.Chroot -analyzer-checker alpha.unix.MallocWithAnnotations -analyzer-checker alpha.unix.PthreadLock -analyzer-checker alpha.unix.SimpleStream -analyzer-checker alpha.unix.Stream -analyzer-checker alpha.unix.cstring.BufferOverlap -analyzer-checker alpha.unix.cstring.NotNullTerminated -analyzer-checker alpha.unix.cstring.OutOfBounds -analyzer-output=html -o /tmp/scan-build-2014-03-31-124858-4118-1 -x c++ /Projects/REST/rest_proto/src/snmp/snmp_interface.cpp 1. parser at end of file 2. While analyzing stack: #0 pointer allocate(size_type __n, const void *) #1 pointer _M_allocate(size_t __n) #2 void _M_emplace_back_aux(const std::vector > &&__args) #3 void push_back(const value_type &__x) #4 void send_walktable_request(const Snmp_pp::Oid &oid_table, const OidVector &oid_list, std::vector &vb_reply_list, boost::system::error_code &ec) 3. /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/ext/new_allocator.h:104:9: Error evaluating statement 4. /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/ext/new_allocator.h:104:9: Error evaluating statement In file included from /Projects/REST/rest_proto/src/net/connection_impl.cpp:1: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/iostream:39: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/ostream:38: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/ios:40: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/bits/char_traits.h:39: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/bits/stl_algobase.h:66: /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/bits/stl_iterator_base_funcs.h:156:11: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption __i += __n; ^~ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 05:41:04 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 12:41:04 +0000 Subject: [LLVMbugs] [Bug 19323] New: abort in static analysis Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19323 Bug ID: 19323 Summary: abort in static analysis Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: apostolos_1 at hotmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12333 --> http://llvm.org/bugs/attachment.cgi?id=12333&action=edit abort log clang version from git master: * dc5af2d - (HEAD, origin/master, origin/HEAD, master) Added _rdtsc intrinsics by Robert Khasanov (3 days ago) Please check the attached log. Sorry, but I can't upload the original file, due to company policy. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 07:49:36 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 14:49:36 +0000 Subject: [LLVMbugs] [Bug 19323] abort in static analysis In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19323 jonathan.sauer at gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jonathan.sauer at gmx.de Resolution|--- |DUPLICATE --- Comment #1 from jonathan.sauer at gmx.de --- This bug seems to have been created in error. I moved the log to bug 19322 where it seems to belong (it's identical to the log posted in the description there). I'm closing this bug as duplicate; if you disagree, please feel free to reopen. *** This bug has been marked as a duplicate of bug 19322 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 08:42:36 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 15:42:36 +0000 Subject: [LLVMbugs] [Bug 19326] New: PowerPC: invalid code generation at -O2 due to bad ordering of instructions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19326 Bug ID: 19326 Summary: PowerPC: invalid code generation at -O2 due to bad ordering of instructions Product: clang Version: 3.4 Hardware: Other OS: Linux Status: NEW Severity: release blocker Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: andyg1001 at hotmail.co.uk CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The problem I am observing is in the following snippet, where with optimisation level 2 switch on, the code inside the if block executes even if maxLength is 0: GuiTextField::GuiTextField(int maxLength) : base(), valid(true) { asm volatile(".marker1":::"memory"); if (maxLength > 0x1234) // testing; was > 0) { asm volatile(".marker2":::"memory"); printf("hmm %i %i\n", maxLength, maxLength > 0); this->SetMaxLength(maxLength); } asm volatile(".marker3":::"memory"); } Here is example output from code compiled at -O2: hmm 0 1 I am afraid that I have been unable to reduce a test-case out of this code (having spent maybe 6 hours on it today!), but hopefully the outputs below can help highlight the problem. Here is the assembly between marker1 and marker3 when compiling with -O0 for PowerPC (targetting 603e): #APP .marker1 #NO_APP lwz 3, 68(31) cmpwi 0, 3, 4661 blt 0, .LBB0_9 b .LBB0_2 .LBB0_2: #APP .marker2 #NO_APP lwz 3, 68(31) lis 4, .L.str at ha .Ltmp3: li 5, 0 li 6, 1 cmpwi 0, 3, 0 la 4, .L.str at l(4) stw 3, 32(31) stw 6, 28(31) stw 5, 24(31) stw 4, 20(31) bgt 0, .LBB0_4 lwz 3, 24(31) stw 3, 28(31) .LBB0_4: lwz 3, 28(31) lwz 4, 20(31) stw 3, 16(31) mr 3, 4 lwz 4, 32(31) lwz 5, 16(31) crxor 6, 6, 6 bl printf .Ltmp4: stw 3, 12(31) b .LBB0_5 .LBB0_5: lwz 4, 68(31) .Ltmp5: lwz 3, 48(31) bl _ZN17GuiEntryFieldBase12SetMaxLengthEi .Ltmp6: b .LBB0_6 .LBB0_6: b .LBB0_9 .LBB0_7: .Ltmp2: stw 3, 64(31) stw 4, 60(31) b .LBB0_10 .LBB0_8: .Ltmp7: stw 3, 64(31) stw 4, 60(31) lwz 3, 44(31) bl _ZN7QStringD2Ev b .LBB0_10 .LBB0_9: #APP .marker3 #NO_APP And here is the same but at -O1 (note that the cmpwi has moved relative to marker1 even though the marker1 declaration should prevent this, but the code still runs correctly in this case): cmpwi 0, 29, 4661 stb 3, 56(30) #APP .marker1 #NO_APP blt 0, .LBB0_2 lis 3, .L.str at ha mr 4, 29 li 5, 1 crxor 6, 6, 6 #APP .marker2 #NO_APP la 3, .L.str at l(3) bl printf .Ltmp0: mr 3, 30 mr 4, 29 bl _ZN17GuiEntryFieldBase12SetMaxLengthEi .Ltmp1: .LBB0_2: lwz 30, 24(31) lwz 29, 20(31) lwz 28, 16(31) #APP .marker3 #NO_APP And then at -O2 (by which point the cmpwi is miles away from its corresponding blt and the code inside the if block executes even though the condition is not met -- I expect corrupted by the lwarx/stwcx that is part of Qt's atomics operations): cmpwi 0, 29, 4661 la 3, _ZTV17GuiTextInputField at l(3) la 12, _ZN7QString11shared_nullE at l(5) addi 4, 3, 8 addi 3, 3, 368 stw 4, 0(30) stw 3, 8(30) stw 12, 52(30) li 3, 1 #APP lwarx 5,0, 12 addi 6, 5, 1 stwcx. 6,0, 12 bne- $-12 #NO_APP stb 3, 56(30) #APP .marker1 #NO_APP blt 0, .LBB0_4 lis 3, .L.str at ha mr 4, 29 li 5, 1 crxor 6, 6, 6 #APP .marker2 #NO_APP la 3, .L.str at l(3) bl printf lwz 3, 40(30) lwz 4, 0(3) lwz 4, 12(4) .Ltmp0: mtctr 4 bctrl mr 28, 3 .Ltmp1: lwz 5, 28(28) lis 3, .L.str1 at ha mr 4, 28 mr 6, 29 crxor 6, 6, 6 la 3, .L.str1 at l(3) bl printf stw 29, 28(28) lwz 3, 40(30) lwz 4, 0(3) lwz 4, 12(4) .Ltmp2: mtctr 4 bctrl mr 4, 3 .Ltmp3: lwz 5, 28(4) lis 3, .L.str2 at ha crxor 6, 6, 6 la 3, .L.str2 at l(3) bl printf .LBB0_4: lwz 30, 24(31) lwz 29, 20(31) lwz 28, 16(31) #APP .marker3 #NO_APP Compare the code from gcc 4.6 for ppc603e at -O2: #APP .marker1 #NO_APP cmpwi 7,30,4660 bgt- 7,.L7 #APP .marker3 #NO_APP lwz 0,36(1) lwz 29,20(1) mtlr 0 lwz 30,24(1) lwz 31,28(1) addi 1,1,32 .cfi_remember_state .cfi_def_cfa_offset 0 .cfi_restore 31 .cfi_restore 30 .cfi_restore 29 blr .L7: .cfi_restore_state #APP .marker2 #NO_APP lis 4,.LC0 at ha li 3,1 la 4,.LC0 at l(4) mr 5,30 li 6,1 .LEHB1: crxor 6,6,6 bl __printf_chk ... And here is the same code for x86_64 compiled by clang (note that the code works correctly here): #APP .marker1 #NO_APP cmpl $4661, %ebp # imm = 0x1235 jl .LBB0_4 # BB#1: # %invoke.cont5 #APP .marker2 #NO_APP movl $.L.str, %edi movl $1, %edx xorl %eax, %eax movl %ebp, %esi callq printf movq 80(%r14), %rdi movq (%rdi), %rax movq 24(%rax), %rax .Ltmp0: callq *%rax movq %rax, %rbx .Ltmp1: # BB#2: # %call.i.i.noexc movl 52(%rbx), %edx movl $.L.str1, %edi xorl %eax, %eax movq %rbx, %rsi movl %ebp, %ecx callq printf movl %ebp, 52(%rbx) movq 80(%r14), %rdi movq (%rdi), %rax movq 24(%rax), %rax .Ltmp2: callq *%rax movq %rax, %rcx .Ltmp3: # BB#3: # %_ZN17GuiEntryFieldBase12SetMaxLengthEi.exit movl 52(%rcx), %edx movl $.L.str2, %edi xorl %eax, %eax movq %rcx, %rsi callq printf .LBB0_4: # %if.end #APP .marker3 #NO_APP In case it is useful, here is the code for the Qt atomic function called in this example: inline bool QBasicAtomicInt::ref() { register int originalValue; register int newValue; asm volatile("lwarx %[originalValue]," _Q_VALUE "\n" "addi %[newValue], %[originalValue], %[one]\n" "stwcx. %[newValue]," _Q_VALUE "\n" "bne- $-12\n" : [originalValue] "=&b" (originalValue), [newValue] "=&r" (newValue), _Q_VALUE_MEMORY_OPERAND : _Q_VALUE_REGISTER_OPERAND [one] "i" (1) : "cc", "memory"); return newValue != 0; } If I were to hazard a guess, I would say that the PowerPC back-end is not taking due care of the asm constraints. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 08:50:21 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 15:50:21 +0000 Subject: [LLVMbugs] [Bug 19294] [ARM64] Cannot select: 0x5378c60: i32 = rotr 0x535df10, 0x535dbf8 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19294 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Chad Rosier --- Thanks, Tim! I'll try to verify the fix once I have the resources. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 08:52:10 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 15:52:10 +0000 Subject: [LLVMbugs] [Bug 19314] [ARM64] Use of __sincos_stret on non-Darwin platforms. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19314 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |mcrosier at codeaurora.org Resolution|FIXED |--- --- Comment #2 from Chad Rosier --- Thanks, Tim! I'll verify shortly. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 10:56:45 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 17:56:45 +0000 Subject: [LLVMbugs] [Bug 19270] Check address space when optimizing gep+cast In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19270 Jingyue Wu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jingyue Wu --- Fixed in r205547. The fixing patch is different from what I proposed here. Instead of disabling the optimization, we create extra addrspacecasts to make sure the type matches. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 11:21:02 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 18:21:02 +0000 Subject: [LLVMbugs] [Bug 19327] New: Forward -ON to the linker Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19327 Bug ID: 19327 Summary: Forward -ON to the linker Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified At least gold has a -O option, but I don't thing it gets used very often since people normally link with "clang -O2" not "clang -Wl,-O2". I tried adding -O2 to the link line and it reduces the clang binary from 58623800 bytes to 57788424 bytes. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 11:32:57 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 18:32:57 +0000 Subject: [LLVMbugs] [Bug 16615] false positive: static analyzer does not detect full case In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=16615 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jordan Rose --- *** This bug has been marked as a duplicate of bug 13027 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 11:34:16 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 18:34:16 +0000 Subject: [LLVMbugs] [Bug 19046] false positive: Assigned value is garbage or unassigned In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19046 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jordan Rose --- Unfortunately, the analyzer doesn't currently handle bitwise constraints...you'll have to use some kind of flag to assert that you handled this already. Or move the one if inside the other, like the 'R' case already is. *** This bug has been marked as a duplicate of bug 3098 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 11:39:27 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 18:39:27 +0000 Subject: [LLVMbugs] [Bug 10199] Static analyzer fails to track path invariants involving bitmasks. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=10199 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jordan_rose at apple.com Resolution|--- |DUPLICATE --- Comment #1 from Jordan Rose --- *** This bug has been marked as a duplicate of bug 3098 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 12:45:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 03 Apr 2014 19:45:49 +0000 Subject: [LLVMbugs] [Bug 19328] New: Message 'argument unused during compilation' emitting while linking Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19328 Bug ID: 19328 Summary: Message 'argument unused during compilation' emitting while linking Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangbugs at nondot.org Reporter: steveire at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified $ clang -c -Xclang -fixit-recompile -fPIC empty.cpp $ clang -shared -o somelib.so -Xclang -fixit-recompile empty.o clang: warning: argument unused during compilation: '-Xclang -fixit-recompile $ clang --version Ubuntu clang version 3.5.0-1~exp1 (trunk) (based on LLVM 3.5.0) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 18:05:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 01:05:30 +0000 Subject: [LLVMbugs] [Bug 19329] New: UNREACHABLE executed at MCFixup.cpp:17 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19329 Bug ID: 19329 Summary: UNREACHABLE executed at MCFixup.cpp:17 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedbugs at nondot.org Reporter: ryan.osial at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12335 --> http://llvm.org/bugs/attachment.cgi?id=12335&action=edit test case On Machine: Linux 3.14.0-gentoo x86_64 Intel(R) Core(TM) i5-3570K Compiled with gcc (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3 $ clang tmp-invert_limb.s unsupported UNREACHABLE executed at /home/ryan/projects/llvm/lib/MC/MCFixup.cpp:17! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 19:09:32 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 02:09:32 +0000 Subject: [LLVMbugs] [Bug 19330] New: __builtin_setjmp with jmp_buf in a struct causes `fatal error in backend' or segmentation fault Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19330 Bug ID: 19330 Summary: __builtin_setjmp with jmp_buf in a struct causes `fatal error in backend' or segmentation fault Product: clang Version: 3.4 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: nobu at ruby-lang.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12337 --> http://llvm.org/bugs/attachment.cgi?id=12337&action=edit minimal code to reproduce the error Compiling the attached source with `-O', clang aborts with fatal error, linker error, or segmentation fault. On MacOS X: $ clang -v Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix $ clang -arch x86_64 -O -c clang_bug.c clang_bug.c:11:29: warning: incompatible pointer types passing 'jmp_buf' (aka 'int [37]') to parameter of type 'void **' [-Wincompatible-pointer-types] (void)(__builtin_setjmp(tag.buf) ? 1 : 0); ^~~~~~~ fatal error: error in backend: unsupported relocation of undefined symbol 'LBB0_-1' $ clang -arch i386 -O -c clang_bug.c clang_bug.c:11:29: warning: incompatible pointer types passing 'jmp_buf' (aka 'int [18]') to parameter of type 'void **' [-Wincompatible-pointer-types] (void)(__builtin_setjmp(tag.buf) ? 1 : 0); ^~~~~~~ Stack dump: 0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple i386-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name clang_bug.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -target-cpu yonah -target-linker-version 236.3 -coverage-file /Users/nobu/src/ruby/trunk/src/clang_bug.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -O2 -fdebug-compilation-dir /Users/nobu/src/ruby/trunk/src -ferror-limit 19 -fmessage-length 238 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-fragile-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o clang_bug.o -x c clang_bug.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'clang_bug.c'. 4. Running pass 'Machine Common Subexpression Elimination' on function '@jump' clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: i386-apple-darwin13.1.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/k_/fqcsxh9x35j1f9q463bj01zw0000gn/T/clang_bug-59499f.c clang: note: diagnostic msg: /var/folders/k_/fqcsxh9x35j1f9q463bj01zw0000gn/T/clang_bug-59499f.sh clang: note: diagnostic msg: ******************** On x86_64-linux clang 34 and FreeBSD clang 3.3: test.c:10:27: warning: incompatible pointer types passing 'jmp_buf' (aka 'struct __jmp_buf_tag [1]') to parameter of type 'void **' [-Wincompatible-pointer-types] (void)(__builtin_setjmp(tag.buf) ? 1 : 0); ^~~~~~~ 1 warning generated. /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/test-11ca81.o: In function `jump': test.c:(.text+0x26): undefined reference to `.LBB0_-1' clang: error: linker command failed with exit code 1 (use -v to see invocation) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 19:31:09 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 02:31:09 +0000 Subject: [LLVMbugs] [Bug 19331] New: [ARM64] An Assertion failure about INSERT_SUBREG in EmitSubregNode() Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19331 Bug ID: 19331 Summary: [ARM64] An Assertion failure about INSERT_SUBREG in EmitSubregNode() Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Hao.Liu at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case: -------------------------------------------------------------- #include "arm_neon.h" uint64x1_t dotest_insert_subreg(uint64x2_t in0) { return vdup_n_u64(vpaddd_u64(in0)); } -------------------------------------------------------------- To run: clang -O0 --target=arm64-linux-gnu -c test0.c The error message is as following: llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:549: void llvm::InstrEmitter::EmitSubregNode(llvm::SDNode*, llvm::DenseMap&, bool, bool): Assertion `SRC && "No register class supports VT and SubIdx for INSERT_SUBREG"' failed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 19:57:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 02:57:52 +0000 Subject: [LLVMbugs] [Bug 19332] New: [ARM64] Unrecognized MLA in DAG selection phase Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19332 Bug ID: 19332 Summary: [ARM64] Unrecognized MLA in DAG selection phase Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Hao.Liu at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case test1.c: -------------------------------------------------------------- #include "arm_neon.h" int32x4_t dotest_mla(int32x4_t in0) { return vmlaq_lane_s32(in0, in0, vget_high_s32(in0), 1); } -------------------------------------------------------------- To run under -O0 TO RUN: clang -O0 --target=arm64-linux-gnu -c test1.c The error message is as following: Unrecognized MLA. UNREACHABLE executed at /home/haoliu01/src/always-clean/lib/Target/ARM6/ARM64ISelDAGToDAG.cpp:462! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 20:30:10 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 03:30:10 +0000 Subject: [LLVMbugs] [Bug 18671] Detect dispatch_once_t in per-thread storage. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18671 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jordan_rose at apple.com Resolution|--- |WONTFIX --- Comment #1 from Jordan Rose --- Thread-local storage is something not that many people even know about. I'm not sure we should assume that once-per-thread is any less likely than once-per-process. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 20:42:50 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 03:42:50 +0000 Subject: [LLVMbugs] [Bug 19333] New: LLVM exports too many symbols (on Unix like systems like Linux and Mac) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19333 Bug ID: 19333 Summary: LLVM exports too many symbols (on Unix like systems like Linux and Mac) Product: Build scripts Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Makefiles Assignee: unassignedbugs at nondot.org Reporter: sstewartgallus00 at mylangara.bc.ca CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This doesn't apply to Windows because by default symbols are hidden in DLLs. On Unix like systems like Linux and Mac though there are a bunch of symbols exported that shouldn't be which increase startup time. There is a long and annoying process of marking symbols to export for the libraries but for the executables (which obviously shouldn't export any symbols unless they have a plugin system) the flag -fvisibility=hidden should be a cheap and easy optimization. Note that LLVM does not use runtime type information or exceptions so I believe there shouldn't be very many problems however, according to http://gcc.gnu.org/wiki/Visibility there also some other cases (for example, static data members of templates that can cause this problem). Using #pragma push for one's own code could be one way of quickly accomplishing this. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 21:28:02 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 04:28:02 +0000 Subject: [LLVMbugs] [Bug 19334] New: Segmentation fault in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19334 Bug ID: 19334 Summary: Segmentation fault in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: asolokha at gmx.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang 3.4 segfaults when compiling the following reduced testcase on x86_64: int fc3 = 0; static int xth(int bfy, int nqq) { return bfy + nqq; } static int qd8(short int y80) { static int w41[1][1]; static int v06; int p7c, ed9, o7f; int *j3e = &w41[0][0]; for (p7c = 0; p7c < 6; ++p7c) for (ed9 = 0; ed9 < 6; ++ed9) for (o7f = 0; o7f < 6; ++o7f) y80 = xth((&v06 != j3e) & y80, y80); return y80; } void ade(void) { int *g4e = &fc3; *g4e ^= qd8(1); } % clang -c -O2 -o 42210194.o 42210194.c clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.4 (tags/RELEASE_34/final) Target: x86_64-pc-linux-gnu Thread model: posix clang: 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: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/42210194-fdd77a.c clang: note: diagnostic msg: /tmp/42210194-fdd77a.sh clang: note: diagnostic msg: ******************** Top 6 frames from stack trace: #0 0x00007f9b76fb870c in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) () from /usr/bin/../lib/libLLVM-3.4.so #1 0x00007f9b76fb409f in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #2 0x00007f9b76fb4d15 in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #3 0x00007f9b76fb8711 in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) () from /usr/bin/../lib/libLLVM-3.4.so #4 0x00007f9b76fb409f in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #5 0x00007f9b76fb4d15 in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #6 0x00007f9b76fb8711 in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) () The following 20913 frames are completely identical. And at the beginning there is: #20920 0x00007f9b76fb409f in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #20921 0x00007f9b76fb4d15 in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #20922 0x00007f9b76fb9900 in llvm::SelectionDAGBuilder::visitSExt(llvm::User const&) () from /usr/bin/../lib/libLLVM-3.4.so #20923 0x00007f9b76fb409f in llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #20924 0x00007f9b76fb4d15 in llvm::SelectionDAGBuilder::getValue(llvm::Value const*) () from /usr/bin/../lib/libLLVM-3.4.so #20925 0x00007f9b76fb8727 in llvm::SelectionDAGBuilder::visitBinary(llvm::User const&, unsigned int) () from /usr/bin/../lib/libLLVM-3.4.so #20926 0x00007f9b76fd4c14 in llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) () from /usr/bin/../lib/libLLVM-3.4.so #20927 0x00007f9b76fe5ed1 in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) () from /usr/bin/../lib/libLLVM-3.4.so #20928 0x00007f9b76fe7659 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/bin/../lib/libLLVM-3.4.so #20929 0x00007f9b76fe88a1 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/bin/../lib/libLLVM-3.4.so #20930 0x00007f9b76669da9 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/bin/../lib/libLLVM-3.4.so #20931 0x00007f9b76669e3b in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/bin/../lib/libLLVM-3.4.so #20932 0x00007f9b7666c2e9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/bin/../lib/libLLVM-3.4.so #20933 0x00000000007de14e in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) () #20934 0x00000000007db801 in ?? () #20935 0x0000000000962e33 in clang::ParseAST(clang::Sema&, bool, bool) () #20936 0x000000000066b789 in clang::FrontendAction::Execute() () #20937 0x0000000000649534 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () #20938 0x0000000000631316 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) () #20939 0x000000000062cf38 in cc1_main(char const**, char const**, char const*, void*) () #20940 0x000000000062b5a5 in main () When building w/ -emit-llvm, clang hangs indefinitely instead. Interesting perf top output is: 18.64% libLLVM-3.4.so [.] _ZN4llvm15ValueEnumerator20EnumerateOperandTypeEPKNS_5ValueE 12.07% libLLVM-3.4.so [.] _ZN4llvm15ValueEnumerator13EnumerateTypeEPNS_4TypeE It seems to loop in llvm::ValueEnumerator::EnumerateOperandType(llvm::Value const*). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 3 22:42:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 05:42:52 +0000 Subject: [LLVMbugs] [Bug 19335] New: [ARM64] Assertion failure on type legalization about operand wasn't scalarized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19335 Bug ID: 19335 Summary: [ARM64] Assertion failure on type legalization about operand wasn't scalarized Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Hao.Liu at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case test.c: ------------------------------------------------------------------ #include "arm_neon.h" uint64_t dotests_type_legalizer(int64x1_t in0) { return vget_lane_u64(vorn_u64(vcgez_s64(in0), in0), 0); } ------------------------------------------------------------------ To RUN: clang -O3 --target=arm64-linux-gnu -c test.c The Error information is as following: /lib/CodeGen/SelectionDAG/LegalizeTypes.h:506: llvm::SDValue llvm::DAGTypeLegalizer::GetScalarizedVector(llvm::SDValue): Assertion `ScalarizedOp.getNode() && "Operand wasn't scalarized?"' failed. AArch64 backend once also had such assertion failure. It was fixed in the backend http://llvm.org/viewvc/llvm-project?view=revision&revision=201381. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 00:37:22 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 07:37:22 +0000 Subject: [LLVMbugs] [Bug 19336] New: Delinearization fails when loop indexes are in reverse order Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19336 Bug ID: 19336 Summary: Delinearization fails when loop indexes are in reverse order Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: tobias at grosser.es CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12342 --> http://llvm.org/bugs/attachment.cgi?id=12342&action=edit Reduced test case We can sucessfully delinearize this piece of code: A[][dim_size]; for (i = 0; i < n; i++)_ for (j = 0; j < n; j++) A[i][j] AddRec: {{%A,+,(4 * %dim_size)}<%loop.i>,+,4}<%loop.j> Base offset: %A ArrayDecl[UnknownSize][%dim_size] with elements of 4 bytes. ArrayRef[{0,+,1}<%loop.i>][{0,+,1}<%loop.j>] but fail for: A[][dim_size]; for (i = 0; i < n; i++)_ for (j = 0; j < n; j++) A[j][i] AddRec: {{%A,+,4}<%loop.i>,+,(4 * %dim_size)}<%loop.j> Base offset: %A ArrayDecl[UnknownSize][1] with elements of 4 bytes. ArrayRef[{0,+,1}<%loop.i>][{0,+,%dim_size}<%loop.j>] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 01:40:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 08:40:55 +0000 Subject: [LLVMbugs] [Bug 19337] New: Assert: illegal float point comparison Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19337 Bug ID: 19337 Summary: Assert: illegal float point comparison Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: spam at drgonzo.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Analyzing the following program using the pre-built 'checker-276' available for Mac OS X causes an assertion failure (Mac OS X 10.6.8 on a MacBook 1,1): int main() { float a = 0.5f; float b = (0.05 > a) ? 0.0f : 1.0f; return 0; } The assertion failure is: Assertion failed: (order < 0 && "illegal float comparison"), function handleFloatConversion, file /Volumes/Data/Users/kremenek/checker-build/checker-build/checker-276-src/tools/clang/lib/Sema/SemaExpr.cpp, line 1057. 0 clang++ 0x0066dd04 PrintStackTraceSignalHandler(void*) + 36 1 clang++ 0x0066e180 SignalHandler(int) + 480 2 libSystem.B.dylib 0x99ca205b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1714806735 4 clang++ 0x0066da0b abort + 27 5 clang++ 0x0066d9f0 abort + 0 6 clang++ 0x01447f9a clang::Sema::UsualArithmeticConversions(clang::ActionResult&, clang::ActionResult&, bool) + 3546 7 clang++ 0x014667c7 clang::Sema::CheckCompareOperands(clang::ActionResult&, clang::ActionResult&, clang::SourceLocation, unsigned int, bool) + 5111 8 clang++ 0x0146c326 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 1174 9 clang++ 0x0146eace clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 1566 10 clang++ 0x01446fd6 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 4534 11 clang++ 0x01135ff4 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 4948 12 clang++ 0x01134c7b clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 203 13 clang++ 0x01140018 clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool, bool, clang::OpaquePtr&, clang::SourceLocation&) + 3000 14 clang++ 0x011396af clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) + 4063 15 clang++ 0x01134c2d clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 125 16 clang++ 0x0111875a clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 3482 17 clang++ 0x011169b5 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1733 18 clang++ 0x0110fb7f clang::Parser::ParseSimpleDeclaration(llvm::SmallVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) + 735 19 clang++ 0x0110f6a3 clang::Parser::ParseDeclaration(llvm::SmallVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 1059 20 clang++ 0x01168409 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 6841 21 clang++ 0x01166896 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) + 214 22 clang++ 0x011700a9 clang::Parser::ParseCompoundStatementBody(bool) + 2185 23 clang++ 0x0117181b clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 187 24 clang++ 0x011833db clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) + 4859 25 clang++ 0x0111689e clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1454 26 clang++ 0x01181ab4 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 1044 27 clang++ 0x0118129d clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 285 28 clang++ 0x0117ff66 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 4662 29 clang++ 0x0117ec59 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 521 30 clang++ 0x011024a7 clang::ParseAST(clang::Sema&, bool, bool) + 7111 31 clang++ 0x008a4b11 clang::ASTFrontendAction::ExecuteAction() + 145 32 clang++ 0x008a43d8 clang::FrontendAction::Execute() + 104 33 clang++ 0x008788df clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 943 34 clang++ 0x008d3231 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 7953 35 clang++ 0x00006011 main + 8129 36 clang++ 0x00003535 start + 53 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 01:50:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 08:50:06 +0000 Subject: [LLVMbugs] [Bug 19338] New: False positive: reinterpret_cast<*> garbage or undefined assignment Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19338 Bug ID: 19338 Summary: False positive: reinterpret_cast<*> garbage or undefined assignment Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kremenek at apple.com Reporter: spam at drgonzo.nl CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Analyzing the following program using the pre-built 'checker-276' available for Mac OS X causes a false positive (Mac OS X 10.6.8 on a MacBook 1,1): #include #include int main() { uint32_t payload[2]; payload[0] = htonl(0x01); payload[1] = htonl(0x01); uint8_t* bytes = new uint8_t[9]; bytes[0] = 0x11; uint8_t* payloadBytes = reinterpret_cast(payload); for (size_t i = 0; i < 8; i++) { bytes[1 + i] = payloadBytes[i]; } return 0; } The analyzer warning is: test.cpp:14:16: warning: Assigned value is garbage or undefined bytes[1 + i] = payloadBytes[i]; ^ ~~~~~~~~~~~~~~~ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 02:03:25 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 09:03:25 +0000 Subject: [LLVMbugs] [Bug 19332] [ARM64] Unrecognized MLA in DAG selection phase In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19332 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tim Northover --- This should be fixed in r205615. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 02:03:44 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 09:03:44 +0000 Subject: [LLVMbugs] [Bug 19331] [ARM64] An Assertion failure about INSERT_SUBREG in EmitSubregNode() In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19331 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tim Northover --- These should be fixed in r205616. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 02:30:19 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 09:30:19 +0000 Subject: [LLVMbugs] [Bug 19339] New: generalized lambda capture in uniform initialization failed to compile Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19339 Bug ID: 19339 Summary: generalized lambda capture in uniform initialization failed to compile Product: clang Version: trunk Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++1y Assignee: unassignedclangbugs at nondot.org Reporter: xlchen1291 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified #include #include struct Foo { template Foo(T) {} }; void bar() { std::vector vec; auto func = [vec{std::move(vec)}] () { }; Foo f1 { func}; // compile Foo f2 { [vec] () { } }; // compile Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile } int main() { } ---------------------------- clang++ -std=c++1y -O2 -Wall -pedantic -pthread main.cpp main.cpp:15:18: error: expected ']' Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile ^ main.cpp:15:14: note: to match this '[' Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile ^ main.cpp:15:36: warning: use of GNU 'missing =' extension in designator [-Wgnu-designator] Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile ^ = main.cpp:15:37: error: expected expression Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile ^ main.cpp:15:15: error: integral constant expression must have integral or unscoped enumeration type, not 'std::vector' Foo f3 { [vec{std::move(vec)}] () {} }; // failed to compile ^~~ 1 warning and 3 errors generated. --------------- clang version 3.5 (trunk 198621) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 03:35:05 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 10:35:05 +0000 Subject: [LLVMbugs] [Bug 19340] New: Crash when parsing specific template specialization code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19340 Bug ID: 19340 Summary: Crash when parsing specific template specialization code Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: lukas.kalbertodt at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12344 --> http://llvm.org/bugs/attachment.cgi?id=12344&action=edit Terminal output + two generated files clang++ crashes, when it parses the following code: template struct Helper { template static void func(const T* m) { } }; template void Helper::func<2>() { } Regardless of the correctness of the code, I guess a crash should not occur. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 05:15:14 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 12:15:14 +0000 Subject: [LLVMbugs] [Bug 19341] New: enabling debuginfo with -g causes an undefined reference error at link time Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19341 Bug ID: 19341 Summary: enabling debuginfo with -g causes an undefined reference error at link time Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: greg_bedwell at sn.scee.net CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The testcase below links correctly when built without -g specified, but fails with undefined reference errors with -g: $ clang -v clang version 3.5.0 (205622) Target: x86_64-unknown-linux-gnu Thread model: posix 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.3 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.2 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Candidate multilib: .;@m64 Selected multilib: .;@m64 $ clang 1.cpp $ clang 1.cpp -g /tmp/1-812f49.o:(.debug_info+0x91): undefined reference to `Bravo::charlie' /tmp/1-812f49.o:(.debug_info+0xf2): undefined reference to `alpha()' clang-3.5: error: linker command failed with exit code 1 (use -v to see invocation) // ========================================== extern char alpha(); struct Bravo { static int charlie; }; template struct Echo { int foxtrot() { return 1; }; }; template <> struct Echo { int foxtrot() { return 100; }; }; template struct Golf { int foxtrot() { return 1000; }; }; template <> struct Golf<&Bravo::charlie> { int foxtrot() { return 10000; }; }; int main() { Echo hotel; Golf<&Bravo::charlie> india; return hotel.foxtrot() + india.foxtrot(); } // ========================================== I've bisected the error and can see that the testcase links successfully at r181631, but with r181634 it fails with an undefined reference to 'Bravo::charlie'. At r181685 we also start seeing the undefined reference to 'alpha()'. Here are the relevant revisions: ----------------------------------------------- http://llvm.org/viewvc/llvm-project?view=revision&revision=181632 PR14492: Debug Info: Support for values of non-integer non-type template parameters. This is only tested for global variables at the moment (& includes tests for the unnamed parameter case, since apparently this entire function was completely untested previously) ----------------------------------------------- ----------------------------------------------- http://llvm.org/viewvc/llvm-project?view=revision&revision=181634 PR14992: Debug Info: Support more non-type template parameters * Provide DW_TAG_template_value_parameter for pointers, function pointers, member pointers, and member function pointers (still missing support for template template parameters which GCC encodes as a DW_TAG_GNU_template_template_param) * Provide values for all but the (member & non-member) function pointer case. Simple constant integer values for member pointers (offset within the object) and address for the value pointer case. GCC doesn't provide a value for the member function pointer case so I'm not sure how, if at all, GDB supports encoding that. & non-member function pointers should follow shortly in a subsequent patch. * Null pointer value encodings of all of these types, including correctly encoding null data member pointers as -1. ----------------------------------------------- ----------------------------------------------- http://llvm.org/viewvc/llvm-project?view=revision&revision=181685 Debug Info: PR14992: Support values for non-type template parameters of function type ----------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 07:13:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 14:13:06 +0000 Subject: [LLVMbugs] [Bug 19261] unconditional branch is not generated with -O0 -fast-isel=false In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19261 Daniil Fukalov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Daniil Fukalov --- fixed in r205529 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 07:41:07 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 14:41:07 +0000 Subject: [LLVMbugs] [Bug 19294] [ARM64] Cannot select: 0x5378c60: i32 = rotr 0x535df10, 0x535dbf8 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19294 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 07:41:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 14:41:30 +0000 Subject: [LLVMbugs] [Bug 19314] [ARM64] Use of __sincos_stret on non-Darwin platforms. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19314 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 08:39:27 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 15:39:27 +0000 Subject: [LLVMbugs] [Bug 19326] PowerPC: invalid code generation at -O2 due to bad ordering of instructions In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19326 Hal Finkel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hal Finkel --- Fixed in r205630. Thanks for the report and working on the reduction! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 08:59:37 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 15:59:37 +0000 Subject: [LLVMbugs] [Bug 19338] False positive: reinterpret_cast<*> garbage or undefined assignment In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19338 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jordan_rose at apple.com Resolution|--- |DUPLICATE --- Comment #1 from Jordan Rose --- Yeah, the analyzer doesn't handle reinterpret_cast very well. Workaround: use memcpy. *** This bug has been marked as a duplicate of bug 9930 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 09:12:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 16:12:28 +0000 Subject: [LLVMbugs] [Bug 17668] Incorrect dereference warning even after direct NULL check In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17668 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jordan Rose --- Yes, this is fixed in checker-276. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 09:42:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 16:42:30 +0000 Subject: [LLVMbugs] [Bug 19335] [ARM64] Assertion failure on type legalization about operand wasn't scalarized In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19335 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 10:41:27 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 17:41:27 +0000 Subject: [LLVMbugs] [Bug 19344] New: constexpr constructor incorrectly rejected due to base class of non-literal type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19344 Bug ID: 19344 Summary: constexpr constructor incorrectly rejected due to base class of non-literal type Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: zilla at kayari.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified struct base { constexpr base() { } ~base() { } }; struct derived : base { constexpr derived() { } }; a.cc:8:13: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] constexpr derived() { } ^ a.cc:8:13: note: non-literal type 'base' cannot be used in a constant expression 1 error generated. I think clang is too strict here, I don't see where the standard requires all base classes to have literal type for a constexpr constructor. If derived::derived() is defined as defaulted the code is accepted, which is inconsistent with the diagnostic because the base class is still non-literal. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 11:18:35 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 18:18:35 +0000 Subject: [LLVMbugs] [Bug 19345] New: [ARM64] Miscompile/miscompare of SPEC2000 benchmarks Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19345 Bug ID: 19345 Summary: [ARM64] Miscompile/miscompare of SPEC2000 benchmarks Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: apazos at codeaurora.org, llvmbugs at cs.uiuc.edu Classification: Unclassified I'm seeing output mismatch in SPEC2000 tests equake and eon with "-O3 -ffast-math –fno-math-errno" and gcc with "-O3 -ffast-math" using llvm/trunk at 205545 and cfe/trunk at 205543. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 11:21:36 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 18:21:36 +0000 Subject: [LLVMbugs] [Bug 19346] New: adding zero to null pointer rejected in constant expressions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19346 Bug ID: 19346 Summary: adding zero to null pointer rejected in constant expressions Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: zilla at kayari.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified constexpr int* p = nullptr; constexpr int n = 0; constexpr int* p2 = p + n; a.cc:3:16: error: constexpr variable 'p2' must be initialized by a constant expression constexpr int* p2 = p + n; ^ ~~~~~ a.cc:3:23: note: cannot perform pointer arithmetic on null pointer constexpr int* p2 = p + n; ^ Th last paragraph of [expr.add] says "If the value 0 is added to or subtracted from a pointer value, the result compares equal to the original pointer value." I believe that should also apply for a null pointer. Rejecting this makes it more awkward to define end() in the code below: struct initializer_list { constexpr initializer_list() : b(nullptr), sz(0) { } constexpr int* begin() const { return b; } constexpr int* end() const { return b+sz; } int* b; unsigned sz; }; constexpr initializer_list il; constexpr int* p = il.end(); -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 13:56:35 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 20:56:35 +0000 Subject: [LLVMbugs] [Bug 19298] DWARF for const integer variables are duplicated in the root scope In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19298 David Blaikie changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Blaikie --- Fixed in r205651. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 4 14:24:40 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 04 Apr 2014 21:24:40 +0000 Subject: [LLVMbugs] [Bug 19348] New: DAGCombiner does not check for legal ExtLoad operation before folding (aext (zextload x)) -> (aext (truncate (*extload x))) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19348 Bug ID: 19348 Summary: DAGCombiner does not check for legal ExtLoad operation before folding (aext (zextload x)) -> (aext (truncate (*extload x))) Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: stanislav.mekhanoshin at amd.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Our custom BE does not support extloads from i8 and i16 right into i64, but there are no legal i8 and i16 types either, only i32 and i64 are legal. So we have custom lowering for such loads which does extload from a sub-dword type to i32 register and then generates extension from i32 to i64. This is the only way the HW can do this is fact. The DAGCombiner detects double extension and folds it back to a single extending load from a sub-dword to i64, which is marked by BE as custom, not legal. This results in "cannot select" error. Custom lowering is not called anymore after the legalization (if it does that would incur an endless loop, I suppose). The working solution is to check in DAGCombiner if a requested ext load operation is legal and do not perform optimization if it is not. Both zext and sext cases are guarded with such check, but not aext. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 5 10:35:26 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 05 Apr 2014 17:35:26 +0000 Subject: [LLVMbugs] [Bug 19349] New: segmentation fault durin compilation Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19349 Bug ID: 19349 Summary: segmentation fault durin compilation Product: clang Version: 3.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: socketpair at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12346 --> http://llvm.org/bugs/attachment.cgi?id=12346&action=edit clang error log Ubuntu LTS 12.04 =================== class Real { public: void qwe(void) {} }; int main(void) { Real *t = new Real(); auto zzz = [=]() { t->qwe(); } zzz(); } =================== clang -std=c++11 bug.cpp -lstdc++ =================== error log attached. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 5 23:30:44 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 06 Apr 2014 06:30:44 +0000 Subject: [LLVMbugs] [Bug 19349] segmentation fault durin compilation In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19349 jonathan.sauer at gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jonathan.sauer at gmx.de Resolution|--- |WORKSFORME --- Comment #1 from jonathan.sauer at gmx.de --- After adding a ";" after the lambda function, the code compiles with clang r205174 (3.5 trunk) as well as Apple's clang-500.2.79 (based on clang 3.3). Clang 3.0 is very old and didn't have complete support for C++11 yet (I'm fairly sure it didn't support lambda functions at all). I'm closing this bug as the crash doesn't happen anymore with a current version. Please feel free to reopen if you disagree, though. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sun Apr 6 22:26:34 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 05:26:34 +0000 Subject: [LLVMbugs] [Bug 19350] New: Cannot use const std::string as key for unordered_multimap: linking error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19350 Bug ID: 19350 Summary: Cannot use const std::string as key for unordered_multimap: linking error Product: clang Version: 3.3 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: socketpair at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified -DOK : error during linking without -DOK: success If I remove 'const' before std::string, both compiled successfully. Exactly the same with gcc 4.6 :( bug in my head? =============================== #include #ifdef OK #include typedef std::unordered_multimap Eventmap; #else #include typedef std::multimap Eventmap; #endif int main(void) { Eventmap eventmap; eventmap.insert(Eventmap::value_type("answer", 42)); return 0; } =============================== $ clang++ bug.cpp -std=c++11 -Wall -Wextra -O3 -DOK /tmp/bug-MKvQXI.o: In function `std::__detail::_Hashtable_iterator, false, false> std::_Hashtable, std::allocator >, std::_Select1st >, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, false, false, false>::_M_insert >(std::pair&&, std::integral_constant)': bug.cpp:(.text._ZNSt10_HashtableIKSsSt4pairIS0_iESaIS2_ESt10_Select1stIS2_ESt8equal_toIS0_ESt4hashIS0_ENSt8__detail18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyELb0ELb0ELb0EE9_M_insertIS2_EENSA_19_Hashtable_iteratorIS2_Lb0ELb0EEEOT_St17integral_constantIbLb0EE[_ZNSt10_HashtableIKSsSt4pairIS0_iESaIS2_ESt10_Select1stIS2_ESt8equal_toIS0_ESt4hashIS0_ENSt8__detail18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyELb0ELb0ELb0EE9_M_insertIS2_EENSA_19_Hashtable_iteratorIS2_Lb0ELb0EEEOT_St17integral_constantIbLb0EE]+0x1ba): undefined reference to `std::hash::operator()(std::string) const' /tmp/bug-MKvQXI.o: In function `std::_Hashtable, std::allocator >, std::_Select1st >, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, false, false, false>::_M_rehash(unsigned long)': bug.cpp:(.text._ZNSt10_HashtableIKSsSt4pairIS0_iESaIS2_ESt10_Select1stIS2_ESt8equal_toIS0_ESt4hashIS0_ENSt8__detail18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyELb0ELb0ELb0EE9_M_rehashEm[_ZNSt10_HashtableIKSsSt4pairIS0_iESaIS2_ESt10_Select1stIS2_ESt8equal_toIS0_ESt4hashIS0_ENSt8__detail18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyELb0ELb0ELb0EE9_M_rehashEm]+0x134): undefined reference to `std::hash::operator()(std::string) const' clang: error: linker command failed with exit code 1 (use -v to see invocation) ============================= $ clang --version Ubuntu clang version 3.3-5ubuntu4~precise1 (branches/release_33) (based on LLVM 3.3) Target: x86_64-pc-linux-gnu Thread model: posix ============================= -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 01:16:26 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 08:16:26 +0000 Subject: [LLVMbugs] [Bug 19351] New: Clang/LLVM 3.4 can't compile Neovim anymove: Assertion failed: (found && "Losing a member during member list replacement") Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19351 Bug ID: 19351 Summary: Clang/LLVM 3.4 can't compile Neovim anymove: Assertion failed: (found && "Losing a member during member list replacement") Product: clang Version: 3.4 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: nicolas at hillegeer.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12350 --> http://llvm.org/bugs/attachment.cgi?id=12350&action=edit error reporting by clang, assertion failed while building event.c I'm not entirely sure if I placed this in the right tracker, someone please move it if it isnt'. First of: since a few commits ago, clang 3.4 no longer compiles the neovim project: https://github.com/neovim/neovim on OSX. Strangely enough, there seem to be no such problems on linux, as the continuous integration (travis) runs both gcc 4.7 and clang 3.4 to test. I've used git bisect to find the offending commit: https://github.com/neovim/neovim/commit/967fb1aca6ea9c3d3046ccd6b9fcf0f88d6999ac I thus suspect it has something to do with klist.h from klib (https://github.com/attractivechaos/klib), which was first used in that commit. After checking out the project, I perform: $ rm -rf build; make all This wil build the dependencies (libuv and luajit) and then start building neovim. I've added the error in an attachment. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 03:05:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 10:05:24 +0000 Subject: [LLVMbugs] [Bug 19352] New: getLocation() points to the wrong position for FriendDecls Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19352 Bug ID: 19352 Summary: getLocation() points to the wrong position for FriendDecls Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: klimek at google.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Locations of friend declarations that are type declarations should point to the declared identifier. struct A {}; A g(); struct B { friend void f(); // getLocation() correctly points to 'f'. friend class X; // getLocation() incorrectly points to 'friend'. // Of course arbitrary type expressions are allowed here, too, in // which case I'd assume it's fine for getLocation() to point to // the start: friend decltype(g()); }; -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 05:14:04 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 12:14:04 +0000 Subject: [LLVMbugs] [Bug 19353] New: Provide easy to inspect vectorization information Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19353 Bug ID: 19353 Summary: Provide easy to inspect vectorization information Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: gonzalobg88 at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified GCC provides -ftree-vectorizer-verbose=x to inspect what the vectorizer is doing. This allows you to see e.g. why the vectorizer is not vectorizing a construct in which you expected vectorization (and to fix it). AFAIK there is no easy way to obtain this information easily with clang. This is thus a feature request. A problem that AFAIK this option has in GCC is that it spits out _a lot_ of information if you use it for your whole program. It would therefore make sense to be able to delimit this information to code snippets using a pragma (e.g. similar to those for pushing/popping warnings). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 05:32:36 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 12:32:36 +0000 Subject: [LLVMbugs] [Bug 14223] Temporary's destructor not called when exception thrown in a called function when compiled with -O2 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14223 Halfdan Ingvarsson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Halfdan Ingvarsson --- This looks fixed in the latest trunk. clang version 3.5.0 (205671) Target: x86_64-unknown-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 06:25:50 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 13:25:50 +0000 Subject: [LLVMbugs] [Bug 18913] [release 3.4] utilities/utility/pairs/pairs.pair/copy_ctor.pass.cpp fails on x86_64-darwin11 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18913 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 06:36:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 13:36:55 +0000 Subject: [LLVMbugs] [Bug 17819] packaged_task cannot be built from an lvalue of function type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17819 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Marshall Clow (home) --- Fixed by revision 205709 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 06:39:25 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 13:39:25 +0000 Subject: [LLVMbugs] [Bug 19115] clang generates 26 times as much instructions as gcc for code with a variable length array In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19115 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Christopher --- Should be fixed in r205710. Thanks for the nice testcase! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 07:23:50 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 14:23:50 +0000 Subject: [LLVMbugs] [Bug 19354] New: failed stream extraction consumes characters after clear (libstdc++ vs libc++) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19354 Bug ID: 19354 Summary: failed stream extraction consumes characters after clear (libstdc++ vs libc++) Product: libc++ Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangbugs at nondot.org Reporter: gellule.xg at gmail.com CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com Classification: Unclassified Thought I would report the following difference between libstdc++ and libc++. For the code below, libc++ reports a position (ss.tellg()) of 3, whereas libstdc++ reports 0. #include #include int main() { std::stringstream ss; double f; ss << "abc"; ss >> f; if(ss.fail()) { std::cout << "Failed!" << std::endl; ss.clear(); } std::cout << "Position: " << ss.tellg() << std::endl; } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 08:31:35 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 15:31:35 +0000 Subject: [LLVMbugs] [Bug 19354] failed stream extraction consumes characters after clear (libstdc++ vs libc++) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19354 Marshall Clow (home) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marshall Clow (home) --- Thanks for the report. I believe that this is a duplicate of http://llvm.org/bugs/show_bug.cgi?id=17782. What's happening here is that libc++ is attempting to parse this as a hex float. [ You have to dig into the C standard to find out about that.. ] If you change the string to "zyx", both libc++ and libstdc++ print 0. I've added your example to that bug. *** This bug has been marked as a duplicate of bug 17782 *** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 09:43:19 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 16:43:19 +0000 Subject: [LLVMbugs] [Bug 19355] New: __GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19355 Bug ID: 19355 Summary: __GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86 Product: clang Version: 3.4 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: gjasny at googlemail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Hello, when compiling the Boost Atomic library I noticed a test case failure which expects that boost::atomic is always lock-free on X86 [1]. This is caused by the fact that clang sets the __GCC_ATOMIC_LLONG_LOCK_FREE to 1. In comparison gcc (4.8) sets this preprocessor symbol to 2: $ gcc --version gcc (Debian 4.8.2-19) 4.8.2 $ gcc -dM -E - -m32 < /dev/null|grep __GCC_ATOMIC_LLONG_LOCK_FREE #define __GCC_ATOMIC_LLONG_LOCK_FREE 2 In contrast: $ clang --version Debian clang version 3.4-2 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix $ clang -dM -E - -m32 < /dev/null|grep __GCC_ATOMIC_LLONG_LOCK_FREE #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 Is this difference a bug? Andrey Semashev stated in the Boost Atomic bug report that Core2 CPUs all should support cmpxchg8b and thus be always completely lock free. Thanks, Gregor [1] See https://svn.boost.org/trac/boost/ticket/9842 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 10:19:50 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 17:19:50 +0000 Subject: [LLVMbugs] [Bug 19356] New: builtin cabs(z) resp. hypot(z) squared should be optimized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19356 Bug ID: 19356 Summary: builtin cabs(z) resp. hypot(z) squared should be optimized Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: mrmocool at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified #include float abs2(std::complex c) { return abs(c) * abs(c); } $ clang++ -mllvm --x86-asm-syntax=intel -std=c++11 -O3 -g -ffast-math -S test.cpp .type bar(std::complex), at function bar(std::complex): # @bar(std::complex) .Lfunc_begin0: # BB#0: # %entry .loc 3 584 0 prologue_end # /usr/include/c++/4.8/complex:584:0 582:/usr/include/c++/4.8/complex **** #if _GLIBCXX_USE_C99_COMPLEX 583:/usr/include/c++/4.8/complex **** inline float 584:/usr/include/c++/4.8/complex **** __complex_abs(__complex__ float __z) { return __builtin_cabsf(__z); } push rax .Ltmp0: .cfi_def_cfa_offset 16 call cabsf .Ltmp1: .loc 1 4 18 # testcomplex.cpp:4:18 mulss xmm0, xmm0 pop rax ret -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 10:20:23 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 17:20:23 +0000 Subject: [LLVMbugs] [Bug 19357] New: cyclic module dependencies can deadlock Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19357 Bug ID: 19357 Summary: cyclic module dependencies can deadlock Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified If module A depends on module B, and module B depends on module A, and we perform a -j2 build where one action builds module A first and the other builds B first, those two build steps can deadlock, because each of them first acquires the lock for the being-built module then tries to wait for the other module's lock. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 10:22:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 17:22:24 +0000 Subject: [LLVMbugs] [Bug 19358] New: module 'conflict' stanza doesn't work across top-level modules Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19358 Bug ID: 19358 Summary: module 'conflict' stanza doesn't work across top-level modules Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangbugs at nondot.org Reporter: richard-llvm at metafoo.co.uk CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Repro: module A {} module B { conflict A } Building B will assert, because it tries to allocate a submodule ID for 'A', which is neither part of the currently-building module nor in a module that it imports. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 13:27:47 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 20:27:47 +0000 Subject: [LLVMbugs] [Bug 19361] New: MS mangler: No mangling for C++11 reference qualified methods Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19361 Bug ID: 19361 Summary: MS mangler: No mangling for C++11 reference qualified methods Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: rnk at google.com CC: llvmbugs at cs.uiuc.edu Blocks: 12477 Classification: Unclassified TIL this program should print "lval ref\nrval ref\n": extern "C" void puts(const char *); struct A { void foo() &; void foo() &&; }; void A::foo() & { puts("lval ref"); } void A::foo() && { puts("rval ref"); } int main() { A a; a.foo(); A().foo(); } MSVC doesn't know how to parse ref-qualified functions, so we don't have any mangling to follow. Clang currently does this: $ clang-cl t.cpp -c t.cpp(9,9) : error: definition with same mangled name as another definition void A::foo() && { ^ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 14:02:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 21:02:52 +0000 Subject: [LLVMbugs] [Bug 19362] New: ARM disassembler ignores negative offset bit for ldrht, ldrsht, strht, and ldrsbt Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19362 Bug ID: 19362 Summary: ARM disassembler ignores negative offset bit for ldrht, ldrsht, strht, and ldrsbt Product: new-bugs Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dpmiller at cmu.edu CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Disassembling ldrht, ldrsht, strht, and ldrsbt with llvm-mc produces instructions without the optional negative sign in front of the optional offset. All offsets are disassembled as a positive offset, regardless of the sign bit. Code to reproduce: $ echo "ldrht r1, [r2], -r3" | llvm-mc -arch=arm -show-inst .text ldrht r1, [r2], -r3 @ @ @ @ @ @ @ > Notice that the Imm is 0. Compare with the disassembly for ldrh in which bit 8 of the immediate is properly set: $ echo "ldrh r1, [r2], -r3" | llvm-mc -arch=arm -show-inst .text ldrh r1, [r2], -r3 @ @ @ @ @ @ @ > -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 14:31:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 07 Apr 2014 21:31:49 +0000 Subject: [LLVMbugs] [Bug 16365] Extremely slow compilation in -O1 and -O2 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=16365 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Trick --- Fixed in r205738. I added a workaround to ClusterNeighboringLoads. time /b/fix/RA/bin/clang++ -O2 -c biggraph.C real 0m6.143s user 0m6.016s sys 0m0.120s -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 17:29:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 00:29:53 +0000 Subject: [LLVMbugs] [Bug 19301] Missing kernel intrinsics In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19301 Reid Kleckner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- Thanks for the patch, I committed it with modifications in r205751. I didn't execute the provided test, but I did compile it successfully. I hope the inline asm constraints are right. :) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 20:18:04 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 03:18:04 +0000 Subject: [LLVMbugs] [Bug 19365] New: Explicit specialization of base inherited constructor: Assertion `Method->isCanonicalDecl() && Overridden->isCanonicalDecl()' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19365 Bug ID: 19365 Summary: Explicit specialization of base inherited constructor: Assertion `Method->isCanonicalDecl() && Overridden->isCanonicalDecl()' failed. Product: clang Version: 3.4 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: hstong at ca.ibm.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified ### REDUCED SOURCE:> cat crashes.cc struct A { template A(T t); }; template <> A::A(int) { } struct B : A { using A::A; }; int main() { B b(42); } Return: 0x00:0 ### COMPILER INVOCATION: > clang++ -std=c++1y crashes.cc ### COMPILER OUTPUT: clang: /build/workdir/llvm-dev.src/tools/clang/lib/AST/ASTContext.cpp:1208: void clang::ASTContext::addOverriddenMethod(const clang::CXXMethodDecl*, const clang::CXXMethodDecl*): Assertion `Method->isCanonicalDecl() && Overridden->isCanonicalDecl()' failed. 0 clang 0x000000001370e64c llvm::sys::PrintStackTrace(_IO_FILE*) + 4273534868 1 clang 0x000000001370e980 2 clang 0x000000001370f230 3 0x00000fffb5dc0418 __kernel_sigtramp_rt64 + 0 4 libc.so.6 0x00000fffb591a038 abort + 4293567448 5 libc.so.6 0x00000fffb590eab8 __assert_fail + 4293526792 6 clang 0x00000000121de834 clang::ASTContext::addOverriddenMethod(clang::CXXMethodDecl const*, clang::CXXMethodDecl const*) + 4253675500 7 clang 0x00000000122ec468 clang::CXXConstructorDecl::setInheritedConstructor(clang::CXXConstructorDecl const*) + 4254681280 8 clang 0x000000001150e058 clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*, bool) + 4241864944 9 clang 0x000000001150eb94 clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*) + 4241867796 10 clang 0x000000001150ec9c clang::TemplateDeclInstantiator::VisitCXXConstructorDecl(clang::CXXConstructorDecl*) + 4241867988 11 clang 0x00000000114f6848 12 clang 0x0000000011503834 clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 4241822548 13 clang 0x0000000011499b3c clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*) + 4241414996 14 clang 0x00000000114a5de8 clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 4241463800 15 clang 0x000000001136b368 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool) + 4240271040 16 clang 0x00000000112d6de4 17 clang 0x00000000112d7394 18 clang 0x00000000112e9304 clang::InitializationSequence::InitializeFrom(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool) + 4239797140 19 clang 0x00000000112e98f4 clang::InitializationSequence::InitializationSequence(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool) + 4239798636 20 clang 0x0000000011060a30 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) + 4237354824 21 clang 0x0000000010eb6d94 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 4235787892 22 clang 0x0000000010ebef30 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 4235820088 23 clang 0x0000000010ec8a70 clang::Parser::ParseSimpleDeclaration(llvm::SmallVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) + 4235859520 24 clang 0x0000000010ec8e8c clang::Parser::ParseDeclaration(llvm::SmallVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 4235860548 25 clang 0x0000000010f2dbbc clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 4236249044 26 clang 0x0000000010f277d8 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) + 4236224048 27 clang 0x0000000010f28170 clang::Parser::ParseCompoundStatementBody(bool) + 4236226456 28 clang 0x0000000010f286f8 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 4236227848 29 clang 0x0000000010ea3fbc clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) + 4235720724 30 clang 0x0000000010ebeba8 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 4235819184 31 clang 0x0000000010e9ea48 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) + 4235699544 32 clang 0x0000000010e9eb1c clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) + 4235699732 33 clang 0x0000000010ea1f6c clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 4235712596 34 clang 0x0000000010ea256c clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 4235714084 35 clang 0x0000000010e988ac clang::ParseAST(clang::Sema&, bool, bool) + 4235685476 36 clang 0x0000000010818624 clang::ASTFrontendAction::ExecuteAction() + 4229756484 37 clang 0x0000000010baec94 clang::CodeGenAction::ExecuteAction() + 4232996092 38 clang 0x0000000010818b60 clang::FrontendAction::Execute() + 4229757464 39 clang 0x00000000107db708 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 4229527256 40 clang 0x0000000010788880 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 4229256424 41 clang 0x0000000010771248 cc1_main(char const**, char const**, char const*, void*) + 4229173584 42 clang 0x0000000010781af0 main + 4229230608 43 libc.so.6 0x00000fffb58ff13c 44 libc.so.6 0x00000fffb58ff34c __libc_start_main + 4293465684 Stack dump: 0. Program arguments: /bin/clang -cc1 -triple powerpc64-unknown-linux-gnu -S -disable-free -main-file-name crashes.cc -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-cpu ppc64 -target-linker-version 11 -resource-dir /bin/../lib/clang/3.4 -internal-isystem /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../include/c++/4.3 -internal-isystem /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../include/c++/4.3/powerpc64-suse-linux -internal-isystem /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../include/c++/4.3/backward -internal-isystem /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../include/powerpc64-suse-linux/c++/4.3 -internal-isystem /usr/local/include -internal-isystem /bin/../lib/clang/3.4/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++1y -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-slp -o /tmp/crashes-94e8e0.s -x c++ crashes.cc 1. crashes.cc:6:21: current parser token ';' 2. crashes.cc:6:12: parsing function body 'main' 3. crashes.cc:6:12: in compound statement ('{}') clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.4 Target: powerpc64-unknown-linux-gnu Thread model: posix clang: 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: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/crashes-ed4ee0.cpp clang: note: diagnostic msg: /tmp/crashes-ed4ee0.sh clang: note: diagnostic msg: ******************** -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 22:58:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 05:58:06 +0000 Subject: [LLVMbugs] [Bug 19366] New: [3.4] no futimes/futimens on solaris (use futimesat instead?) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19366 Bug ID: 19366 Summary: [3.4] no futimes/futimens on solaris (use futimesat instead?) Product: Build scripts Version: 3.4 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: autoconf Assignee: unassignedbugs at nondot.org Reporter: FBergemann at web.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified On Solaris 10 (sparcv9) i get following compilation problem: In file included from /data/FBergemann/SRC2/llvm-release_34/lib/Support/Path.cpp:1035:0: /data/FBergemann/SRC2/llvm-release_34/lib/Support/Unix/Path.inc:540:2: error: #error Missing futimes() and futimens() #error Missing futimes() and futimens() ^ I could at least continue compilation for using futimesat(...) instead - hacked this way: #if defined(HAVE_FUTIMENS) timespec Times[2]; Times[0].tv_sec = Time.toPosixTime(); Times[0].tv_nsec = 0; Times[1] = Times[0]; if (::futimens(FD, Times)) #elif defined(HAVE_FUTIMES) timeval Times[2]; Times[0].tv_sec = Time.toPosixTime(); Times[0].tv_usec = 0; Times[1] = Times[0]; if (::futimes(FD, Times)) #else timeval Times[2]; Times[0].tv_sec = Time.toPosixTime(); Times[0].tv_usec = 0; Times[1] = Times[0]; if (::futimesat(FD, NULL, Times)) #endif Can you check, if you can incorporate futimesat(...) option into the build procedure? - thanks! best regards, Frank -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Mon Apr 7 23:51:00 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 06:51:00 +0000 Subject: [LLVMbugs] [Bug 19367] New: [ARM64] Can not select ARM64ISD::NOT of v1i64 type Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19367 Bug ID: 19367 Summary: [ARM64] Can not select ARM64ISD::NOT of v1i64 type Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: Hao.Liu at arm.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case: ---------------------------------------------------------------- #include "arm_neon.h" uint64x1_t dotest_not_v1i64(uint64x1_t in0, uint64x1_t in1) { return vtst_u64(in0, vcge_u64(in0, in1)); } ---------------------------------------------------------------- The error information is as following: $ clang --target=arm64-linux-gnu -O3 -S dotest_1.c fatal error: error in backend: Cannot select: 0x74030f0: v1i64 = ARM64ISD::NOT 0x7402fe8 [ORD=4] [ID=8] 0x7402fe8: v1i64 = ARM64ISD::CMEQz 0x74027a8 [ORD=4] [ID=6] 0x74027a8: v1i64,ch = CopyFromReg 0x73c60c0, 0x74026a0 [ORD=1] [ID=4] 0x74026a0: v1i64 = Register %vreg0 [ID=1] In function: dotest_not_v1i64 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 05:19:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 12:19:52 +0000 Subject: [LLVMbugs] [Bug 19346] adding zero to null pointer rejected in constant expressions In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19346 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Thanks for the report, fixed in r205757. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 09:48:42 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 16:48:42 +0000 Subject: [LLVMbugs] [Bug 19369] New: Initialization of static cl::opt variables is not thread safe Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19369 Bug ID: 19369 Summary: Initialization of static cl::opt variables is not thread safe Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dnovillo at google.com CC: llvmbugs at cs.uiuc.edu, qcolombet at apple.com Classification: Unclassified This came up during code review. Full thread at: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140331/211991.html In particular, the discussion of the initialization for PassRemarkPattern: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140331/212005.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 10:13:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 17:13:53 +0000 Subject: [LLVMbugs] [Bug 19370] New: [X86] Non-temporal store from _mm_stream_ps is not mapped to movntps in some cases Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19370 Bug ID: 19370 Summary: [X86] Non-temporal store from _mm_stream_ps is not mapped to movntps in some cases Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: dario.domizioli at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12354 --> http://llvm.org/bugs/attachment.cgi?id=12354&action=edit Test case and assembly output We have encountered a situation where non-temporal stores (coming from a _mm_stream_ps intrinsic) are not compiled to movntps, and they are instead producing a standard movaps. In this example this happens when the value to store is a constant. I am attaching a tar.gz file containing: - simplified.cpp - simplified.ll - simplified.s which are, respectively: - the source code - the output of "clang -O2 -S -emit-llvm simplified.cpp -o simplified.ll" - the output of "llc simplified.ll -o simplified.s" The test case is reduced from a larger file, and I have removed things like memory fences after the operations (they don't seem to affect the situation). This is the smallest source I could get to. I am using Linux Ubuntu, the triple is x86_64-unknown-linux-gnu. There are two functions in the code. The first one uses a non-temporal store to copy a value from a global to another. The second one uses a non-temporal store to write a splat of zeroes (created with _mm_set1_ps) into the destination. The first is compiled to this IR: %0 = load <4 x float>* bitcast ([4 x float]* @src to <4 x float>*), align 32, !tbaa !1 store <4 x float> %0, <4 x float>* bitcast ([4 x float]* @dest to <4 x float>*), align 32, !nontemporal !4 ret void And it generates the following asm (stripped): vmovaps src(%rip), %xmm0 vmovntps %xmm0, dest(%rip) retq The second one is compiled to this IR: store <4 x float> zeroinitializer, <4 x float>* bitcast ([4 x float]* @dest to <4 x float>*), align 32, !nontemporal !4 ret void And it generates the following asm (stripped): vxorps %xmm0, %xmm0, %xmm0 vmovaps %xmm0, dest(%rip) retq Both stores in the IR have the "!nontemporal" flag, but ISEL seems to select a different instruction in each case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 10:27:59 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 17:27:59 +0000 Subject: [LLVMbugs] [Bug 19371] New: [zorg] getClangMinGWBuildFactory calls ninja clang-test w/o checking out clang-tests Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19371 Bug ID: 19371 Summary: [zorg] getClangMinGWBuildFactory calls ninja clang-test w/o checking out clang-tests Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rfoos at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified An svn-clang-tests step needs to be added to bring in the clang-tests project for this step. C:\buildbots\hexagon-build-01-exp\clang-mingw64-win7\llvm\build>"ninja" "clang-test" ninja: error: unknown target 'clang-test', did you mean 'clang-tidy'? program finished with exit code 1 elapsedTime=0.218000 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 10:58:34 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 17:58:34 +0000 Subject: [LLVMbugs] [Bug 15207] modules do not work with relative -I paths In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=15207 John Thompson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |John.Thompson.JTSoftware at gm | |ail.com Resolution|--- |FIXED --- Comment #1 from John Thompson --- Richard fixed this in r203005. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 13:13:03 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 20:13:03 +0000 Subject: [LLVMbugs] [Bug 19372] New: assertion "Replacement.isCanonical() && "replacement types must always be canonical"" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19372 Bug ID: 19372 Summary: assertion "Replacement.isCanonical() && "replacement types must always be canonical"" Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: eric at boostpro.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12355 --> http://llvm.org/bugs/attachment.cgi?id=12355&action=edit self-contained repro Built from trunk within the past week. Release with debug assertions. See attached tgz for the repro. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 13:23:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 20:23:28 +0000 Subject: [LLVMbugs] [Bug 19373] New: clang erroneously enforcing alias template parameter kind Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19373 Bug ID: 19373 Summary: clang erroneously enforcing alias template parameter kind Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: eric at boostpro.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Gcc 4.8.2 accepts the following code. I think it's legal, but I'm far from certain. /////////////////////////////////////// template using X = T; template class T> struct S { template using X = T; }; int main() { S::X i = 0; } /////////////////////////////////////// Result: test.cpp:8:17: error: pack expansion used as argument for non-pack parameter of alias template using X = T; ^~~~~ test.cpp:13:5: note: in instantiation of template class 'S' requested here S::X i = 0; ^ test.cpp:1:19: note: template parameter is declared here template ^ -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 13:33:08 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 20:33:08 +0000 Subject: [LLVMbugs] [Bug 19345] [ARM64] Miscompile/miscompare of SPEC2000 benchmarks In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19345 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Chad Rosier --- I've verified that these failures have all been resolved. Thanks, Tim! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 13:42:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 20:42:24 +0000 Subject: [LLVMbugs] [Bug 19374] New: Getting 'is not a member of' compiling error while accessing class member in nested class. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19374 Bug ID: 19374 Summary: Getting 'is not a member of' compiling error while accessing class member in nested class. Product: clang Version: 3.2 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: aurelien.ooms at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12356 --> http://llvm.org/bugs/attachment.cgi?id=12356&action=edit Working example archive. Working example in attachement file # make clean all COMPILER=g++ produces no error while # make clean all COMPILER=clang++ outputs h/pfsp/pivoting/best.hpp:47:20: error: 'pfsp::pivoting::best(const std::vector > &, void (*)(const std::vector > &, pfsp::pivoting::functor > *), pfsp::eval::functor >, std::tuple, lib::array::proxy, std::vector > > *)::fn::operator()(const std::tuple &)::fn::e' is not a member of class 'fn' The problem seems to be that in h/pfsp/pivoting/best.hpp:47:20 I don't access the class members using the this keyword. Adding this-> for all member access in h/pfsp/pivoting/best.hpp and h/pfsp/pivoting/first.hpp solves the issue but the program will not compile and strange warnings/errors pop up: warning: field 'e' will be initialized after field 'sol' [-Wreorder] warning: field 'sol' will be initialized after field 'opt' [-Wreorder] warning: field 'opt' will be initialized after field 'argopt' [-Wreorder] error: constructor for 'fn' must explicitly initialize the reference member 'sol' ('Strange' because I don't see what's the problem..) -v == g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) clang++ -v Debian clang version 3.2-7ubuntu1 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: x86_64-pc-linux-gnu Thread model: posix -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 14:40:45 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 08 Apr 2014 21:40:45 +0000 Subject: [LLVMbugs] [Bug 19348] DAGCombiner does not check for legal ExtLoad operation before folding (aext (zextload x)) -> (aext (truncate (*extload x))) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19348 Matt Arsenault changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |Matthew.Arsenault at amd.com Resolution|--- |FIXED --- Comment #3 from Matt Arsenault --- Fixed by r205805 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 17:18:37 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 00:18:37 +0000 Subject: [LLVMbugs] [Bug 19375] New: -Os generates crashy ARM iOS binary Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19375 Bug ID: 19375 Summary: -Os generates crashy ARM iOS binary Product: clang Version: 3.4 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: fischman at chromium.org CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12357 --> http://llvm.org/bugs/attachment.cgi?id=12357&action=edit tar cvjf of the pre-processed .c file and resulting .o's in question At r189214 clang builds libvpx with -Os and the resulting binary doesn't crash. At r191856 the resulting binary does crash. For lots of details/noise on the crash please see https://code.google.com/p/webrtc/issues/detail?id=3038 Since the crash is isolated to a single input .c file I've run that .c file through clang -E under both clang versions (output differs only in immaterial whitespace). I then ran each of these through its respective clang -c and got significantly different object files (though, of course, this by itself is not a problem). I'm attaching these files to this bug. The relevant -E and -c command-lines are pasted below. FWIW this crash only manifests on iOS -Os builds; -O0 builds are fine, and Android armv7 -Os builds are fine too. ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/third_party/libvpx/source/libvpx/vp8/encoder/libvpx.pickinter.o.d -DV8_DEPRECATION_WARNINGS -DBLINK_SCALE_FILTERS_AT_RECORD_TIME -DDISABLE_NACL -DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_CONFIGURATION_POLICY -DDISCARDABLE_MEMORY_ALWAYS_SUPPORTED_NATIVELY -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DENABLE_EGLIMAGE=1 -DCLD_VERSION=1 -DENABLE_SPELLCHECK=1 -DDISABLE_FTP_SUPPORT=1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNS_BLOCK_ASSERTIONS=1 -I../../third_party/libvpx/source/config/linux/arm-neon -I../../third_party/libvpx/source/config -I../../third_party/libvpx/source/libvpx -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -Os -gdwarf-2 -fvisibility=hidden -Wnewline-eof -miphoneos-version-min=6.0 -arch armv7 -Wendif-labels -Wno-unused-parameter -Wno-missing-field-initializers -Wheader-hygiene -Wno-c++11-narrowing -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-deprecated-register -Wno-absolute-value -std=c99 -Xclang -load -Xclang /Users/fischman/src/wr/trunk/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -fcolor-diagnostics -I/Users/fischman/src/wr/trunk/third_party/libvpx/source/config/linux/arm-neon -I/Users/fischman/src/wr/trunk/third_party/libvpx/source/config -Igen/third_party/libvpx -Wno-unknown-warning-option -E ../../third_party/libvpx/source/libvpx/vp8/encoder/pickinter.c -o /tmp/b3038/libvpx.pickinter.E.189214 ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/third_party/libvpx/source/libvpx/vp8/encoder/libvpx.pickinter.o.d -DV8_DEPRECATION_WARNINGS -DBLINK_SCALE_FILTERS_AT_RECORD_TIME -DDISABLE_NACL -DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_CONFIGURATION_POLICY -DDISCARDABLE_MEMORY_ALWAYS_SUPPORTED_NATIVELY -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DENABLE_EGLIMAGE=1 -DCLD_VERSION=1 -DENABLE_SPELLCHECK=1 -DDISABLE_FTP_SUPPORT=1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNS_BLOCK_ASSERTIONS=1 -I../../third_party/libvpx/source/config/linux/arm-neon -I../../third_party/libvpx/source/config -I../../third_party/libvpx/source/libvpx -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -Os -gdwarf-2 -fvisibility=hidden -Wnewline-eof -miphoneos-version-min=6.0 -arch armv7 -Wendif-labels -Wno-unused-parameter -Wno-missing-field-initializers -Wheader-hygiene -Wno-c++11-narrowing -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-deprecated-register -Wno-absolute-value -std=c99 -Xclang -load -Xclang /Users/fischman/src/wr/trunk/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -fcolor-diagnostics -I/Users/fischman/src/wr/trunk/third_party/libvpx/source/config/linux/arm-neon -I/Users/fischman/src/wr/trunk/third_party/libvpx/source/config -Igen/third_party/libvpx -Wno-unknown-warning-option -x c -c /tmp/b3038/libvpx.pickinter.E.189214 -o /tmp/b3038/libvpx.pickinter.o.189214 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 18:07:18 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 01:07:18 +0000 Subject: [LLVMbugs] [Bug 19376] New: Missing -Wuninitialized warning for construction of member with another member using a constructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19376 Bug ID: 19376 Summary: Missing -Wuninitialized warning for construction of member with another member using a constructor Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangbugs at nondot.org Reporter: akyrtzi at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This test case: ------------- struct Bar { int val = 0; }; struct Foo { Foo(const Bar& b) : val(b.val) { } int val; }; class MyClass1 { public: MyClass1(); private: Bar x; Bar y; }; MyClass1::MyClass1() : x(y) { } class MyClass2 { public: MyClass2(); private: Foo x; Bar y; }; MyClass2::MyClass2() : x(y) { } ----------------- Only gives only warning: test.cpp:21:26: warning: field 'y' is uninitialized when used here [-Wuninitialized] MyClass1::MyClass1() : x(y) ^ 1 warning generated. It should warn on MyClass2 as well. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Tue Apr 8 18:40:40 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 01:40:40 +0000 Subject: [LLVMbugs] [Bug 18908] False positive when using a category on NSMutableArray In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18908 Jordan Rose changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jordan_rose at apple.com Resolution|--- |FIXED --- Comment #2 from Jordan Rose --- Fixed in r205827. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 00:07:17 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 07:07:17 +0000 Subject: [LLVMbugs] [Bug 19367] [ARM64] Can not select ARM64ISD::NOT of v1i64 type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19367 Tim Northover changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |t.p.northover at gmail.com Resolution|--- |FIXED --- Comment #2 from Tim Northover --- Thanks Hao. These should be fixed in r205835 and r205836. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 00:20:16 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 07:20:16 +0000 Subject: [LLVMbugs] [Bug 19377] New: LangRef: missing documentation for unary operations 'inv', 'neg', 'fneg' Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19377 Bug ID: 19377 Summary: LangRef: missing documentation for unary operations 'inv', 'neg', 'fneg' Product: Documentation Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedbugs at nondot.org Reporter: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The operations 'inv', 'neg', 'fneg' are not mentioned in http://llvm.org/docs/LangRef.html -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 00:36:09 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 07:36:09 +0000 Subject: [LLVMbugs] [Bug 9619] clang c++ "infinite" loop with template class and operator-> In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9619 Rahul Jain <1989.rahuljain at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |1989.rahuljain at gmail.com Resolution|--- |FIXED --- Comment #8 from Rahul Jain <1989.rahuljain at gmail.com> --- The option -foperator-arrow-depth=N implemented in r194161 takes care of this. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 05:08:59 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 12:08:59 +0000 Subject: [LLVMbugs] [Bug 19379] New: llvm-lit does not get built on Windows. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19379 Bug ID: 19379 Summary: llvm-lit does not get built on Windows. Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: jujjyl at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified 1. Run CMake with the following args: cmake -G "Visual Studio 10 Win64" -DCMAKE_INCLUDE_EXAMPLES=OFF -DCMAKE_INCLUDE_TESTS=OFF c:/path/to/llvm 2. Open the generated .sln file in VS2010. Observed: The tool llvm-lit is not present in the solution and does not get built. Expected: The tool llvm-lit should be found in the solution in folder Utils/llvm-lit -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 08:38:38 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 15:38:38 +0000 Subject: [LLVMbugs] [Bug 19383] New: Denormalized results for divsf3 and divdf3 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19383 Bug ID: 19383 Summary: Denormalized results for divsf3 and divdf3 Product: compiler-rt Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedbugs at nondot.org Reporter: hausen at gmx.at CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12358 --> http://llvm.org/bugs/attachment.cgi?id=12358&action=edit Proposed patch for denormalized division results. divsf and divdf currently flush denormalized results to zero. The attached patch changes this. It works for the few test cases I have at hand (notably, the paranoia floating-point test). The code is adapted from the corresponding code in the multiplication routines, so it should not be too far off, but, admittedly, I might have overlooked some corner case. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 10:01:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 17:01:52 +0000 Subject: [LLVMbugs] [Bug 19385] New: Adding static_asserts suppresses errors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19385 Bug ID: 19385 Summary: Adding static_asserts suppresses errors Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: jw2wjw2 at gmail.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12359 --> http://llvm.org/bugs/attachment.cgi?id=12359&action=edit File demonstrating the bug This program fails to compile with the error: %%%% clang++ -std=c++11 static_assert.cpp %%%% static_assert.cpp:17:38: error: no matching function for call to 'memoize' std::cout << "1+" << val <<" = " << memoize(increment,std::move(val)) << std::endl; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ static_assert.cpp:6:1: note: candidate template ignored: substitution failure [with function_t = int (*)(int), Args = ]: implicit instantiation of undefined template 'std::result_of' memoize(function_t f, Args&&...a) { ^ When the debug flag is enabled, compilation succeeds. (clang++ -std=c++11 -DDEBUG static_assert.cpp) Since the only difference between the two is the presence of a static_assert, this violates §7.0.4: "... If the value of the expression when so converted is true, the declaration has no effect." -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 11:34:58 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 18:34:58 +0000 Subject: [LLVMbugs] [Bug 19386] New: Add ARM64 backend component to libraries product. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19386 Bug ID: 19386 Summary: Add ARM64 backend component to libraries product. Product: Bugzilla Admin Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Products Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 11:45:29 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 18:45:29 +0000 Subject: [LLVMbugs] [Bug 19387] New: [ARM64] Assertion `Subtarget->isTargetDarwin() && "automatic va_arg instruction only works on Darwin"' failed. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19387 Bug ID: 19387 Summary: [ARM64] Assertion `Subtarget->isTargetDarwin() && "automatic va_arg instruction only works on Darwin"' failed. Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Test case: -------------------------------------------------------------------- target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128" target triple = "arm64-none-linux-gnu" %struct.__va_list.1 = type { i8*, i8*, i8*, i32, i32 } define void @vaarg(%struct.__va_list.1* byval nocapture %ap) { entry: %0 = va_arg %struct.__va_list.1* %ap, i32* ret void } --------------------------------------------------------------------- Reproduce with llc -O3 test.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 14:17:15 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 21:17:15 +0000 Subject: [LLVMbugs] [Bug 19388] New: formal parameter reordered with optimisations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19388 Bug ID: 19388 Summary: formal parameter reordered with optimisations Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedbugs at nondot.org Reporter: compnerd at compnerd.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following snippet demonstrates the issue: struct S { int i; }; int function(struct S s, int i) { return s.i + i; } The parameters are reordered even at -O1. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:04:01 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:04:01 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 19181, which changed state. Bug 19181 Summary: MS ABI: Layout of derived class with empty base is wrong http://llvm.org/bugs/show_bug.cgi?id=19181 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:04:00 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:04:00 +0000 Subject: [LLVMbugs] [Bug 19181] MS ABI: Layout of derived class with empty base is wrong In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19181 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed in r205933. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:06:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:06:30 +0000 Subject: [LLVMbugs] [Bug 19389] New: SSE register return with SSE disabled Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19389 Bug ID: 19389 Summary: SSE register return with SSE disabled Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: dl9pf at gmx.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified We fail to compile fs/mbcache.c from the linux kernel with: fatal error: error in backend: SSE register return with SSE disabled clang-3.5: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.5.0 Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.5: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script. clang-3.5: 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.5: note: diagnostic msg: /home/llvmlinux/targets/x86_64/tmp/mbcache-641fb2.c clang-3.5: note: diagnostic msg: /home/llvmlinux/targets/x86_64/tmp/mbcache-641fb2.sh clang-3.5: note: diagnostic msg: ******************** make[3]: *** [fs/mbcache.o] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:11:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:11:30 +0000 Subject: [LLVMbugs] [Bug 18826] MS ABI: clang doesn't create a packed struct when one is required In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18826 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed on or prior to r205933. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:11:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:11:30 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18826, which changed state. Bug 18826 Summary: MS ABI: clang doesn't create a packed struct when one is required http://llvm.org/bugs/show_bug.cgi?id=18826 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:13:09 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:13:09 +0000 Subject: [LLVMbugs] [Bug 18467] [-cxx-abi microsoft] wrong layout involving empty base class at offset 0 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18467 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed in r205933. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:13:10 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:13:10 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18467, which changed state. Bug 18467 Summary: [-cxx-abi microsoft] wrong layout involving empty base class at offset 0 http://llvm.org/bugs/show_bug.cgi?id=18467 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:16:41 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:16:41 +0000 Subject: [LLVMbugs] [Bug 19390] New: [windows] Cmake llvm build of MinGW under Cygwin fails: Posix filesystem calls. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19390 Bug ID: 19390 Summary: [windows] Cmake llvm build of MinGW under Cygwin fails: Posix filesystem calls. Product: new-bugs Version: trunk Hardware: PC OS: Windows 2000 Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: rfoos at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified A CMake build using MinGW under CYGWIN fails in FileSystem.h. This is due to the LLVM source code using Posix filesystem calls when LLVM_ON_UNIX is true. Since MinGW can be used on both Cygwin/Unix, and Windows there is a conflict. LLVM assumes that LLVM_ON_UNIX means that all posix filesystem calls are present. Since Mingw doesn't support posix filesystem calls, the build breaks early in: include/llvm/Support/FileSystem.h The information to identify this case is in CMakeCCompiler.cmake. The final definition of the flags is in LLVMConfig.cmake set(LLVM_ON_UNIX 1) set(LLVM_ON_WIN32 0) For MinGW, LLVM_ON_UNIX must be false and LLVM_ON_WIN32 must be true. Linux or Windows is not quite correct for this case. A new HAVE_POSIX, segragating the filesystem headers and api's would be more correct. This is a bit more extensive involving source code, cmake build, and autoconf build. Since mingw current builds with LLVM_ON_WIN32 set this way, the trivial change should work. The Host and Compiler information regarding Cygwin and MinGW are all present in CMakeCCompiler.cmake for a starting point. The variables needed by the build are set in LLVMConfig.cmake. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:16:46 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:16:46 +0000 Subject: [LLVMbugs] [Bug 18694] MS ABI: Alignment of field following vbptr or vfptr is ignored. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18694 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed on or prior to r205933. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:16:47 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:16:47 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18694, which changed state. Bug 18694 Summary: MS ABI: Alignment of field following vbptr or vfptr is ignored. http://llvm.org/bugs/show_bug.cgi?id=18694 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 15:17:57 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 09 Apr 2014 22:17:57 +0000 Subject: [LLVMbugs] [Bug 17803] loop increment/compare/branch should be removed for vectorized and unrolled code In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17803 Sanjay changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sanjay3.0.0.0 at gmail.com Resolution|--- |FIXED --- Comment #3 from Sanjay --- This looks ideal with clang 3.5 (r205798): bin$ ./clang -v clang version 3.5.0 (trunk 205798) (llvm/trunk 205792) Target: x86_64-apple-darwin13.1.0 Thread model: posix bin$ ./clang xor.c -O3 -fomit-frame-pointer -o - -S -march=core-avx2 ... ## BB#0: ## %entry vmovaps LCPI0_0(%rip), %ymm0 vxorps (%rdi), %ymm0, %ymm1 vxorps 32(%rdi), %ymm0, %ymm2 vxorps 64(%rdi), %ymm0, %ymm3 vxorps 96(%rdi), %ymm0, %ymm0 vmovups %ymm1, (%rdi) vmovups %ymm2, 32(%rdi) vmovups %ymm3, 64(%rdi) vmovups %ymm0, 96(%rdi) vzeroupper retq With a plain 'avx' target rather than 'avx2', we go through all kinds of gymnastics to avoid unaligned 32-bit load or store, but the leftover loop problem is still fixed: $ ./clang xor.c -O3 -fomit-frame-pointer -o - -S -march=corei7-avx ... ## BB#0: ## %entry vmovups (%rdi), %xmm0 vmovups 32(%rdi), %xmm1 vmovups 64(%rdi), %xmm2 vmovups 96(%rdi), %xmm3 vinsertf128 $1, 16(%rdi), %ymm0, %ymm0 vinsertf128 $1, 48(%rdi), %ymm1, %ymm1 vinsertf128 $1, 80(%rdi), %ymm2, %ymm2 vinsertf128 $1, 112(%rdi), %ymm3, %ymm3 vmovaps LCPI0_0(%rip), %ymm4 vxorps %ymm4, %ymm0, %ymm0 vxorps %ymm4, %ymm1, %ymm1 vxorps %ymm4, %ymm2, %ymm2 vxorps %ymm4, %ymm3, %ymm3 vextractf128 $1, %ymm0, %xmm4 vmovups %xmm4, 16(%rdi) vmovups %xmm0, (%rdi) vextractf128 $1, %ymm1, %xmm0 vmovups %xmm0, 48(%rdi) vmovups %xmm1, 32(%rdi) vextractf128 $1, %ymm2, %xmm0 vmovups %xmm0, 80(%rdi) vmovups %xmm2, 64(%rdi) vextractf128 $1, %ymm3, %xmm0 vmovups %xmm0, 112(%rdi) vmovups %xmm3, 96(%rdi) vzeroupper retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 22:02:18 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 05:02:18 +0000 Subject: [LLVMbugs] [Bug 15869] DIE Value form not supported yet In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=15869 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Christopher --- I'm going to go ahead and call this fixed then. If you run into any other problems let me know please! Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Wed Apr 9 22:22:23 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 05:22:23 +0000 Subject: [LLVMbugs] [Bug 19221] Debug-info verifier failure In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19221 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |echristo at gmail.com Resolution|--- |FIXED Assignee|unassignedbugs at nondot.org |echristo at gmail.com --- Comment #1 from Eric Christopher --- I believe I've fixed this in 205952. The global variables weren't quite right, they really should never have empty name strings and we should output variables so that people can use them to grab values when you've got an anonymous union at global scope. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 00:06:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 07:06:52 +0000 Subject: [LLVMbugs] [Bug 19391] New: clang 3.4 hangs in SymbolTableListTraits::transferNodesFromList() w/ -Os Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19391 Bug ID: 19391 Summary: clang 3.4 hangs in SymbolTableListTraits::transferNodesFromList() w/ -Os Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangbugs at nondot.org Reporter: asolokha at gmx.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified clang 3.4 on x86_64-pc-linux-gnu hangs when compiling the following test case w/ -Os: static int bv(void) { static int zv = 1; int wf = 1; h3: for (zv = 0; zv < 1; ++zv) if (0 != wf) goto h3; return 0; } static void sj(int d2) { int ol; int fo; int *rf = &fo; volatile int *as = &fo; for (d2 = 0; d2 < 2; ++d2) *as = 0; for (ol = 15; ol != 2; ol -= 3U) if (ol != (0 == *rf)) { static int st; for (st = 0; st < 1; ++st) ; } } void u1(void) { sj(bv()); } It seems that the endless loop occurs in llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&, llvm::ilist_iterator, llvm::ilist_iterator). W/ the following change to the test case compilation takes a few seconds but eventually ends successfully: static void sj(int d2) { - int ol; + short int ol; int fo; int *rf = &fo; volatile int *as = &fo; for (d2 = 0; d2 < 2; ++d2) *as = 0; - for (ol = 15; ol != 2; ol -= 3U) + for (ol = 15; ol != 2; ol -= 3) if (ol != (0 == *rf)) { static int st; for (st = 0; st < 1; ++st) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 07:50:56 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 14:50:56 +0000 Subject: [LLVMbugs] [Bug 19392] New: AArch64/ARM64 top-level merge issue Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19392 Bug ID: 19392 Summary: AArch64/ARM64 top-level merge issue Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: t.p.northover at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified This is intended to be a parent for all issues that are blocking the completion of the AArch64/ARM64 merge process. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 12:24:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 19:24:52 +0000 Subject: [LLVMbugs] [Bug 19392] AArch64/ARM64 top-level merge issue In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19392 Bug 19392 depends on bug 19387, which changed state. Bug 19387 Summary: [ARM64] Assertion `Subtarget->isTargetDarwin() && "automatic va_arg instruction only works on Darwin"' failed. http://llvm.org/bugs/show_bug.cgi?id=19387 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 12:24:51 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 19:24:51 +0000 Subject: [LLVMbugs] [Bug 19387] [ARM64] Assertion `Subtarget->isTargetDarwin() && "automatic va_arg instruction only works on Darwin"' failed. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19387 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Chad Rosier --- This problem appears to have resulted from an incorrect internal merge. We have since resolved the issue. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 12:36:47 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 19:36:47 +0000 Subject: [LLVMbugs] [Bug 19393] New: C++11 atomics fail to link Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19393 Bug ID: 19393 Summary: C++11 atomics fail to link Product: dragonegg Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: New Bugs Assignee: baldrick at free.fr Reporter: scott+llvm+bugzilla at pakin.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12362 --> http://llvm.org/bugs/attachment.cgi?id=12362&action=edit Minimal reproducer, courtesy of Aleksandr Drozd When using std::atomic, this works: $ g++ -std=c++11 -o atomics atomics.cpp This doesn't: $ g++ -fplugin=/usr/local/lib/dragonegg.so -std=c++11 -o atomics atomics.cpp /tmp/ccYWBxLQ.o: In function `std::__atomic_base::store(int, std::memory_order)': atomics.cpp:(.text._ZNSt13__atomic_baseIiE5storeEiSt12memory_order[_ZNSt13__atomic_baseIiE5storeEiSt12memory_order]+0x44): undefined reference to `__atomic_store_4' /tmp/ccYWBxLQ.o: In function `std::__atomic_base::load(std::memory_order) const': atomics.cpp:(.text._ZNKSt13__atomic_baseIiE4loadESt12memory_order[_ZNKSt13__atomic_baseIiE4loadESt12memory_order]+0x38): undefined reference to `__atomic_load_4' collect2: error: ld returned 1 exit status Here's what I'm running: $ g++ --version | head -1 g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 $ svn info | grep Revision Revision: 205933 $ uname -a Linux morbo 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I've attached a minimal reproducer. Thanks in advance for your attention, -- Scott -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 12:59:41 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 19:59:41 +0000 Subject: [LLVMbugs] [Bug 8890] build.llvm.org should redirect to http://google1.osuosl.org:8011/ In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8890 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |tobias at grosser.es Resolution|--- |INVALID --- Comment #3 from Tobias Grosser --- google1.osuosl.org does not exist any more -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 13:10:19 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 20:10:19 +0000 Subject: [LLVMbugs] [Bug 17286] using memory operand form of division would save on code size In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17286 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sanjay3.0.0.0 at gmail.com Resolution|--- |FIXED --- Comment #13 from Sanjay Patel --- Marking as fixed because the test cases here work as expected now. Will file separate bugs if I encounter any other problems. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 13:38:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 20:38:06 +0000 Subject: [LLVMbugs] [Bug 17185] match broadcast instruction to data type (int or FP) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17185 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sanjay3.0.0.0 at gmail.com Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- Using: $ ./clang -v clang version 3.5.0 (trunk 205798) (llvm/trunk 205792) Target: x86_64-apple-darwin13.1.0 Thread model: posix We're not generating any floating-point variants of the broadcast instruction. We're generating 'vpbroadcastq' now. Not sure if this is actually better codegen though...certainly bigger: _foo: ## @foo .cfi_startproc ## BB#0: ## %entry ## kill: ESI ESI RSI testl %esi, %esi jle LBB0_23 ## BB#1: ## %for.body.lr.ph movl %edx, %r8d leal -1(%rsi), %eax leaq 1(%rax), %r9 xorl %r10d, %r10d movabsq $8589934560, %rdx ## imm = 0x1FFFFFFE0 andq %r9, %rdx je LBB0_5 ## BB#2: ## %vector.ph vmovq %r8, %xmm0 vpbroadcastq %xmm0, %ymm0 <---- integer form of broadcast incq %rax andq $-32, %rax xorl %ecx, %ecx vmovdqa LCPI0_0(%rip), %ymm1 vmovdqa LCPI0_1(%rip), %ymm2 vmovdqa LCPI0_2(%rip), %ymm3 vmovdqa LCPI0_3(%rip), %ymm4 vmovdqa LCPI0_4(%rip), %ymm5 vmovdqa LCPI0_5(%rip), %ymm6 vmovdqa LCPI0_6(%rip), %ymm7 vmovdqa LCPI0_7(%rip), %ymm8 vmovdqa LCPI0_8(%rip), %ymm9 .align 4, 0x90 LBB0_3: ## %vector.body ## =>This Inner Loop Header: Depth=1 vmovq %rcx, %xmm10 vpermq $0, %ymm10, %ymm10 ## ymm10 = ymm10[0,0,0,0] vpaddq %ymm0, %ymm10, %ymm10 vpaddq %ymm1, %ymm10, %ymm11 vpaddq %ymm2, %ymm10, %ymm12 vpaddq %ymm3, %ymm10, %ymm13 vpaddq %ymm4, %ymm10, %ymm14 vpermd %ymm12, %ymm9, %ymm12 vpermd %ymm11, %ymm9, %ymm11 vinserti128 $1, %xmm11, %ymm12, %ymm11 vpaddq %ymm5, %ymm10, %ymm12 vpermd %ymm14, %ymm9, %ymm14 vpermd %ymm13, %ymm9, %ymm13 vinserti128 $1, %xmm13, %ymm14, %ymm13 vpaddq %ymm6, %ymm10, %ymm14 vpermd %ymm14, %ymm9, %ymm14 vpermd %ymm12, %ymm9, %ymm12 vinserti128 $1, %xmm12, %ymm14, %ymm12 vpaddq %ymm7, %ymm10, %ymm14 vpaddq %ymm8, %ymm10, %ymm10 vpermd %ymm10, %ymm9, %ymm10 vpermd %ymm14, %ymm9, %ymm14 vinserti128 $1, %xmm14, %ymm10, %ymm10 vmovdqu %ymm11, (%rdi,%rcx,4) vmovdqu %ymm13, 32(%rdi,%rcx,4) vmovdqu %ymm12, 64(%rdi,%rcx,4) vmovdqu %ymm10, 96(%rdi,%rcx,4) addq $32, %rcx cmpq %rcx, %rax jne LBB0_3 ## BB#4: movq %rdx, %r10 LBB0_5: ## %middle.block cmpq %r10, %r9 je LBB0_23 ## BB#6: ## %for.body.preheader leal 1(%rsi), %edx leal 1(%r10), %eax subl %eax, %edx movl %edx, %eax andl $7, %eax je LBB0_20 ## BB#7: ## %unr.cmp60 cmpl $1, %eax je LBB0_19 ## BB#8: ## %unr.cmp52 cmpl $2, %eax je LBB0_18 ## BB#9: ## %unr.cmp44 cmpl $3, %eax je LBB0_17 ## BB#10: ## %unr.cmp36 cmpl $4, %eax je LBB0_16 ## BB#11: ## %unr.cmp28 cmpl $5, %eax je LBB0_15 ## BB#12: ## %unr.cmp cmpl $6, %eax je LBB0_14 ## BB#13: ## %for.body.unr leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_14: ## %for.body.unr17 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_15: ## %for.body.unr22 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_16: ## %for.body.unr30 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_17: ## %for.body.unr38 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_18: ## %for.body.unr46 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_19: ## %for.body.unr54 leal (%r10,%r8), %eax movl %eax, (%rdi,%r10,4) incq %r10 LBB0_20: ## %for.body.preheader.split cmpl $8, %edx jb LBB0_23 ## BB#21: ## %for.body.preheader.split.split leaq 28(%rdi,%r10,4), %rax leaq 3(%r10,%r8), %rdx subl %r10d, %esi xorl %edi, %edi .align 4, 0x90 LBB0_22: ## %for.body ## =>This Inner Loop Header: Depth=1 leal (%rdx,%rdi), %r8d leal -3(%rdx,%rdi), %ecx movl %ecx, -28(%rax,%rdi,4) leal -2(%rdx,%rdi), %ecx movl %ecx, -24(%rax,%rdi,4) leal -1(%rdx,%rdi), %ecx movl %ecx, -20(%rax,%rdi,4) movl %r8d, -16(%rax,%rdi,4) leal 1(%rdx,%rdi), %ecx movl %ecx, -12(%rax,%rdi,4) leal 2(%rdx,%rdi), %ecx movl %ecx, -8(%rax,%rdi,4) leal 3(%rdx,%rdi), %ecx movl %ecx, -4(%rax,%rdi,4) leal 4(%rdx,%rdi), %ecx movl %ecx, (%rax,%rdi,4) addq $8, %r10 addq $8, %rdi cmpl %edi, %esi jne LBB0_22 LBB0_23: ## %for.end vzeroupper retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 13:38:08 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 20:38:08 +0000 Subject: [LLVMbugs] [Bug 17725] use the right data type when materializing an FP constant In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17725 Bug 17725 depends on bug 17185, which changed state. Bug 17185 Summary: match broadcast instruction to data type (int or FP) http://llvm.org/bugs/show_bug.cgi?id=17185 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 13:51:56 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 20:51:56 +0000 Subject: [LLVMbugs] [Bug 19394] New: Failure to compute loop count (and, thus, vectorize) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19394 Bug ID: 19394 Summary: Failure to compute loop count (and, thus, vectorize) Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedbugs at nondot.org Reporter: hfinkel at anl.gov CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Created attachment 12363 --> http://llvm.org/bugs/attachment.cgi?id=12363&action=edit test case We currently are unable to vectorize (or do much of anything else) with the following loop: omp.lb.le.global_ub..lr.ph.split.us: ; preds = %entry %12 = sext i32 %7 to i64 br label %omp.lb.le.global_ub..us omp.lb.le.global_ub..us: ; preds = %omp.lb_ub.check_pass.us, %omp.lb.le.global_ub..lr.ph.split.us %indvars.iv14 = phi i64 [ %indvars.iv.next15, %omp.lb_ub.check_pass.us ], [ %12, %omp.lb.le.global_ub..lr.ph.split.us ] %13 = trunc i64 %indvars.iv14 to i32 %omp.idx.le.ub.us = icmp sgt i32 %13, %10 br i1 %omp.idx.le.ub.us, label %omp.loop.end.loopexit, label %omp.lb_ub.check_pass.us omp.lb_ub.check_pass.us: ; preds = %omp.lb.le.global_ub..us %14 = load double* %ref3, align 8, !tbaa !4 %arrayidx.us = getelementptr inbounds [10000000 x double]* @c, i64 0, i64 %indvars.iv14 %15 = load double* %arrayidx.us, align 8, !tbaa !4 %mul5.us = fmul double %14, %15 %arrayidx6.us = getelementptr inbounds [10000000 x double]* @b, i64 0, i64 %indvars.iv14 store double %mul5.us, double* %arrayidx6.us, align 8, !tbaa !4 %indvars.iv.next15 = add nsw i64 %indvars.iv14, 1 br label %omp.lb.le.global_ub..us omp.loop.end.loopexit: ; preds = %omp.lb.le.global_ub..us br label %omp.loop.end this is important because this is what is generated by Intel's OpenMP branch (after optimization) from this basic loop (the outlined portion): ssize_t j; #pragma omp parallel for for (j=0; j {(1 + (sext i32 %7 to i64)),+,1}<%omp.lb.le.global_ub..us> Exits: <> but it cannot compute an expression for the backedge count: Determining loop execution counts for: @.omp_microtask.35 Loop %omp.lb.le.global_ub..us: Unpredictable backedge-taken count. Loop %omp.lb.le.global_ub..us: Unpredictable max backedge-taken count. We should either enhance SE, or maybe there is a different want to formulate the loop in the frontend that will be friendlier to the existing SE implementation. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 14:05:38 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 21:05:38 +0000 Subject: [LLVMbugs] [Bug 19395] New: [ARM64] Maintain compatibility with armv7 intrinsics. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19395 Bug ID: 19395 Summary: [ARM64] Maintain compatibility with armv7 intrinsics. Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: mcrosier at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Patterns need to be added to support the selection of legacy ARMv7 intrinsics in ARM64InstrInfo.td. Similar code was added to AArch64InstrNEON.td. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 14:06:36 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 21:06:36 +0000 Subject: [LLVMbugs] [Bug 17236] missed opportunity to use vector FMA instruction In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=17236 Sanjay Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sanjay3.0.0.0 at gmail.com Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- With: $ ./clang -v clang version 3.5.0 (trunk 205798) (llvm/trunk 205792) Target: x86_64-apple-darwin13.1.0 Thread model: posix The SLP vectorizer is now able to generate packed FMA instructions for this test case. It's not using 32-byte wide operations, but that problem is addressed by bug 17170. _foo: ## @foo .cfi_startproc ## BB#0: ## %entry vmovupd (%rdi), %xmm0 vfmadd213pd %xmm0, %xmm0, %xmm0 vmovupd %xmm0, (%rdi) vmovupd 16(%rdi), %xmm0 vfmadd213pd %xmm0, %xmm0, %xmm0 vmovupd %xmm0, 16(%rdi) vmovupd 32(%rdi), %xmm0 vfmadd213pd %xmm0, %xmm0, %xmm0 vmovupd %xmm0, 32(%rdi) vmovupd 48(%rdi), %xmm0 vfmadd213pd %xmm0, %xmm0, %xmm0 vmovupd %xmm0, 48(%rdi) retq -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 14:27:57 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 21:27:57 +0000 Subject: [LLVMbugs] [Bug 19396] New: ARM code emitter misoptimization with 16-bit multiplication Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19396 Bug ID: 19396 Summary: ARM code emitter misoptimization with 16-bit multiplication Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedbugs at nondot.org Reporter: craig at ni.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified The following code snippet (post opt -O2 optimization): %136 = getelementptr i8* %dsp, i32 844 %137 = bitcast i8* %136 to i32** %138 = load i32** %137, align 4 %139 = bitcast i32* %138 to i16* %140 = load i16* %139, align 2 %vr22 = sext i16 %140 to i32 %vr22.1 = mul i32 %vr22, 5000 %141 = getelementptr i8* %dsp, i32 872 %142 = bitcast i8* %141 to i16* %143 = trunc i32 %vr22.1 to i16 store i16 %143, i16* %142, align 2 %144 = getelementptr i8* %dsp, i32 876 %sext = mul i32 %vr22, 327680000 ; 5000<<16 %145 = ashr exact i32 %sext, 16 %146 = bitcast i8* %144 to i32* store i32 %145, i32* %146, align 4 miscompiles on ARM with ;llc -mtriple=arm-pc-eabi -mcpu=cortex-a8 -mattr=-thumb2' (even with -O0 added). It generates the following: ldr r0, [r4, #844] mov r1, #904 mov r2, #59244544 orr r1, r1, #4096 orr r2, r2, #268435456 ldrsh r0, [r0] smulbb r1, r0, r1 smulwb r0, r2, r0 mov r2, #872 strh r1, [r4, r2] str r0, [r4, #876] The problem is that the second multiply (smulwb) tries to fold the ashr operation into the multiply, but it's not actually equivalent. The expected result in the original IR is the result of the 16-bit multiplication truncated to 16-bits and then sign-extended to 32. Instead smulwb multiplies all of 32 by the low 16-bits of r0 and writes the high 32-bits of the 48-bit intermediate result into r0. This leaves the entire 32-bit result intact without truncation to 16 bits and sign-extension. The culprit is this pattern in ARMInstrInfo.td: def : ARMV5TEPat<(sra (mul GPR:$a, sext_16_node:$b), (i32 16)), (SMULWB GPR:$a, GPR:$b)>; Commenting it out makes the bug go away, and correct code is emitted: ldr r0, [r4, #844] mov r2, #904 orr r2, r2, #4096 ldrsh r1, [r0] mov r0, #59244544 orr r0, r0, #268435456 mul r0, r1, r0 smulbb r1, r1, r2 mov r2, #872 strh r1, [r4, r2] asr r0, r0, #16 str r0, [r4, #876] -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 14:33:34 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 21:33:34 +0000 Subject: [LLVMbugs] [Bug 19395] [ARM64] Maintain compatibility with armv7 intrinsics. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19395 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 14:33:35 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 21:33:35 +0000 Subject: [LLVMbugs] [Bug 19392] AArch64/ARM64 top-level merge issue In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19392 Bug 19392 depends on bug 19395, which changed state. Bug 19395 Summary: [ARM64] Maintain compatibility with armv7 intrinsics. http://llvm.org/bugs/show_bug.cgi?id=19395 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 16:24:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 23:24:49 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 19180, which changed state. Bug 19180 Summary: MS ABI: layout of class with vbptr and vfptr is wrong http://llvm.org/bugs/show_bug.cgi?id=19180 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 16:24:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 23:24:49 +0000 Subject: [LLVMbugs] [Bug 19180] MS ABI: layout of class with vbptr and vfptr is wrong In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19180 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- fixed in r206000 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 16:26:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 23:26:49 +0000 Subject: [LLVMbugs] [Bug 18474] [-cxx-abi microsoft] size calculation is wrong for aligned bitfield inside pragma-pack In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18474 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed in 2059994. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 16:26:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 23:26:49 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18474, which changed state. Bug 18474 Summary: [-cxx-abi microsoft] size calculation is wrong for aligned bitfield inside pragma-pack http://llvm.org/bugs/show_bug.cgi?id=18474 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 16:43:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 10 Apr 2014 23:43:06 +0000 Subject: [LLVMbugs] [Bug 19282] clang crash on enum class ParseDeclarationAfterDeclaratorAndAttributes In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19282 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- No crash with trunk. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 17:14:32 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 00:14:32 +0000 Subject: [LLVMbugs] [Bug 18702] MS ABI: insufficient padding inserted between zero sized virtual bases in a record with a bitfield In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18702 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Warren Hunt --- fixed in 206004 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 17:14:33 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 00:14:33 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 18702, which changed state. Bug 18702 Summary: MS ABI: insufficient padding inserted between zero sized virtual bases in a record with a bitfield http://llvm.org/bugs/show_bug.cgi?id=18702 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 17:49:45 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 00:49:45 +0000 Subject: [LLVMbugs] [Bug 19397] New: MS ABI: Extra vtordisp thunk generated method inherited from virtual base Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19397 Bug ID: 19397 Summary: MS ABI: Extra vtordisp thunk generated method inherited from virtual base Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: rnk at google.com CC: llvmbugs at cs.uiuc.edu, timurrrr at google.com Classification: Unclassified In this example, we generate a thunk for g and MSVC doesn't. This may not be a correctness problem, but it shows up when comparing vftables. $ cat t.cpp struct A { A() {} virtual void f() = 0; virtual void g(); }; struct B : A { B() {} virtual void g(); }; struct C : virtual B { C() {} virtual void f(); }; C c; $ dumpbin /symbols t1.obj | grep ?g@ 025 00000000 SECT6 notype () External | ?g at B@@$4PPPPPPPM at A@AEXXZ ([thunk]:public: virtual void __thiscall B::g`vtordisp{4294967292,0}' (void)) 026 00000000 UNDEF notype External | ?g at B@@UAEXXZ (public: virtual void __thiscall B::g(void)) 02A 00000000 UNDEF notype External | ?g at A@@UAEXXZ (public: virtual void __thiscall A::g(void)) $ dumpbin /symbols t2.obj | grep ?g@ 012 00000000 UNDEF notype () External | ?g at A@@UAEXXZ (public: virtual void __thiscall A::g(void)) 014 00000000 UNDEF notype () External | ?g at B@@UAEXXZ (public: virtual void __thiscall B::g(void)) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Thu Apr 10 18:11:25 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 01:11:25 +0000 Subject: [LLVMbugs] [Bug 19398] New: Implement vector deleting destructors Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19398 Bug ID: 19398 Summary: Implement vector deleting destructors Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: rnk at google.com CC: david.majnemer at gmail.com, llvmbugs at cs.uiuc.edu, timurrrr at google.com Blocks: 12477 Classification: Unclassified MSVC supports an extension that allows users to delete an array of polymorphic objects where the dynamic type doesn't match the static type of the array. Here's an example of MSVC doing this where we can't: $ cat t.cpp extern "C" int printf(const char *, ...); struct A { A() : a(42) {} virtual ~A() { printf("a: %d\n", a); } int a; }; struct B : A { B() : b(13) {} ~B() { printf("b: %d\n", b); } int b; }; void foo(A *a) { delete[] a; } int main() { B *b = new B[2]; foo(b); } $ cl -nologo t.cpp && ./t.exe t.cpp b: 13 a: 42 b: 13 a: 42 $ clang-cl t.cpp && ./t.exe a: 16699704 a: 42 They use "vector deleting destructors" to do this special array deletion, and those are what go in the vftable. We currently put the scalar deleting dtor there instead. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 00:41:01 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 07:41:01 +0000 Subject: [LLVMbugs] [Bug 19399] New: MS ABI: Layout of class hierarchy with overridden methods and virtual inheritance is wrong Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19399 Bug ID: 19399 Summary: MS ABI: Layout of class hierarchy with overridden methods and virtual inheritance is wrong Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified consider: extern "C" int printf(const char *, ...); struct A { virtual void fun() {} }; struct B: public A {}; struct C: public virtual A { virtual void fun() {} C() {} }; struct D: public virtual C, public virtual B {}; int main() { printf("sizeof(D): %Iu\n", sizeof(D)); } 32-bit: clang gives D size 24, msvc gives it size 20 64-bit: clang gives D size 48, msvc gives it size 40 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 04:46:01 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 11:46:01 +0000 Subject: [LLVMbugs] [Bug 19400] New: Port big-endian support to ARM64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19400 Bug ID: 19400 Summary: Port big-endian support to ARM64 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: t.p.northover at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Big-endian support is currently being implemented on AArch64, and this will probably need to be ported to ARM64 before the merge can be called complete. This may mean the (hopefully temporary) creation of an arm64_be triple to do the redirection (yuck!). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 07:36:58 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 14:36:58 +0000 Subject: [LLVMbugs] [Bug 19401] New: clang-compiled gcc has reproducible internal compiler error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19401 Bug ID: 19401 Summary: clang-compiled gcc has reproducible internal compiler error Product: new-bugs Version: trunk Hardware: All OS: NetBSD Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedbugs at nondot.org Reporter: tk at giga.or.at CC: llvmbugs at cs.uiuc.edu Classification: Unclassified I'm using clang coming with NetBSD, on NetBSD-6.99.40/amd64, currently: clang version 3.5 (trunk 202566) Target: x86_64--netbsd Thread model: posix NetBSD also comes with a version of gcc: gcc (NetBSD nb2 20140304) 4.8.3 When using that clang to compile that version of gcc and then use gcc to compile software, a reproducible internal compiler error appears that does not happen when gcc is compiled with gcc. The original bug report was filed for a compilation problem with gambatte, see http://gnats.netbsd.org/48731 but the same problem also happened with pcre. This problem was then reported upstream to gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 until it was found that this only happens when gcc is compiled with clang. This looks really hard to debug, but I wanted to report it anyway. Let me know how to proceed. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 10:00:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 17:00:53 +0000 Subject: [LLVMbugs] [Bug 19395] [ARM64] Maintain compatibility with armv7 intrinsics. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19395 Chad Rosier changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #1 from Chad Rosier --- I thought I would reopen this to start the discussion. AFAIK, LLVM intrinsics can use any namespace. However, I would argue users of ARM64 will have to change their code to use arm64 prefix. When the ARMv8 backends merge is complete, the users may have to change their code back to use aarch64 prefix depending on how things pan out. Thus, it might be worthwhile to support the ARMv7 intrinsics in the ARM64 backend despite not being a strict requirement. This happens to work in the AArch64 backend because of the reuse of the ARMv7 intrinsics. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 10:00:54 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 17:00:54 +0000 Subject: [LLVMbugs] [Bug 19392] AArch64/ARM64 top-level merge issue In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19392 Bug 19392 depends on bug 19395, which changed state. Bug 19395 Summary: [ARM64] Maintain compatibility with armv7 intrinsics. http://llvm.org/bugs/show_bug.cgi?id=19395 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 10:43:21 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 17:43:21 +0000 Subject: [LLVMbugs] [Bug 19402] New: Finish converting instcombine to use IRBuilder Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19402 Bug ID: 19402 Summary: Finish converting instcombine to use IRBuilder Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedbugs at nondot.org Reporter: rafael.espindola at gmail.com CC: bigcheesegs at gmail.com, filcab at gmail.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Instcombine got an IR builder in r80492, but the move is still not done. Right now a we have a mix of visit methods doing Foo = Builder->CreateFoo()... return ReplaceInstUsesWith(I, Foo); or just return new Foo(...); and letting the main loop insert the instruction in the BB and replace it. Using the builder looks like the new way, but it seems to be missing some features, like reusing the old instruction name. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 11:54:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 18:54:53 +0000 Subject: [LLVMbugs] [Bug 19403] New: zlib support in windows with MSVC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19403 Bug ID: 19403 Summary: zlib support in windows with MSVC Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedbugs at nondot.org Reporter: sgundapa at codeaurora.org CC: llvmbugs at cs.uiuc.edu Classification: Unclassified Why is zlib support disabled for windows/MSVC in CMake? I got the zlib headers and libraries from GetGnuWin32. I have a code in llvm that uses zlib algorithm. With the current CMake configuration in LLVM, I couldn't configure to link zlib. To detect zlib.h header -DCMAKE_C_FLAGS="/IC:/GetGnuWin32/gnuwin32/include" - DCMAKE_CXX_FLAGS="/IC:/GetGnuWin32/gnuwin32/include" To detect zlib.lib library (dirty hack) -DHAVE_LIBZ=1 -DCMAKE_EXE_LINKER_FLAGS="C:/GetGnuWin32/gnuwin32/lib/zlib.lib" -DCMAKE_SHARED_LINKER_FLAGS="C:/GetGnuWin32/gnuwin32/lib/zlib.lib" The checks to detect zlib library and add it to the linker line are written for non-windows/MSVC sytems. I think, blocking the zlib support in windows is a limitation and a bug. --Sumanth G -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 12:34:06 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 19:34:06 +0000 Subject: [LLVMbugs] [Bug 19293] Cannot use GDB to debug executables built with Clang on trunk In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19293 Gregory Casamento changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Gregory Casamento --- I tried debugging with GDB version 7.7. The version I was using was 7.4. I was successful using 7.7. For some reason it didn't work with 7.4. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 12:59:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 19:59:24 +0000 Subject: [LLVMbugs] [Bug 19242] attribute_deprecated_with_message enabled when [[deprecated]] is not available In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19242 Richard Smith changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |richard-llvm at metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- That's correct; as the documentation says, this feature test is (also) for __attribute__((deprecated)). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 13:10:43 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 20:10:43 +0000 Subject: [LLVMbugs] [Bug 19404] New: Port Cortex-A53 scheduling model to ARM64 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19404 Bug ID: 19404 Summary: Port Cortex-A53 scheduling model to ARM64 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: t.p.northover at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified AArch64 has a scheduling model for Cortex-A53 which needs to be ported to ARM64 before the end of the merge. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 13:38:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 20:38:24 +0000 Subject: [LLVMbugs] [Bug 19405] New: Invalid optimization with -fPIC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19405 Bug ID: 19405 Summary: Invalid optimization with -fPIC Product: libraries Version: 3.3 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations Assignee: unassignedbugs at nondot.org Reporter: hubicka at ucw.cz CC: llvmbugs at cs.uiuc.edu Classification: Unclassified #include "stdio.h" int b(void) { return 1; } int a(int (*b)(void)) { return b(); } m() { int i; for (i=0; i<1000000;i++) i+=a(b); printf ("%i\n",i); c(); } With -O2 -fPIC is compiled as (on Linux): m: # @m .cfi_startproc # BB#0: pushq %rax .Ltmp3: .cfi_def_cfa_offset 16 leaq .L.str(%rip), %rdi movl $1000000, %esi # imm = 0xF4240 xorb %al, %al callq printf at PLT xorb %al, %al popq %rdx jmp c at PLT # TAILCALL .Ltmp4: This is not valid, since ELF interpositionallows you to replace a by different function returning different value. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 13:56:39 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 20:56:39 +0000 Subject: [LLVMbugs] [Bug 19299] recent regression: clang asserts building ITK: "Elements of a VectorType must be a primitive type" In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19299 Sean McBride changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Sean McBride --- clang r205980 no longer has this bug. ITK can once again be built. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 14:19:58 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 21:19:58 +0000 Subject: [LLVMbugs] [Bug 19406] New: Implement subtarget features for ARM64 backend Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19406 Bug ID: 19406 Summary: Implement subtarget features for ARM64 backend Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedbugs at nondot.org Reporter: t.p.northover at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified AArch64 supports CPUs lacking various parts of the instruction set: NEON and FP specifically, in some combination. Before the merge is completed ARM64 will have to do the same. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 14:43:25 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 21:43:25 +0000 Subject: [LLVMbugs] [Bug 18747] Add an option to allow an exhaustive search during last chance recoloring In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=18747 Quentin Colombet changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Quentin Colombet --- Mayur implemented #2 in r206072. Closing. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 15:05:48 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 22:05:48 +0000 Subject: [LLVMbugs] [Bug 19399] MS ABI: Layout of class hierarchy with overridden methods and virtual inheritance is wrong In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19399 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Warren Hunt --- Fixed in r206077. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 15:05:49 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 22:05:49 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 19399, which changed state. Bug 19399 Summary: MS ABI: Layout of class hierarchy with overridden methods and virtual inheritance is wrong http://llvm.org/bugs/show_bug.cgi?id=19399 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 15:52:30 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 22:52:30 +0000 Subject: [LLVMbugs] [Bug 19407] New: Potential vtordisp bug Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19407 Bug ID: 19407 Summary: Potential vtordisp bug Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: david.majnemer at gmail.com CC: llvmbugs at cs.uiuc.edu Classification: Unclassified consider: extern "C" int printf(const char *, ...); struct A {}; struct B {}; struct C : A { virtual void fun() {} }; struct D : virtual B, virtual C { virtual void fun() {} D() {} }; int main() { printf("sizeof(D): %Iu\n", sizeof(D)); } 32-bit clang/MSVC --- different.cpp_clang 2014-04-11 15:57:50.482628043 -0700 +++ different.cpp_vs 2014-04-11 15:57:50.462627835 -0700 @@ -1 +1 @@ -sizeof(D): 16 +sizeof(D): 12 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 15:52:31 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 22:52:31 +0000 Subject: [LLVMbugs] [Bug 19408] New: MS ABI: Bad this adjustment in vtable thunk with vtordisp Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19408 Bug ID: 19408 Summary: MS ABI: Bad this adjustment in vtable thunk with vtordisp Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: rnk at google.com CC: david.majnemer at gmail.com, llvmbugs at cs.uiuc.edu, timurrrr at google.com Blocks: 12477, 18887 Classification: Unclassified This program should print 3 but it prints 4: extern "C" int printf(const char *, ...); struct A { A() : a(1) {} virtual void f() { printf("%d\n", a); } int a; }; struct B : virtual A { B() : b(2) {} int b; }; struct C : B { C() : c(3) {} virtual void f() { printf("%d\n", c); } int c; }; struct D : C { D() : d(4) {} int d; }; int main() { D x; x.f(); } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 16:33:54 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 23:33:54 +0000 Subject: [LLVMbugs] [Bug 19407] Potential vtordisp bug In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19407 Warren Hunt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Warren Hunt --- Fixed in r206087. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 16:33:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 11 Apr 2014 23:33:55 +0000 Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 19407, which changed state. Bug 19407 Summary: Potential vtordisp bug http://llvm.org/bugs/show_bug.cgi?id=19407 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:28:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:28:28 +0000 Subject: [LLVMbugs] [Bug 13518] Debug info for the constructor of a templated class emits file for prototype instead of definition In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13518 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Christopher --- dzur:~/tmp> ~/builds/build-llvm/Debug+Asserts/bin/clang -g Test.cpp dzur:~/tmp> gdb a.out (gdb) run Starting program: a.out Program received signal SIGSEGV, Segmentation fault. Test::Test (this=0x7fffffffe2b8) at Test.cpp:5 5 *((T *)1) = 0; (gdb) bt #0 Test::Test (this=0x7fffffffe2b8) at Test.cpp:5 #1 0x0000000000400588 in main () at Test.cpp:9 Seems reasonable. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:30:59 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:30:59 +0000 Subject: [LLVMbugs] [Bug 13513] C++ arguments passed by invisible reference have wrong type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13513 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Looks fixed: dzur:~/tmp> ~/builds/build-llvm/Debug+Asserts/bin/clang -g foo.cpp dzur:~/tmp> gdb a.out Reading symbols from a.out...done. (gdb) ptype foo type = int (Obj) -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:33:45 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:33:45 +0000 Subject: [LLVMbugs] [Bug 13486] debug info has wrong AT_high_pc in CIE with global initializers In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13486 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Christopher --- Fixed this a while ago. Looks good with using DW_AT_ranges and here are the relocations in the .debug_ranges section: Section (16) .rela.debug_ranges { 0x0 R_X86_64_64 .text 0x0 0x8 R_X86_64_64 .text 0x30 0x10 R_X86_64_64 .text.startup 0x0 0x18 R_X86_64_64 .text.startup 0x12 0x20 R_X86_64_64 .text.startup 0x40 0x28 R_X86_64_64 .text.startup 0x52 0x30 R_X86_64_64 .text 0x30 0x38 R_X86_64_64 .text 0x3B } -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:36:53 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:36:53 +0000 Subject: [LLVMbugs] [Bug 13400] ARM Code generation crashes on a VS2010 build In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13400 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |INVALID --- Comment #14 from Eric Christopher --- We no longer support VS2010 in llvm. If you can still see this with VS2012 please reopen and I'll help you track it down. Thanks and apologize for the delay. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:40:38 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:40:38 +0000 Subject: [LLVMbugs] [Bug 13357] Clang crashes with coverage and Objective-C++ In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13357 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Christopher --- Looks like it's been fixed (I just tried duplicating it on a mac). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 17:49:40 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 00:49:40 +0000 Subject: [LLVMbugs] [Bug 12766] Wrong code while compiling glib-2.32.2 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12766 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Eric Christopher --- Going to mark it as fixed for now since there's been no reply in 6 mos. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:15:16 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:15:16 +0000 Subject: [LLVMbugs] [Bug 12476] "ld: warning: can't add line info to anonymous symbol cstring=SetTraceFilter" when building with -O3 -g in a class with virtual and nonvirtual bases In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12476 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Christopher --- Looks like valid debug info to me, and if I recall correctly that bug wasn't related to debug info. Going to resolve this as fixed for now. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:31:05 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:31:05 +0000 Subject: [LLVMbugs] [Bug 12069] subrange types should have the type passed into the metadata instead of constructing an "anonymous" type In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12069 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Christopher --- Debug info is fairly comparable to gcc's at this point, going to close this. If there's more we can do let me know. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:38:54 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:38:54 +0000 Subject: [LLVMbugs] [Bug 19409] New: name lookup of virtual base class member through using-declarations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19409 Bug ID: 19409 Summary: name lookup of virtual base class member through using-declarations Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangbugs at nondot.org Reporter: Trevor_Smigiel at playstation.sony.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified The following test case, example 6 from n1543, generates an ambiguous name lookup error on trunk. Is generating an error correct? It seems unambiguous (according to standard section 10.2 and n1543) because I1::f and I2::f designate the same virtual base class member B::f. struct B { void f(); }; struct I1: virtual B { using B::f; }; struct I2: virtual B { using B::f; }; struct D: I1, I2 { void g() { f(); // unambiguous } }; # clang --version clang version 3.5.0 (205993) Target: x86_64-unknown-linux-gnu Thread model: posix # clang -std=c++11 -c c.cpp c.cpp:13:9: error: member 'f' found in multiple base classes of different types f(); // unambiguous ^ c.cpp:6:14: note: member found by ambiguous name lookup using B::f; ^ c.cpp:9:14: note: member found by ambiguous name lookup using B::f; ^ 1 error generated. g++ 4.7 and 4.8 also generate an error for this case. I did not test other versions of gcc. For reference: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#39 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1543.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1626.pdf -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:45:07 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:45:07 +0000 Subject: [LLVMbugs] [Bug 7739] Implement support for 3DNow! In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=7739 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Eric Christopher --- The headers exist now as far as I can tell. dzur:~/sources/llvm> find . -name "*3dn*" -print ./tools/clang/test/CodeGen/3dnow-builtins.c ./tools/clang/lib/Headers/mm3dnow.h ./test/CodeGen/X86/3dnow-intrinsics.ll -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:50:58 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:50:58 +0000 Subject: [LLVMbugs] [Bug 9321] [autoconf][cmake] "make install" may provide similar installation. In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=9321 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Eric Christopher --- Since all of Brad's patches were applied, Resolved/Fixed? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:51:02 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:51:02 +0000 Subject: [LLVMbugs] [Bug 15732] [META] CMake build equivalent to the autotools build In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=15732 Bug 15732 depends on bug 9321, which changed state. Bug 9321 Summary: [autoconf][cmake] "make install" may provide similar installation. http://llvm.org/bugs/show_bug.cgi?id=9321 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:54:18 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:54:18 +0000 Subject: [LLVMbugs] [Bug 11135] Update -print-dbginfo pass to match LLVMDebugVersion 11 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=11135 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Eric Christopher --- Anything we do here will need to be completely rewritten and it doesn't seem to be something anyone wants necessarily. Going to close for now, will reopen if there's demand. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:56:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:56:28 +0000 Subject: [LLVMbugs] [Bug 12140] struct packing causing crashes In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12140 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Eric Christopher --- We now require gcc4.7 or greater and there have been no reports of failures on freebsd for the platform. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 18:57:52 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 01:57:52 +0000 Subject: [LLVMbugs] [Bug 12803] regression in John the Rippler blowfish on trunk versus 3.1 branch In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=12803 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Eric Christopher --- I'm going to close this as worksforme as I haven't seen the regression recently and it's been a while etc. Can retest if necessary or we want to use it as a benchmark. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:00:26 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:00:26 +0000 Subject: [LLVMbugs] [Bug 13599] Debug info says 'this' is at %rsp-8, but it's not there yet In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13599 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Jeffrey, I think this is fixed, or at least I haven't seen us stopping in the prologue before this is set up. Seen this lately? (Going to mark as resolved fixed and we can reopen it if we can see it on a testcase). -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:01:18 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:01:18 +0000 Subject: [LLVMbugs] [Bug 13636] An executable produced by clang can not be debugged with gdb under Windows In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13636 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Christopher --- Pretty sure people have been debugging under windows. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:11:28 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:11:28 +0000 Subject: [LLVMbugs] [Bug 13939] Breakpoint on constructor pauses before writing 'this' to the stack In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13939 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Christopher --- Jeffrey, going to guess that this was a duplicate of the "this" problem. Let me know if you've run into it recently. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:12:37 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:12:37 +0000 Subject: [LLVMbugs] [Bug 13973] LLVM/CLANG trunk emitting MACH-O files rejected by ranlib OS X 10.7.4/XCode 4.4.1 In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13973 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Eric Christopher --- The other bug has been resolved/fixed, going to mark this as so. Let me know if you still are seeing problems. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:15:02 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:15:02 +0000 Subject: [LLVMbugs] [Bug 14129] friend function is not marked with 'friend' in debug info In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14129 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Eric Christopher --- Apparently no one likes having friends and it's a non-zero cost in the debug info so I'm going to close this as wontfix for now and we can reopen it if we need to. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:22:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:22:55 +0000 Subject: [LLVMbugs] [Bug 14382] fPIC error for LTOCodeGenerator.o (SUSE Linux Enterprise Server 10 SP4 (x86_64)) In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14382 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Christopher --- We now require gcc 4.7 or greater to build llvm. If you see this with a later version please let me know. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:28:23 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:28:23 +0000 Subject: [LLVMbugs] [Bug 14473] Multiple breakpoints in class template member function definition In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14473 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Seems to be fixed: dzur:~/tmp> ~/builds/build-llvm/Debug+Asserts/bin/clang -g -c foo.cpp dzur:~/tmp> gdb foo.o Reading symbols from foo.o...done. (gdb) b foo::foo Breakpoint 1 at 0x4f: file foo.cpp, line 9. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:28:24 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:28:24 +0000 Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14330 Bug 14330 depends on bug 14473, which changed state. Bug 14473 Summary: Multiple breakpoints in class template member function definition http://llvm.org/bugs/show_bug.cgi?id=14473 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:33:13 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:33:13 +0000 Subject: [LLVMbugs] [Bug 14473] Multiple breakpoints in class template member function definition In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14473 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #2 from Eric Christopher --- Reopening this as we appear to need a new testcase. Probably constructor/destructor specific as a guess. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:33:13 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:33:13 +0000 Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14330 Bug 14330 depends on bug 14473, which changed state. Bug 14473 Summary: Multiple breakpoints in class template member function definition http://llvm.org/bugs/show_bug.cgi?id=14473 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 19:44:26 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 02:44:26 +0000 Subject: [LLVMbugs] [Bug 14966] A debug info issue when passing a struct by value In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=14966 Eric Christopher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Appears fixed if you'd like to verify: Breakpoint 1, main () at z.cpp:11 11 S s = { A_1, 1, {(const void*)10, (const void*)20, (const void*)30} }; (gdb) n 12 f1(s); (gdb) s f1 (s=...) at z.cpp:7 7 return f2(s); (gdb) p s $1 = {a = A_1, b = 1, c = {0xa, 0x14, 0x1e}} (gdb) s f2 (s=...) at zz.cpp:5 5 return s.c[2]; (gdb) s main () at z.cpp:13 13 } (gdb) p s $2 = {a = A_1, b = 1, c = {0xa, 0x14, 0x1e}} (gdb) s -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Fri Apr 11 22:36:10 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 05:36:10 +0000 Subject: [LLVMbugs] [Bug 13337] strip out DW_TAG_restrict_type on linux In-Reply-To: References: Message-ID: http://llvm.org/bugs/show_bug.cgi?id=13337 David Blaikie changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Blaikie --- r206105 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 12 01:28:05 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 08:28:05 +0000 Subject: [LLVMbugs] [Bug 19410] New: [R3.4.1] tools/clang/include/clang-c/Makefile aborts on Open Solaris 11 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19410 Bug ID: 19410 Summary: [R3.4.1] tools/clang/include/clang-c/Makefile aborts on Open Solaris 11 Product: Build scripts Version: 3.4 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: Makefiles Assignee: unassignedbugs at nondot.org Reporter: FBergemann at web.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified There is a multi line backquote in the Makefile here (starting with `find clang-c -type f ...): ifneq ($(PROJ_SRC_ROOT),$(PROJ_OBJ_ROOT)) $(Verb) if test -d "$(PROJ_OBJ_ROOT)/tools/clang/include/clang-c" ; then \ cd $(PROJ_OBJ_ROOT)/tools/clang/include && \ for hdr in `find clang-c -type f '!' '(' -name 'Makefile' ')' -print \ | grep -v CVS | grep -v .tmp | grep -v .dir` ; do \ instdir=`dirname "$(IntIncludeDir)/$$hdr"` ; \ if test \! -d "$$instdir" ; then \ $(EchoCmd) Making install directory $$instdir ; \ $(MKDIR) $$instdir ;\ fi ; \ $(DataInstall) $$hdr $(IntIncludeDir)/$$hdr ; \ done ; \ fi endif This fails in Solaris 11 (Virtual Box). It works, after joining the lines into a single line. rgds, Frank -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 12 07:02:38 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 14:02:38 +0000 Subject: [LLVMbugs] [Bug 19411] New: Block scope function declaration in class member function definition ignores linkage specification Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19411 Bug ID: 19411 Summary: Block scope function declaration in class member function definition ignores linkage specification Product: clang Version: 3.4 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangbugs at nondot.org Reporter: hstong at ca.ibm.com CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu Classification: Unclassified Clang does not honour linkage specifications in determining (at least) the language linkage of the name of a function declared at block scope in a member function definition. GCC and ICC work as expected. C++03 3.5 [basic.link] paragraph 6: The name of a function declared in block scope [ . . . ] [has] linkage. [ . . . ] [The] block scope entity receives external linkage. C++03 7.5 [dcl.link] paragraph 4: In a linkage-specification, the specified language linkage applies to the function types of all function declarators, function names, and variable names introduced by the declaration(s). ### SOURCE: > cat blockscopeextC.cc struct A { void foo(); }; extern "C" void A::foo() { void bar(int); bar(0); } Return: 0x00:0 ### COMPILER INVOCATION AND RESULT: > clang++ blockscopeextC.cc -c && nm blockscopeextC.o U _Z3bari 0000000000000000 D _ZN1A3fooEv Return: 0x00:0 ### EXPECTED RESULT: U bar 0000000000000000 D _ZN1A3fooEv ### clang++ -v: > clang++ -v clang version 3.4 (tags/RELEASE_34/final) Target: powerpc64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/ppc64-redhat-linux/4.4.4 Found candidate GCC installation: /usr/lib/gcc/ppc64-redhat-linux/4.4.6 Selected GCC installation: /usr/lib/gcc/ppc64-redhat-linux/4.4.6 Return: 0x00:0 -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at llvm.org Sat Apr 12 16:41:55 2014 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 12 Apr 2014 23:41:55 +0000 Subject: [LLVMbugs] [Bug 19412] New: Errorneous assumption of 8 bit argument widened to 32 bit Message-ID: http://llvm.org/bugs/show_bug.cgi?id=19412 Bug ID: 19412 Summary: Errorneous assumption of 8 bit argument widened to 32 bit Product: clang Version: 3.4 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangbugs at nondot.org Reporter: sebastiangraf at t-online.de CC: llvmbugs at cs.uiuc.edu Classification: Unclassified When using https://github.com/vmt/udis86, I hit this both on my Mac and my Linux PC using clang as compiler targeting x64. To reproduce (python 2.7 is needed as default python, I submitted a pull request to fix that but it wasn't accepted yet): 1. Download the repository 2. $ ./configure --prefix=`pwd`/bin CC="clang" from the root of the repository 3. $ make && make install (will not make if it couldn't use python 2.7 for codegen) 4. Examine ud_set_mode in ./bin/lib/libudis.so with gdb 5. $ gdb ./bin/lib/libudis86.so 6. (gdb) info line ud_set_mode 7. (gdb) x/13i 0x11100 (start of ud_set_mode was 0x11100 for me) This results in the assembly listing for ud_set_mode in ./libudis/udis86.c:86: (gdb) x/13i 0x11100 0x11100 : lea -0x10(%rsi),%eax 0x11103 : cmp $0x30,%eax 0x11106 : ja 0x11120 0x11108 : movabs $0x1000000010001,%rcx 0x11112 : bt %rax,%rcx 0x11116 : jae 0x11120 0x11118 : mov %sil,0x170(%rdi) 0x1111f : retq 0x11120 : movb $0x10,0x170(%rdi) 0x11127 : retq 0x11128: nopl 0x0(%rax,%rax,1) 0x11130 : mov %rsi,0x178(%rdi) 0x11137 : retq Note that the 8 bit argument m is assumed to be 32 bits wide in 0x11103. For completeness sake, the assembly output from udis86.s generated by using clang -S ...: ud_set_mode: # @ud_set_mode .cfi_startproc # BB#0: # kill: ESI ESI RSI leal -16(%rsi), %eax cmpl $48, %eax ja .LBB1_3 # BB#1: movabsq $281474976776193, %rcx # imm = 0x1000000010001 btq %rax, %rcx jae .LBB1_3 # BB#2: movb %sil, 368(%rdi) ret The respective IR: Function Attrs: nounwind uwtable define void @ud_set_mode(%struct.ud* nocapture %u, i8 zeroext %m) #0 { %1 = zext i8 %m to i32 switch i32 %1, label %4 [ i32 16, label %2 i32 32, label %2 i32 64, label %2 ] ;