[llvm-bugs] [Bug 25995] New: Unqualified lookup into dependent bases of class templates fails if class exists with the same name
https://llvm.org/bugs/show_bug.cgi?id=25995 Bug ID: 25995 Summary: Unqualified lookup into dependent bases of class templates fails if class exists with the same name Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: jva...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15545 --> https://llvm.org/bugs/attachment.cgi?id=15545&action=edit Reproduction Full reproduction in attachment, created with default console application in visual studio 2013. The code that works with MSVC, does not compile with clang-cl. In short, we have a templated class 'Wrapper', a base class which defines Wrapper as Wrapper and some template arguments and a Derived class which tries to use this. If the typedef and usages would be renamed to TWrapper, all compiles. Though in this case we both have a class called Wrapper and the typedef called Wrapper, where an other one gets chosen than what MSVC does. -- 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 25996] New: weak symbols fail on Windows
https://llvm.org/bugs/show_bug.cgi?id=25996
Bug ID: 25996
Summary: weak symbols fail on Windows
Product: new-bugs
Version: 3.7
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: klamer.schu...@tno.nl
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Having the code:
$ cat main.cpp
#include
__attribute__((weak)) int fn()
{
return 0;
}
int main(int argc, char *argv[])
{
printf("%d\n", fn());
return 0;
}
$ cat fn.cpp
int fn()
{
return 42;
}
fails to compile on Windows for both msvc and gnu toolchains:
$ /c/prog64/LLVM/bin/clang++ -v main.cpp fn.cpp
clang version 3.7.0 (trunk 234109)
Target: x86_64-pc-windows-msvc
Thread model: posix
"c:\\prog64\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
main.cpp -mrelocation-model pic -pic-level 2 -mthre
ad-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info
-resource-dir "c:\\prog64\\LLVM\\bin\\..\\lib\\clang\
\3.7.0" -internal-isystem
"c:\\prog64\\LLVM\\bin\\..\\lib\\clang\\3.7.0\\include" -internal-isystem
"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include"
-internal-isystem "C:\\Program
Files (x86)\\Windows Kits\\8.1\\include\\shared" -internal-isystem "C:\\Program
Files (x86)\\Windows Kits\\8.1\\include\\um" -internal-isystem "C:\\Program
Files (x86)\\Windows Kits\\8.1\\include\\win
rt" -std=c++11 -fdeprecated-macro -fdebug-compilation-dir "c:\\tmp"
-ferror-limit 19 -fmessage-length 200 -mstackrealign -fms-extensions
-fms-compatibility -fms-compatibility-version=18 -fno-threadsaf
e-statics -fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
"C:/Users/schuttek/AppData/Local/Temp\\main-2b9d52.o" -x c++ main
.cpp
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn-r234109 default target
x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
c:\prog64\LLVM\bin\..\lib\clang\3.7.0\include
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
C:\Program Files (x86)\Windows Kits\8.1\include\shared
C:\Program Files (x86)\Windows Kits\8.1\include\um
C:\Program Files (x86)\Windows Kits\8.1\include\winrt
End of search list.
"c:\\prog64\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
fn.cpp -mrelocation-model pic -pic-level 2 -mthread
-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info
-resource-dir "c:\\prog64\\LLVM\\bin\\..\\lib\\clang\\3
.7.0" -internal-isystem "c:\\prog64\\LLVM\\bin\\..\\lib\\clang\\3.7.0\\include"
-internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio
12.0\\VC\\include" -internal-isystem "C:\\Program Fi
les (x86)\\Windows Kits\\8.1\\include\\shared" -internal-isystem "C:\\Program
Files (x86)\\Windows Kits\\8.1\\include\\um" -internal-isystem "C:\\Program
Files (x86)\\Windows Kits\\8.1\\include\\winrt
" -std=c++11 -fdeprecated-macro -fdebug-compilation-dir "c:\\tmp" -ferror-limit
19 -fmessage-length 200 -mstackrealign -fms-extensions -fms-compatibility
-fms-compatibility-version=18 -fno-threadsafe-
statics -fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
"C:/Users/schuttek/AppData/Local/Temp\\fn-f9cbfd.o" -x c++ fn.cpp
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn-r234109 default target
x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
c:\prog64\LLVM\bin\..\lib\clang\3.7.0\include
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
C:\Program Files (x86)\Windows Kits\8.1\include\shared
C:\Program Files (x86)\Windows Kits\8.1\include\um
C:\Program Files (x86)\Windows Kits\8.1\include\winrt
End of search list.
"C:\\Program Files (x86)\\Microsoft Visual Studio
12.0\\VC\\bin\\amd64\\link.exe" -out:a.exe -defaultlib:libcmt
"-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio
12.0\\VC\\lib\\amd64" "-libp
ath:C:\\Program Files (x86)\\Windows Kits\\8.1\\Lib\\winv6.3\\um\\x64" -nologo
"C:/Users/schuttek/AppData/Local/Temp\\main-2b9d52.o"
"C:/Users/schuttek/AppData/Local/Temp\\fn-f9cbfd.o"
fn-f9cbfd.o : error LNK2005: "int __cdecl fn(void)" (?fn@@YAHXZ) already
defined in main-2b9d52.o
a.exe : fatal error LNK1169: one or more multiply defined symbols found
clang++.exe: error: linker command failed with exit code 1169 (use -v to see
invocation)
$ clang++ -m64 -v main.cpp fn.cpp
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-p
[llvm-bugs] [Bug 25997] New: [WinEH] no-return function in cleanup code not called with -O
https://llvm.org/bugs/show_bug.cgi?id=25997
Bug ID: 25997
Summary: [WinEH] no-return function in cleanup code not called
with -O
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r.sagita...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This code:
#include
#include
struct Cleanup
{
~Cleanup()
{
puts("abort");
exit(42);
}
};
void test()
{
try
{
Cleanup a;
throw int(3);
}
catch(int)
{
}
}
int main(int argc, char** argv)
{
test();
}
compiles and runs correctly (prints "abort" and has exit code 42) when built
with "clang -fexceptions -m32". Adding "-O" to the command line causes the
program to crash.
The C++ code itself seems questionable, but other languages support arbitrary
code in "finally" blocks, e.g. throwing another exception.
The IR for the test function:
define void @"\01?test@@YAXXZ"() #0 personality i8* bitcast (i32 (...)*
@__CxxFrameHandler3 to i8*) {
entry:
%a = alloca %struct.Cleanup, align 1
%tmp = alloca i32, align 4
store i32 3, i32* %tmp, align 4
%0 = bitcast i32* %tmp to i8*
invoke void @_CxxThrowException(i8* %0, %eh.ThrowInfo* @_TI1H) #4
to label %unreachable unwind label %ehcleanup
ehcleanup:; preds = %entry
%1 = cleanuppad within none []
call x86_thiscallcc void @"\01??1Cleanup@@QAE@XZ"(%struct.Cleanup* %a) #5 [
"funclet"(token %1) ]
cleanupret from %1 unwind label %catch.dispatch
catch.dispatch: ; preds = %ehcleanup
%2 = catchswitch within none [label %catch] unwind to caller
catch:; preds = %catch.dispatch
%3 = catchpad within %2 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i8*
null]
catchret from %3 to label %catchret.dest
catchret.dest:; preds = %catch
br label %try.cont
try.cont: ; preds = %catchret.dest
ret void
unreachable: ; preds = %entry
unreachable
}
The problem here is that the optimizer infers "noreturn" from the cleanup call
and replaces "cleanupret" with "unreachable":
define void @"\01?test@@YAXXZ"() #0 personality i8* bitcast (i32 (...)*
@__CxxFrameHandler3 to i8*) {
entry:
%a = alloca %struct.Cleanup, align 1
%tmp = alloca i32, align 4
%0 = getelementptr inbounds %struct.Cleanup, %struct.Cleanup* %a, i32 0, i32
0
call void @llvm.lifetime.start(i64 1, i8* %0) #6
store i32 3, i32* %tmp, align 4, !tbaa !4
%1 = bitcast i32* %tmp to i8*
invoke void @_CxxThrowException(i8* %1, %eh.ThrowInfo* nonnull @_TI1H) #7
to label %unreachable unwind label %ehcleanup
ehcleanup:; preds = %entry
%2 = cleanuppad within none []
call x86_thiscallcc void @"\01??1Cleanup@@QAE@XZ"(%struct.Cleanup* nonnull
%a) #6 [ "funclet"(token %2) ]
unreachable
unreachable: ; preds = %entry
unreachable
}
This seems to break the funclet extraction mechanism for the Windows exception
handling.
--
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 25998] New: lib/CodeGen/MachineInstr.cpp: 3 * misleading formatting ?
https://llvm.org/bugs/show_bug.cgi?id=25998 Bug ID: 25998 Summary: lib/CodeGen/MachineInstr.cpp: 3 * misleading formatting ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified 1. /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1741:31: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] if (!HaveSemi) OS << ";"; HaveSemi = true; ^~~~ /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1741:5: note: ...this ‘if’ clause, but it is not if (!HaveSemi) OS << ";"; HaveSemi = true; ^~ 2. /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1752:31: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] if (!HaveSemi) OS << ";"; HaveSemi = true; ^~~~ /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1752:5: note: ...this ‘if’ clause, but it is not if (!HaveSemi) OS << ";"; HaveSemi = true; ^~ 3. /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1765:31: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] if (!HaveSemi) OS << ";"; HaveSemi = true; ^~~~ /home/dcb/llvm/trunk/llvm/lib/CodeGen/MachineInstr.cpp:1765:5: note: ...this ‘if’ clause, but it is not if (!HaveSemi) OS << ";"; HaveSemi = true; ^~ -- 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 25999] New: spec2000/188.ammp, spec2006/433.milc, 444.namd, 447.dealII, 453.povray compilation fails on LTO stage after commit r256394
https://llvm.org/bugs/show_bug.cgi?id=25999 Bug ID: 25999 Summary: spec2000/188.ammp, spec2006/433.milc, 444.namd, 447.dealII, 453.povray compilation fails on LTO stage after commit r256394 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: sergey.k.oku...@gmail.com CC: david.l.kreit...@intel.com, denis.bri...@intel.com, elena.demikhov...@intel.com, llvm-bugs@lists.llvm.org, sergos@gmail.com, spatel+l...@rotateright.com, zia.ans...@intel.com Classification: Unclassified Bisect analysis showed LLVM revision 256394 is responsible for the fails. The comments to commit are the following. commit 75759ab3e9255fe5f716e4a71ca1ee56901dedf8 Author: Sanjay Patel Date: Thu Dec 24 21:17:56 2015 + [InstCombine] transform more extract/insert pairs into shuffles (PR2109) This is an extension of the shuffle combining from r203229: http://reviews.llvm.org/rL203229 The idea is to widen a short input vector with undef elements so the existing shuffle transform for extract/insert can kick in. The motivation is to finally solve PR2109: https://llvm.org/bugs/show_bug.cgi?id=2109 For that example, the IR becomes: %1 = bitcast <2 x i32>* %P to <2 x float>* %ld1 = load <2 x float>, <2 x float>* %1, align 8 %2 = shufflevector <2 x float> %ld1, <2 x float> undef, <4 x i32> %i2 = shufflevector <4 x float> %A, <4 x float> %2, <4 x i32> ret <4 x float> %i2 And x86 SSE output improves from: movq(%rdi), %xmm1 ## xmm1 = mem[0],zero movdqa %xmm1, %xmm2 shufps $229, %xmm2, %xmm2 ## xmm2 = xmm2[1,1,2,3] shufps $48, %xmm0, %xmm1 ## xmm1 = xmm1[0,0],xmm0[3,0] shufps $132, %xmm1, %xmm0 ## xmm0 = xmm0[0,1],xmm1[0,2] shufps $32, %xmm0, %xmm2 ## xmm2 = xmm2[0,0],xmm0[2,0] shufps $36, %xmm2, %xmm0 ## xmm0 = xmm0[0,1],xmm2[2,0] retq To the almost optimal: movhpd (%rdi), %xmm0 Note: There's a tension in the existing transform related to generating arbitrary shufflevector masks. We avoid that in other places in InstCombine because we're scared that codegen can't handle strange masks, but it looks like we're ok with producing those here. I purposely chose weird insert/extract indexes for the regression tests to see the effect in these cases. For PowerPC+Altivec, AArch64, and X86+SSE/AVX, I think the codegen is equal or better for these examples. Differential Revision: http://reviews.llvm.org/D15096 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256394 91177308-0d34-0410-b5e6-96231b3b80d8 LLVM-clang options: -m64 -fuse-ld=gold -Ofast -funroll-loops -flto -static -mfpmath=sse -march=core-avx2 During LTO phase spec benchmarks fail with the following error message (e.g., spec2006/444.namd). runspec --config=lnx-x86_64-clang-default.cfg --rebuild -a build -e ref64 -T base 444 clang++ -m64 -m64 -fuse-ld=gold -Ofast -funroll-loops -flto -static -mfpmath=sse -march=core-avx2 -DSPEC_CPU_LP64Compute.o ComputeList.o ComputeNonbondedUtil.o LJTable.o Molecule.o Patch.o PatchList.o ResultSet.o SimParameters.o erf.o spec_namd.o -o namd Instruction does not dominate all uses! %782 = extractelement <2 x double> %721, i32 1 %779 = insertelement <4 x double> undef, double %782, i32 0 Instruction does not dominate all uses! %1053 = extractelement <2 x double> %974, i32 1 %1050 = insertelement <4 x double> undef, double %1053, i32 0 Instruction does not dominate all uses! %1332 = shufflevector <2 x double> %1263, <2 x double> undef, <4 x i32> %1330 = shufflevector <4 x double> %1329, <4 x double> %1332, <4 x i32> LLVM ERROR: Broken function found, compilation aborted! clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) specmake: *** [namd] Error 1 Okunev Sergey, Software Engineer Intel Compiler Team -- 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 25998] lib/CodeGen/MachineInstr.cpp: 3 * misleading formatting ?
https://llvm.org/bugs/show_bug.cgi?id=25998 Yaron Keren changed: What|Removed |Added Status|NEW |RESOLVED CC||yaron.ke...@gmail.com Resolution|--- |FIXED --- Comment #1 from Yaron Keren --- r256688 -- 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 26000] New: [WinEH] asserting loop optimizations with captured variables
https://llvm.org/bugs/show_bug.cgi?id=26000
Bug ID: 26000
Summary: [WinEH] asserting loop optimizations with captured
variables
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: r.sagita...@gmx.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compile this code with "clang -m32 -fexceptions -c -O":
struct string
{
string(const char*s);
const char* ptr;
};
bool adEq2(string& s1);
void checkContent(string s)
{
string old = s;
auto fail = [&]()
{
s = old;
};
try
{
while (s.ptr != 0)
{
old = s;
if (adEq2(s)) { }
}
}
catch(int e)
{
fail();
}
}
Result:
Assertion failed: Val && "isa<> used on a null pointer", file
C:\s\d\ldc\llvm\include\llvm/Support/Casting.h, line 95
It does not happen without optimizations or when compiling with -m64.
Bugpoint reports a broken function after the -licm pass, here is the IR to
reproduce:
; ModuleID = 'bugpoint-reduced-instructions.bc'
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i386-pc-windows-msvc18.0.0"
%rtti.TypeDescriptor2.0.2.4.6.8.22 = type { i8**, i8*, [3 x i8] }
%struct.string.1.3.5.7.9.23 = type { i8* }
@"\01??_7type_info@@6B@" = external constant i8*
@"\01??_R0H@8" = external global %rtti.TypeDescriptor2.0.2.4.6.8.22
define void @"\01?checkContent@@YAXUstring@@@Z"(%struct.string.1.3.5.7.9.23*
byval align 4 %s) #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to
i8*) {
entry:
br label %while.cond
while.cond: ; preds = %while.body, %entry
%0 = ptrtoint i8* undef to i32
br i1 undef, label %try.cont, label %while.body
while.body: ; preds = %while.cond
%call = invoke zeroext i1
@"\01?adEq2@@YA_NAAUstring@@@Z"(%struct.string.1.3.5.7.9.23* nonnull
dereferenceable(4) %s)
to label %while.cond unwind label %catch.dispatch
catch.dispatch: ; preds = %while.body
%1 = catchswitch within none [label %catch] unwind to caller
catch:; preds = %catch.dispatch
%2 = catchpad within %1 [%rtti.TypeDescriptor2.0.2.4.6.8.22* @"\01??_R0H@8",
i32 0, i32* undef]
store i32 %0, i32* undef, align 4
catchret from %2 to label %try.cont
try.cont: ; preds = %catch, %while.cond
ret void
}
; Function Attrs: argmemonly nounwind
declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture readonly,
i32, i32, i1) #1
declare zeroext i1 @"\01?adEq2@@YA_NAAUstring@@@Z"(%struct.string.1.3.5.7.9.23*
dereferenceable(4)) #0
declare i32 @__CxxFrameHandler3(...)
attributes #0 = { "disable-tail-calls"="false" "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="pentium4"
"target-features"="+fxsr,+mmx,+sse,+sse2" "unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { argmemonly nounwind }
!llvm.ident = !{!0}
!0 = !{!"clang version 3.8.0 "}
--
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 25997] [WinEH] no-return function in cleanup code not called with -O
https://llvm.org/bugs/show_bug.cgi?id=25997
David Majnemer changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||david.majne...@gmail.com,
||r...@google.com
Resolution|--- |WONTFIX
--- Comment #1 from David Majnemer ---
Thanks for the excellent bug report!
This seems to be a quirk in the behavior of MSVC's personality routine.
C++17 [except.handle]p9 says:
If no matching handler is found, the function std::terminate() is called;
whether or not the stack is unwound before this call to std::terminate() is
implementation-defined.
Clang has decided that your catch handler is not a matching handler because it
is dynamically unreachable.
Here is an example which doesn't rely on clang-cl. clang, gcc and icc give the
following code different behavior depending on the optimization level:
extern "C" void __attribute__((nothrow, noreturn)) exit(int);
struct S {
~S() { exit(1); }
};
void f() {
S s;
throw 0;
}
void g() {
try {
f();
} catch (...) {
}
}
int main() { g(); }
--
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 26001] New: [clang-cl] error: "asm operand has incomplete type" on boost::atomic
https://llvm.org/bugs/show_bug.cgi?id=26001
Bug ID: 26001
Summary: [clang-cl] error: "asm operand has incomplete type" on
boost::atomic
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: heavenandhell...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang is failing to compile this:
#include
int main() {
boost::atomic counter;
counter.store(0, boost::memory_order_relaxed);
return 0;
}
This is one of the errors i'm getting:
../boost_1_60_0\boost/atomic/detail/ops_msvc_x86.hpp(640,26) : error: asm
operand has incomplete type 'volatile storage_type *' (aka 'volatile typename
make_storage_type<8U, Signed>::type *')
mov edx, p
^
The snippet is a reduced test case i extracted from a library. It can be built
with the following command (there's no need to build boost):
clang-cl Tmp.cpp -Ic:\boost_1_60_0\
Note, the error only happen with 64 bit integers, if i change the type to
int32_t or long, there's no error.
--
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 26002] New: cc_kext configuration wants InstrProfilingWriter linked in
https://llvm.org/bugs/show_bug.cgi?id=26002 Bug ID: 26002 Summary: cc_kext configuration wants InstrProfilingWriter linked in Product: compiler-rt Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: pump...@me.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'm not 100% sure about this, but when I try to link xnu (the Darwin kernel, at http://opensource.apple.com/source/xnu/xnu-3248.20.55/) with a libclang_rt.cc_kext produced from compiler-rt (SVN 256647) it complains about a missing llvmBufferWriter (and a couple of other related symbols). I noticed that in CompilerRTDarwinUtils.cmake, PROFILE_SOURCES doesn't include InstrProfilingWriter. If I add InstrProfilingWriter to that list, the linker issue goes away (except it still complains about memcpy_chk/memset_chk, but I that's likely unrelated). -- 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 26003] New: sanitizer lint checks fail on Ubuntu
https://llvm.org/bugs/show_bug.cgi?id=26003 Bug ID: 26003 Summary: sanitizer lint checks fail on Ubuntu Product: compiler-rt Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: axw...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'm running "check-all" with compiler-rt in my tree, and I get the following error: cd "/home/andrew/projects/debian/llvm-toolchain-snapshot-3.8~svn254193/build-llvm/projects/compiler-rt/lib" && "LLVM_CHECKOUT=/home/andrew/projects/debian/llvm-toolchain-snapshot-3.8~svn254193" SILENT=1 TM PDIR= PYTHON_EXECUTABLE=/usr/bin/python "COMPILER_RT=/home/andrew/projects/debian/llvm-toolchain-snapshot-3.8~svn254193/projects/compiler-rt" "/home/andrew/projects/debian/llvm-toolchain-snapshot-3.8~svn25 4193/projects/compiler-rt/lib/sanitizer_common/scripts/check_lint.sh" /bin/sh: 1: LLVM_CHECKOUT=/home/andrew/projects/debian/llvm-toolchain-snapshot-3.8~svn254193: not found Pretty sure this is because /bin/sh is dash on Ubuntu, and the env-var prefix thing is a bashism. -- 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 26004] New: clang hangs on valid code at -O1 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=26004
Bug ID: 26004
Summary: clang hangs on valid code at -O1 on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following test case causes the current clang trunk to hang when compiling
at -O1 in both 32-bit and 64-bit modes on x86_64-linux-gnu.
It is a regression from 3.7.x.
$ clang-trunk -v
clang version 3.8.0 (trunk 256693)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.2.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-trunk -O0 -c small.c
$ clang-trunk -Os -c small.c
$ clang-3.7.0 -O1 -c small.c
$
$ timeout -s 9 10 clang-trunk -O1 -c small.c
Killed
$
--
int a, b = 1;
void
fn1 ()
{
a++;
}
void
fn2 ()
{
if (b)
lbl:
b = 0;
fn1 ();
if (b)
goto lbl;
}
--
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 26005] New: scan-build fails to find C++ STL headers
https://llvm.org/bugs/show_bug.cgi?id=26005 Bug ID: 26005 Summary: scan-build fails to find C++ STL headers Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: rjwa...@durables.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15546 --> https://llvm.org/bugs/attachment.cgi?id=15546&action=edit Output files. Using scan-build from checker-277, I can't build my c++ files. I get this error: $ ~/Desktop/checker-277/scan-build make scan-build: Using '/Users/rjwalsh/Desktop/checker-277/bin/clang' for static analysis /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icebox python3 icebox_chipdb.py > chipdb-1k.new mv chipdb-1k.new chipdb-1k.txt python3 icebox_chipdb.py -8 > chipdb-8k.new mv chipdb-8k.new chipdb-8k.txt /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icepack /Users/rjwalsh/Desktop/checker-277/libexec/c++-analyzer -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include -c -o icepack.o icepack.cc icepack.cc:19:10: fatal error: 'set' file not found #include ^ 1 error generated. icepack.cc:19:10: fatal error: 'set' file not found #include ^ 1 error generated. /Users/rjwalsh/Desktop/checker-277/libexec/ccc-analyzer icepack.o -lm -lstdc++ -o icepack ln -sf icepack iceunpack /Applications/Xcode.app/Contents/Developer/usr/bin/make -C iceprog /Users/rjwalsh/Desktop/checker-277/libexec/ccc-analyzer -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/Cellar/libftdi/1.2/include/libftdi1 -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -c -o iceprog.o iceprog.c /Users/rjwalsh/Desktop/checker-277/libexec/ccc-analyzer iceprog.o -L/usr/local/Cellar/libftdi/1.2/lib -L/usr/local/Cellar/libusb/1.0.20/lib -lftdi1 -lusb-1.0 -lm -o iceprog /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icemulti /Users/rjwalsh/Desktop/checker-277/libexec/c++-analyzer -MD -O0 -ggdb -Wall -std=c++11 -c -o icemulti.o icemulti.cc icemulti.cc:17:10: fatal error: 'fstream' file not found #include ^ 1 error generated. icemulti.cc:17:10: fatal error: 'fstream' file not found #include ^ 1 error generated. /Users/rjwalsh/Desktop/checker-277/libexec/ccc-analyzer icemulti.o -lm -lstdc++ -o icemulti # /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icetime scan-build: 0 bugs found. scan-build: The analyzer encountered problems on some source files. scan-build: Preprocessed versions of these sources were deposited in '/var/folders/59/t04m219n3xd322k9sv2gfmm4gn/T/scan-build-2016-01-02-214517-1185-1/failures'. scan-build: Please consider submitting a bug report using these files: scan-build: http://clang-analyzer.llvm.org/filing_bugs.html -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
