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