[llvm-bugs] [Bug 35429] New: Possibly a new diagnostic about strange ternary operator usage
https://bugs.llvm.org/show_bug.cgi?id=35429
Bug ID: 35429
Summary: Possibly a new diagnostic about strange ternary
operator usage
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Given the code:
void test(double *CAM, double coeffs) {
coeffs > 0.0 ? *CAM = 1.0 / coeffs : 0.0;
}
clang does not issue any warning.
The intended code is
void test(double *CAM, double coeffs) {
*CAM = coeffs > 0.0 ? 1.0 / coeffs : 0.0;
}
Perhaps it would be possible to warn on that?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35430] New: [ASan/Win] CHECK failure in allocator
https://bugs.llvm.org/show_bug.cgi?id=35430 Bug ID: 35430 Summary: [ASan/Win] CHECK failure in allocator Product: compiler-rt Version: 5.0 Hardware: PC OS: Windows XP Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: steinar+l...@gunderson.no CC: llvm-bugs@lists.llvm.org Hi, I've got a fairly complicated test in MySQL that causes an internal error in ASan. I'm trying to figure out if there's any information to go on to make a smaller testcase, so I'm sending just the error to try to get the discussion going :-) Please let me know if you can see right away what it is, or in what direction I should try looking. === mysqldump: [Warning] Using a password on the command line interface can be insecure. mysqldump: Got error: 1146: Table 'test.???' doesn't exist when using LOCK TABLES ==21896==AddressSanitizer CHECK failed: C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:755 "((owner_)) == ((GetThreadSelf()))" (0x5394, 0x58e0) ==21896==AddressSanitizer CHECK failed: C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\..\sanitizer_common/sanitizer_allocator_primary64.h:493 "((region->allocated_user)) <= ((region->mapped_user))" (0x2f400, 0x2) #0 0x7ff69cd33f5f in __asan::AsanCheckFailed C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\asan_rtl.cc:69 #0 0x7ff69cd33f5f in __asan::AsanCheckFailed C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\asan_rtl.cc:69 #1 0x7ff69cd1bfbb in __sanitizer::CheckFailed C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_termination.cc:79 #1 0x7ff69cd1bfbb in __sanitizer::CheckFailed C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_termination.cc:79 #2 0x7ff69cd1dae1 in __sanitizer::BlockingMutex::Unlock C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:755 #2 0x7ff69cd4f565 in __sanitizer::SizeClassAllocator64<__asan::AP64>::PopulateFreeArray C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_primary64.h:493 #3 0x7ff69cd4f04c in __sanitizer::SizeClassAllocator64<__asan::AP64>::GetFromAllocator C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_primary64.h:139 #3 0x7ff69cd4ee7e in __sanitizer::SizeClassAllocator64<__asan::AP64>::GetFromAllocator C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_primary64.h:130 #4 0x7ff69cd4edd3 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Refill C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_local_cache.h:110 #4 0x7ff69cd4edd3 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Refill C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_local_cache.h:110 #5 0x7ff69cd4e8f0 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_local_cache.h:50 #5 0x7ff69cd4e8f0 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_local_cache.h:50 #6 0x7ff69cd4e859 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64>,__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >,__sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback,__sanitizer::ReturnNullOrDieOnFailure> >::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_combined.h:62 #6 0x7ff69cd4e859 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64>,__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >,__sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback,__sanitizer::ReturnNullOrDieOnFailure> >::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_allocator_combined.h:62 #7 0x7ff69cd4af5f in __asan::Allocator::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\asan_allocator.cc:424 #7 0x7ff69cd4af5f in __asan::Allocator::Allocate C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\asan_allocator.cc:424 #8 0x7ff69cd4b8c5 in __asan::asan_memalign C:\src\llvm_package_500\llvm\projects\compiler-rt\lib\asan\asan_allocator.cc:855 #8 0x7ff69cd4b8c5 in __asan::asan_memalign C:\src\llvm_package_500\llvm\projects\compiler-rt\lib
[llvm-bugs] [Bug 35431] New: CFI (Control Flow Integrity) emits invalid checks when using std::make_shared (C++11)
https://bugs.llvm.org/show_bug.cgi?id=35431 Bug ID: 35431 Summary: CFI (Control Flow Integrity) emits invalid checks when using std::make_shared (C++11) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: adr...@guinet.me CC: llvm-bugs@lists.llvm.org Created attachment 19477 --> https://bugs.llvm.org/attachment.cgi?id=19477&action=edit test case Hello all, CFI (Control Flow Integrity) generates bad code when std::make_shared is used for C++11 code. The bad code involve a comparaison which will always fail, and jump to the "ud2" instruction (on X86), as if an invalid call (in the CFI sense) would have been made. Using the joint a.cpp file, one can reproduce this using current LLVM trunk (r319014). The bug happens using GNU's libstdc++, with full or thin lto: $ build/bin/clang++ -fsanitize=cfi -fvisibility=hidden -flto=full -O2 a.cpp -fPIC -o a_full -std=c++11 && ./a_full Illegal instruction $ build/bin/clang++ -fsanitize=cfi -fvisibility=hidden -flto=thin -O2 a.cpp -fPIC -o a_thin -std=c++11 && ./a_thin Illegal instruction If we take a look at the assembly generated in both cases, it looks like this: - for a_full: 400850 new_ptr2(void) proc near 400850 pushrbx 400851 mov rbx, rdi 400854 mov edi, 28h 400859 calloperator new(ulong) 40085E mov rcx, 10001h 400868 mov [rax+8], rcx 40086C mov qword ptr [rax], offset off_400C80 400873 mov ecx, offset off_400CC0 400878 cmp [rax+10h], rcx <-- memory at rax+0x10 has never been initialized, this equality is always false! 40087C jnz short loc_40089D 40087E mov rcx, rax 400881 add rcx, 10h 400885 xorps xmm0, xmm0 400888 movups xmmword ptr [rax+18h], xmm0 40088C mov qword ptr [rax+10h], offset off_400CC0 400894 mov [rbx], rcx 400897 mov [rbx+8], rax 40089B pop rbx 40089C retn - for a_thin: 400850 new_ptr2(void) proc near 400850pushrbx 400851mov rbx, rdi 400854mov edi, 28h 400859calloperator new(ulong) 40085Emov rcx, 10001h 400868mov [rax+8], rcx 40086Cmov qword ptr [rax], offset __typeid__ZTSSt23_Sp_counted_ptr_inplaceI2S2SaIS0_ELN9__gnu_cxx12_Lock_policyE2EE_global_addr400873 mov ecx, offset __typeid__ZTSSt23_Sp_counted_ptr_inplaceI2S2SaIS0_ELN9__gnu_cxx12_Lock_policyE2EE_global_addr 400878mov edx, offset __typeid__ZTSSt23_Sp_counted_ptr_inplaceI2S2SaIS0_ELN9__gnu_cxx12_Lock_policyE2EE_global_addr 40087Dcmp rdx, rcx 400880jnz short loc_4008BE 400882mov ecx, offset __typeid__ZTS4Base_global_addr 400887cmp [rax+10h], rcx <-- same here, memory at rax+0x10 has never been initialized, this equality is always false! 40088Bjnz short loc_4008BE 40088Dxorps xmm0, xmm0 400890movups xmmword ptr [rax+18h], xmm0 400894mov qword ptr [rax+10h], offset __typeid__ZTS4Base_global_addr 40089Cmov ecx, offset __typeid__ZTS4Base_global_addr 4008A1mov edx, offset __typeid__ZTS4Base_global_addr 4008A6cmp rdx, rcx 4008A9jnz short loc_4008BE 4008ABmov rcx, rax 4008AEadd rcx, 10h 4008B2mov [rbx], rcx 4008B5mov [rbx+8], rax 4008B9mov rax, rbx 4008BCpop rbx 4008BDretn For the record, this does not happen using LLVM's libc++: $ build/bin/clang++ -fsanitize=cfi -fvisibility=hidden -flto=full -O2 a.cpp -fPIC -o a -std=c++11 -stdlib=libc++ && ./a S2 $ build/bin/clang++ -fsanitize=cfi -fvisibility=hidden -flto=thin -O2 a.cpp -fPIC -o a -std=c++11 -stdlib=libc++ && ./a S2 Question is to know whether this is due to some bug in libstdc++ or a bug in CFI. Note that using the official LLVM 5 release, the bug happens for both C++ libraries, which might point to an actual CFI bug. For the record, this bug has been found while building Clang/LLVM using clang with CFI. This kind of construction (using std::make_shared) exists for instance in clang's RealFileSystem::dir_begin function (in clang/lib/Basic/VirtualFileSystem.cpp). Please let me know if you need further information. Regards, -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34317] wasm32-unknown-unknown-wasm target generated invalid code
https://bugs.llvm.org/show_bug.cgi?id=34317 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dan Gohman --- This is fixed in r317707. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35432] New: clang compilation fails with assertion "Invalid loop count" in Loop Vectorization
https://bugs.llvm.org/show_bug.cgi?id=35432
Bug ID: 35432
Summary: clang compilation fails with assertion "Invalid loop
count" in Loop Vectorization
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails at compilation with Assertion `ExitCount !=
SE.getCouldNotCompute() && "Invalid loop count"'
in 'Loop Vectorization'
= nice.c ==
unsigned int a [192] [192];
int main ()
{
unsigned int i = 0;
unsigned short s = 0;
unsigned char c = 0;
goo(& i);
for (s = i; s <= 63; s += 1)
{
for (c = s; c > i; c--)
++a[0][0];
}
foo(& s);
return 0;
}
===
>>> clang -v
clang version 6.0.0 (trunk 319020)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -c -O0 nice.c
>>> clang -c -O2 nice.c
clang-6.0: llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2126: llvm::Value*
llvm::SCEVExpander::generateOverflowCheck(const llvm::SCEVAddRecExpr*,
llvm::Instruction*, bool): Assertion `ExitCount != SE.getCouldNotCompute() &&
"Invalid loop count"' failed.
#0 0x040b3d7d llvm::sys::PrintStackTrace(llvm::raw_ostream&)
llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x040b3e0e PrintStackTraceSignalHandler(void*)
llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x040b22fa llvm::sys::RunSignalHandlers()
llvm/lib/Support/Signals.cpp:49:0
#3 0x040b3715 SignalHandler(int)
llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x7fbb7b590100 __restore_rt (/lib64/libpthread.so.0+0xf100)
#5 0x7fbb7a1885f7 __GI_raise (/lib64/libc.so.6+0x355f7)
#6 0x7fbb7a189ce8 __GI_abort (/lib64/libc.so.6+0x36ce8)
#7 0x7fbb7a181566 __assert_fail_base (/lib64/libc.so.6+0x2e566)
#8 0x7fbb7a181612 (/lib64/libc.so.6+0x2e612)
#9 0x033dae58
llvm::SCEVExpander::generateOverflowCheck(llvm::SCEVAddRecExpr const*,
llvm::Instruction*, bool) llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2128:0
#10 0x033db77d
llvm::SCEVExpander::expandWrapPredicate(llvm::SCEVWrapPredicate const*,
llvm::Instruction*) llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2209:0
#11 0x033dac75
llvm::SCEVExpander::expandCodeForPredicate(llvm::SCEVPredicate const*,
llvm::Instruction*) llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2101:0
#12 0x033db8c4
llvm::SCEVExpander::expandUnionPredicate(llvm::SCEVUnionPredicate const*,
llvm::Instruction*) llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2234:0
#13 0x033dac28
llvm::SCEVExpander::expandCodeForPredicate(llvm::SCEVPredicate const*,
llvm::Instruction*) llvm/lib/Analysis/ScalarEvolutionExpander.cpp:2096:0
#14 0x041e0307 llvm::InnerLoopVectorizer::emitSCEVChecks(llvm::Loop*,
llvm::BasicBlock*) llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3473:0
#15 0x041e0a10
llvm::InnerLoopVectorizer::createVectorizedLoopSkeleton()
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3623:0
#16 0x041f4197
llvm::LoopVectorizationPlanner::executePlan(llvm::InnerLoopVectorizer&,
llvm::DominatorTree*) llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7561:0
#17 0x041faca5 llvm::LoopVectorizePass::processLoop(llvm::Loop*)
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8926:0
#18 0x041fb15e llvm::LoopVectorizePass::runImpl(llvm::Function&,
llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&,
llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*,
llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&,
std::function&,
llvm::OptimizationRemarkEmitter&)
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9007:0
#19 0x041db6fc (anonymous
namespace)::LoopVectorize::runOnFunction(llvm::Function&)
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2493:0
#20 0x039a29c8 llvm::FPPassManager::runOnFunction(llvm::Function&)
llvm/lib/IR/LegacyPassManager.cpp:1514:0
#21 0x039a2b5b llvm::FPPassManager::runOnModule(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:1535:0
#22 0x039a2ee7 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:1591:0
#23 0x039a35d8 llvm::legacy::PassManagerImpl::run(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:1694:0
#24 0x039a3819 llvm::legacy::PassManager::run(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:1726:0
#25 0x04353435 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:790:0
#26 0x04355bb4 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::
[llvm-bugs] [Bug 35433] New: [AMDGPU][MC][DISASSEMBLER][GFX9] Incorrect decoding of GLOBAL/SCRATCH instructions
https://bugs.llvm.org/show_bug.cgi?id=35433 Bug ID: 35433 Summary: [AMDGPU][MC][DISASSEMBLER][GFX9] Incorrect decoding of GLOBAL/SCRATCH instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Global atomic instructions are decoded incorrectly, e.g. 0x00,0x80,0x08,0xdd,0x02,0x04,0x00,0x00 is decoded as global_atomic_add v[2:3], v4s[0:1] should be: global_atomic_add v[2:3], v4, s[0:1] Also, 13-bit signed offsets in GLOBAL/SCRATCH opcodes are decoded as unsigned, e.g. 0xfc,0x5f,0x68,0xdc,0x00,0x00,0x00,0x00 is decoded as scratch_store_short off, v0, s0 offset:8188 should be: scratch_store_short off, v0, s0 offset:-4096 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35326, which changed state. Bug 35326 Summary: Merge r316181 into the 5.0 branch : AMDGPU: Parse r600 CPU name early and expose FMAF capability https://bugs.llvm.org/show_bug.cgi?id=35326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35326] Merge r316181 into the 5.0 branch : AMDGPU: Parse r600 CPU name early and expose FMAF capability
https://bugs.llvm.org/show_bug.cgi?id=35326 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r316181 |r316181 r319032 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- Merged: r319032 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35434] New: Domain adjustment needs to consider potentially entered loop even if multiple are left
https://bugs.llvm.org/show_bug.cgi?id=35434 Bug ID: 35434 Summary: Domain adjustment needs to consider potentially entered loop even if multiple are left Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: doerf...@cs.uni-saarland.de CC: llvm-bugs@lists.llvm.org Created attachment 19478 --> https://bugs.llvm.org/attachment.cgi?id=19478&action=edit Test case + fix The attached test case (see patch) shows how the domain generation uses domain constraints of a non-related loop if multiple loops are left and one is entered when traversing a single CFG edge. A potential fix is also included in the patch. Unit tests pass but no other testing was performed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35380, which changed state. Bug 35380 Summary: Please backport r316106 to 5.0.1 [lldb-server tests: Fix undefined behavior] https://bugs.llvm.org/show_bug.cgi?id=35380 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35380] Please backport r316106 to 5.0.1 [lldb-server tests: Fix undefined behavior]
https://bugs.llvm.org/show_bug.cgi?id=35380 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|r316106 |r316106 r319035 --- Comment #3 from Tom Stellard --- Merged: r319035 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35435] New: Member access to incomplete type from dllimport
https://bugs.llvm.org/show_bug.cgi?id=35435
Bug ID: 35435
Summary: Member access to incomplete type from dllimport
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zahira.ammarguel...@intel.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
An explicit instantiation request should be ignored when it’s trying to
instantiate a dllimport class.
Reproducer:
class __declspec(dllimport) Edge;
template
class __declspec(dllimport) Range
{
void insert(T *obj) { obj->loc(); }
};
template void Range::insert(Edge *);
ksh-3.2$ clang -c t1.cpp
t1.cpp:10:28: error: member access into incomplete type 'test1::Edge'
void insert(T *obj) { obj->loc(); }
^
t1.cpp:13:28: note: in instantiation of member function
'test1::Range::insert' requested here
template void Range::insert(Edge *);
^
t1.cpp:5:29: note: forward declaration of 'test1::Edge'
class __declspec(dllimport) Edge;
^
t1.cpp:22:28: error: member access into incomplete type 'test2::Edge'
void insert(T* obj) { obj->loc(); }
^
t1.cpp:25:28: note: in instantiation of member function
'test2::Range::insert' requested here
template void Range::insert(Edge *);
^
t1.cpp:17:29: note: forward declaration of 'test2::Edge'
class __declspec(dllexport) Edge;
^
2 errors generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35436] New: [AMDGPU][MC][GFX9] VGPR-offset should be 32 bits for global_* instructions
https://bugs.llvm.org/show_bug.cgi?id=35436 Bug ID: 35436 Summary: [AMDGPU][MC][GFX9] VGPR-offset should be 32 bits for global_* instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org AMD documentation describes two types of addressing supported by global_* instructions: • Memory_addr = VGPR-address + instruction offset. • Memory_addr = SGPR-address + VGPR-offset + instruction offset. Moreover, the documentation states that "VGPR-offset is always 32 bits". See, for example, page 80 of Vega_Shader_ISA_28July2017.pdf However, both SP3 and LLVM assemblers require a pair of registers for VGPR-offset, for example: global_store_dword v[1:2], v4, s[6:7] inst_offset:-1 Is this a bug in AMD documentation or should assembler be corrected? Note that documentation requires 32-bit VGPR-offsets for scratch_* opcodes, and this requirement is met by both assembler implementations. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35437] New: [LLVM-COV] Two continuous "for" statements lead to incorrect coverage information
https://bugs.llvm.org/show_bug.cgi?id=35437
Bug ID: 35437
Summary: [LLVM-COV] Two continuous "for" statements lead to
incorrect coverage information
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 6.0.0-svn318792-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat small.c
int main()
{
int i=0, k=0;
for (; i<1; i++) {
return 0;
}
for (; k<1; k++){
return 1;
}
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov
$ cat small.gcov
1| |int main()
2| 1|{
3| 1|int i=0, k=0;
4| 1|for (; i<1; i++) {
5| 1|return 0;
6| 1|}
7| 1|for (; k<1; k++){
8| 0|return 1;
9| 0|}
10| 1|}
Line #7 is wrongly marked as executed in llvm-cov.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35438] New: std::bitset::bitset(unsigned long long) does not zero unused bits
https://bugs.llvm.org/show_bug.cgi?id=35438
Bug ID: 35438
Summary: std::bitset::bitset(unsigned long long) does not zero
unused bits
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: te...@chromium.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
As per the standard, the std::bitset::bitset(unsigned long long x)
constructor should only take the lowest n bits from the argument, however, the
libc++ implementation stores the argument unchanged in its backing store, which
can be observed by the to_ulong() member function.
Example:
std::bitset<8> x(1000);
printf("%zu\n", x.to_ulong());
This should output 255, but it outputs 1000.
Also, this behavior is different from libstdc++, which is standard compliant in
this case.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35367] Merge r318658 into the 5.0 branch: Fixed OMP doacross implementation on 32-bit platforms.
https://bugs.llvm.org/show_bug.cgi?id=35367 Tom Stellard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Fixed By Commit(s)|r318658 |r318658 r319053 Resolution|--- |FIXED --- Comment #4 from Tom Stellard --- Merged: r319053 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35367, which changed state. Bug 35367 Summary: Merge r318658 into the 5.0 branch: Fixed OMP doacross implementation on 32-bit platforms. https://bugs.llvm.org/show_bug.cgi?id=35367 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35388, which changed state. Bug 35388 Summary: Merge r318848 into the 5.0 branch: Fix for OMP doacross implementation on Power https://bugs.llvm.org/show_bug.cgi?id=35388 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35388] Merge r318848 into the 5.0 branch: Fix for OMP doacross implementation on Power
https://bugs.llvm.org/show_bug.cgi?id=35388 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|r318848 |r318848 r319057 --- Comment #3 from Tom Stellard --- Merged: r319057 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34404] llvm_unreachable in clang::ento::ExprEngine::VisitCommonDeclRefExpr()
https://bugs.llvm.org/show_bug.cgi?id=34404 Artem Dergachev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Artem Dergachev --- Should be fixed by r319055. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34766] Assertion failure in clang::ento::ExprEngine::VisitCompoundLiteralExpr
https://bugs.llvm.org/show_bug.cgi?id=34766 Artem Dergachev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Artem Dergachev --- Should be fixed by r319058. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35438] std::bitset::bitset(unsigned long long) does not zero unused bits
https://bugs.llvm.org/show_bug.cgi?id=35438 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marshall Clow (home) --- > I think it is fair to argue that to_ulong() should output a number smaller > than 2^N. I agree - that's what I was getting at with the comment about "not returning bits that are not part of '*this'" Fixed in revision 319074. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35439] New: lld produces more dynamic relocations in executable than gold
https://bugs.llvm.org/show_bug.cgi?id=35439 Bug ID: 35439 Summary: lld produces more dynamic relocations in executable than gold Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Producing an executable with .global _start _start: retq .section.data.rel.ro,"aw",@progbits .quad foo .quad foo Where foo is defined to be a function in a .so, lld will produce 00202000 00010001 R_X86_64_64 foo + 0 00202008 00010001 R_X86_64_64 foo + 0 gold will produce 00402000 00010007 R_X86_64_JUMP_SLOT 00400220 foo + 0 That is, gold uses the plt hack even when the relocation is applied to a rw section. I don't think lld should do this by default as now there is an unnecessary plt. I am reporting the bug mostly to document a case where lld's output is bigger. We would consider a command line option if someone really needs the size saving. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35440] New: lld's .hash and .gnu.hash are bigger than gold's
https://bugs.llvm.org/show_bug.cgi?id=35440 Bug ID: 35440 Summary: lld's .hash and .gnu.hash are bigger than gold's Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org When linking a clang built clang with gold, the size of the hash sections are [ 5] .gnu.hash GNU_HASH 00e228e0 a228e0 0a626c 00 A 3 0 8 [ 6] .hash HASH 00ec8b50 ac8b50 096898 04 A 3 0 8 with lld the sizes are [ 7] .gnu.hash GNU_HASH 01dcb4c0 1bcb4c0 0b6220 00 A 4 0 8 [ 8] .hash HASH 01e816e0 1c816e0 0ad108 04 A 4 0 4 We probably don't care about .hash, but should at least understand the difference in .gnu.hash. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3652 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in GetDeclSpecTypeForDeclarator
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 3652 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: Stack-overflow in GetDeclSpecTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3652#c1 ClusterFuzz testcase 4526360841158656 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35441] New: AsmParser::parseMSInlineAsm() incorrectly assumes whitespace when rewriting expressions
https://bugs.llvm.org/show_bug.cgi?id=35441
Bug ID: 35441
Summary: AsmParser::parseMSInlineAsm() incorrectly assumes
whitespace when rewriting expressions
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: va...@penzin.net
CC: llvm-bugs@lists.llvm.org
Created attachment 19480
--> https://bugs.llvm.org/attachment.cgi?id=19480&action=edit
Patch against revision 319067
Microsoft C/C++ compiler allows the following syntax:
__asm { mov[foo],2017 }
(Note the absence of whitespace between the opcode "mov" and the left bracket.)
AsmParser::parseMSInlineAsm() rewrites the above fragment as "movdword ptr
$0,$$2017" while the expected result is "mov dword ptr $0,$$2017" (note the
whitespace between the opcode "mov" and the size specifier "dword ptr").
To reproduce the above, please consider the following C source (foo.c):
#include
int
foo ( void )
{
int32_t bar = 0;
__asm {
mov[bar],2017
}
return bar;
}
Please verify generation of the bitcode of the above as follows:
clang-6.0 -S -fasm-blocks -emit-llvm foo.c -o - | grep dword
Please find attached a patch that amends this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33368] DAGCombine incorrecly eliminates vector extension/truncation sequence
https://bugs.llvm.org/show_bug.cgi?id=33368 Wolfgang Pieb changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Wolfgang Pieb --- Fixed with r306345. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31455] [X86][SSE] Slow sqrt libcall branch due to dependency on sqrtsd result
https://bugs.llvm.org/show_bug.cgi?id=31455 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sanjay Patel --- After: https://reviews.llvm.org/rL319094 We should see something like this on x86-64: _sqrt_add: xorps %xmm2, %xmm2 ucomisd %xmm2, %xmm0 # test the arg jb LBB0_2 sqrtsd %xmm0, %xmm0 # not negative, so we're good addsd %xmm1, %xmm0 retq LBB0_2: pushq %rax # defer to libm to set errno movsd %xmm1, (%rsp) callq _sqrt movsd (%rsp), %xmm1 addq$8, %rsp addsd %xmm1, %xmm0 retq -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35393] Windows clang-cl.exe: Unable to compile C++17 code
https://bugs.llvm.org/show_bug.cgi?id=35393 Reid Kleckner changed: What|Removed |Added Resolution|--- |INVALID CC||r...@google.com Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- If you execute clang from a VS 2017 tools prompt this will work as intended. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34129] Add tests
https://bugs.llvm.org/show_bug.cgi?id=34129 Adam Nemet changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Adam Nemet --- https://reviews.llvm.org/rL319073 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35442] New: Merge r319025 into the 5.0 branch : [AMDGPU] Add custom lowering for llvm.log{, 10}.{f16, f32} intrinsics
https://bugs.llvm.org/show_bug.cgi?id=35442
Bug ID: 35442
Summary: Merge r319025 into the 5.0 branch : [AMDGPU] Add
custom lowering for llvm.log{,10}.{f16,f32} intrinsics
Product: new-bugs
Version: 5.0
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ved...@miletic.net
CC: llvm-bugs@lists.llvm.org
Blocks: 34492
Is it OK to merge the following revision(s) to the 5.0 branch?
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=34492
[Bug 34492] [meta] 5.0.1 Release Blockers
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33860] Merge D35387: "[MACH-O] Fix the ASM code generated for __stub_helpers section" to 5.0
https://bugs.llvm.org/show_bug.cgi?id=33860 Lang Hames changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Lang Hames --- Very belatedly LGTM'd. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 33860, which changed state. Bug 33860 Summary: Merge D35387: "[MACH-O] Fix the ASM code generated for __stub_helpers section" to 5.0 https://bugs.llvm.org/show_bug.cgi?id=33860 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35416] "fragment covers entire variable" error in Windows selfhost build
https://bugs.llvm.org/show_bug.cgi?id=35416 Adrian Prantl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Adrian Prantl --- Should be fixed in r319126. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32578] armv7: Assertion failed: (!NodePtr->isKnownSentinel()), function operator*, file include/llvm/ADT/ilist_iterator.h, line 139.
https://bugs.llvm.org/show_bug.cgi?id=32578 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |ma...@braunis.de Resolution|--- |FIXED --- Comment #3 from Matthias Braun --- Thanks for the patch Vedant and sorry for the long delay. Committed in r319130 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35428] WebAssembly backend wrongly exports static functions
https://bugs.llvm.org/show_bug.cgi?id=35428 Chen-Pang He changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Chen-Pang He --- Thanks for your explanation. I used to compile with clang -c tgammaf.c Hence the static functions were exported. Now I compile with clang -nostdlib -Wl,--allow-undefined tgammaf.c Then static functions are generated but not exported, which is good. Where is your project? I found jfbastien/musl before, which implements many C routines in JavaScript. Therefore, I'm trying a different approach: build from scratch avoid dependency on JavaScript or Linux as possible. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35064] Crash in WebAssembly register allocation
https://bugs.llvm.org/show_bug.cgi?id=35064 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dan Gohman --- Fixed in r319144. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
