[llvm-bugs] [Bug 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 26354, which changed state. Bug 26354 Summary: regression: Compilation hangs with -O2 -mavx for certain input (valid code) https://llvm.org/bugs/show_bug.cgi?id=26354 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 26354] regression: Compilation hangs with -O2 -mavx for certain input (valid code)
https://llvm.org/bugs/show_bug.cgi?id=26354 Elias Pipping changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Elias Pipping --- This fixes the problem for me. :) Thanks a lot to David Majnemer for the reduction! Thanks a lot to Sanjay Patel for the fix! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26391] New: Invalid defs/uses of the FPSW register after register allocation
https://llvm.org/bugs/show_bug.cgi?id=26391
Bug ID: 26391
Summary: Invalid defs/uses of the FPSW register after register
allocation
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: david.majne...@gmail.com, jswe...@arxan.com,
k...@freebsd.org, llvm-bugs@lists.llvm.org,
ma...@braunis.de, qcolom...@apple.com
Depends on: 21903
Classification: Unclassified
+++ This bug was initially created as a clone of Bug #21903 +++
According to Matthias Braun, this test case is probably exposing a slightly
different problem with the internal representation. Minimized C++ test case:
int x0, x1, x2;
double x3, x4;
int x5(double x6, double x7) {
if (x4 && x6 < x7)
x0 = 1;
else
x0 = 0;
return x0;
}
void x8(double x6, double x7, bool &x9, double x10, double x11) {
if (x2 == 0)
x9 = 0;
if (x2 == 1 && x5(x1, 0) && x5(x6, 0) && x5(x7, x11))
x9 = 1;
if (x2 == 6)
x9 = 0;
if (x2 == 7 && x5(x1, x3) && x5(x6, x10) && x5(x7, x11))
x9 = 1;
}
Reproduce with: clang -cc1 -triple i386 -emit-obj -target-cpu i686 -O2 -w
testcase.cpp
Resulting in:
*** Bad machine code: MBB exits via conditional branch/fall-through but the CFG
successors don't match the actual successors! ***
- function:_Z2x8ddRbdd
- basic block: BB#2 land.lhs.true (0x7fa392846b38)
*** Bad machine code: Using an undefined physical register ***
- function:_Z2x8ddRbdd
- basic block: BB#5 land.lhs.true14 (0x7fa392846ea8)
- instruction: FNSTSW16r
- operand 1: %FPSW
*** Bad machine code: Using an undefined physical register ***
- function:_Z2x8ddRbdd
- basic block: BB#11 land.lhs.true14 (0x7fa392846be8)
- instruction: %EAX = MOVZX32rr8
- operand 1: %AL
*** Bad machine code: Using an undefined physical register ***
- function:_Z2x8ddRbdd
- basic block: BB#11 land.lhs.true14 (0x7fa392846be8)
- instruction: %EDX = MOV32rm
- operand 1: %EDX
fatal error: error in backend: Found 4 machine code errors.
Further reduced to .ll form by David Majnemer, to:
target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
target triple = "i686--linux-gnu"
define void @f(double %p1, double %p2, double %p3, double %p4, i32 %p5, i8*
%p6, double %p7, double %p8, double %p9) align 2 {
entry:
%cmp.i54 = fcmp olt double %p2, %p8
%tobool.i45 = fcmp une double %p4, 0.00e+00
switch i32 %p5, label %if.end20 [
i32 0, label %if.then10
i32 1, label %land.lhs.true
i32 2, label %if.then10
i32 4, label %land.lhs.true13
]
land.lhs.true:; preds = %entry
br i1 undef, label %land.lhs.true3, label %if.end20
land.lhs.true3: ; preds = %land.lhs.true15,
%land.lhs.true
br i1 %cmp.i54, label %land.lhs.true5, label %if.end20
land.lhs.true5: ; preds = %land.lhs.true3
%cmp.i50 = fcmp olt double %p3, %p9
br i1 %cmp.i50, label %if.then10, label %if.end20
if.then10:; preds = %land.lhs.true5,
%entry, %entry
store i8 1, i8* %p6, align 1
br label %if.end20
land.lhs.true13: ; preds = %entry
%cmp.i46 = fcmp olt double %p1, %p7
%or.cond.i47 = and i1 %tobool.i45, %cmp.i46
%storemerge.i48 = zext i1 %or.cond.i47 to i32
br i1 %or.cond.i47, label %land.lhs.true15, label %if.end20
land.lhs.true15: ; preds = %land.lhs.true13
%storemerge.i44 = zext i1 %cmp.i54 to i32
br label %land.lhs.true3
if.end20: ; preds = %land.lhs.true13,
%if.then10, %land.lhs.true5, %land.lhs.true3, %land.lhs.true, %entry
ret void
}
--
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 26392] New: Polly requires additional linkages on darwin
https://llvm.org/bugs/show_bug.cgi?id=26392
Bug ID: 26392
Summary: Polly requires additional linkages on darwin
Product: Polly
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Other
Assignee: polly-...@googlegroups.com
Reporter: howarth.mailing.li...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The Polly shared library requires additional linkages on darwin. The current
linkage in lib/CMakeLists.txt is limited to
if (BUILD_SHARED_LIBS)
target_link_libraries(Polly
LLVMSupport
LLVMCore
LLVMScalarOpts
LLVMInstCombine
LLVMTransformUtils
LLVMAnalysis
LLVMipo
LLVMMC
)
link_directories(
${LLVM_LIBRARY_DIR}
)
endif()
However darwin requires the additional linkages of...
LLVMBitReader
LLVMMCParser
LLVMObject
LLVMProfileData
LLVMTarget
LLVMVectorize
as the darwin requires all of the weak undefined symbols in a library to be
resolved when linking it against an executable (unless
-Wl,-undefined,dynamic_lookup is used to override the default behavior of
-Wl,-undefined,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 26393] New: -DLLVM_LINK_LLVM_DYLIB:BOOL=ON produces many llvm test suite regressions
https://llvm.org/bugs/show_bug.cgi?id=26393 Bug ID: 26393 Summary: -DLLVM_LINK_LLVM_DYLIB:BOOL=ON produces many llvm test suite regressions Product: Build scripts Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: howarth.mailing.li...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Building llvm/clang/compiler-rt/polly/libc++/openmp with -DLLVM_LINK_LLVM_DYLIB:BOOL=ON on x86_64 results in many llvm test suite regressions. Expected Passes: 7605 Expected Failures : 51 Unsupported Tests : 3841 Unexpected Failures: 3853 These all seem to be some variation of opt reporting an unknown command line argument being passed to it such as... FAIL: LLVM :: Analysis/BasicAA/2003-02-26-AccessSizeTest.ll (1 of 15350) TEST 'LLVM :: Analysis/BasicAA/2003-02-26-AccessSizeTest.ll' FAILED Script: -- gtimeout 1m /sw/src/fink.build/llvm39-3.9.0-1/build/stage3/./bin/opt < /sw/src/fink.build/llvm39-3.9.0-1/llvm-3.9.0.src/test/Analysis/BasicAA/2003-02-26-AccessSizeTest.ll -basicaa -gvn -instcombine -S | /sw/src/fink.build/llvm39-3.9.0-1/build/stage3/./bin/FileCheck /sw/src/fink.build/llvm39-3.9.0-1/llvm-3.9.0.src/test/Analysis/BasicAA/2003-02-26-AccessSizeTest.ll -- Exit Code: 2 Command Output (stderr): -- opt: Unknown command line argument '-basicaa'. Try: '/sw/src/fink.build/llvm39-3.9.0-1/build/stage3/./bin/opt -help' opt: Did you mean '-passes'? opt: Unknown command line argument '-gvn'. Try: '/sw/src/fink.build/llvm39-3.9.0-1/build/stage3/./bin/opt -help' opt: Did you mean '-Os'? opt: Unknown command line argument '-instcombine'. Try: '/sw/src/fink.build/llvm39-3.9.0-1/build/stage3/./bin/opt -help' opt: Did you mean '-print-options'? FileCheck error: '-' is empty. -- -- 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 26394] New: libclang python bindings discard index when creating a TranslationUnit
https://llvm.org/bugs/show_bug.cgi?id=26394
Bug ID: 26394
Summary: libclang python bindings discard index when creating a
TranslationUnit
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: andrej.lajo...@ad-vega.si
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I was testing the python bindings for libclang and I noticed that the following
example crashes:
test.py:
--
import clang.cindex
tu = clang.cindex.TranslationUnit.from_source('test.c')
tu.reparse()
print tu.cursor()
--
The file 'test.c' must exist, but can be empty. The expected result is that
clang would create a translation unit and then reparse it immediately. But the
actual result is this:
--
$ python2 test.py
LIBCLANG FATAL ERROR: unknown module format
libclang: crash detected during reparsing
Segmentation fault
--
I believe that I know what the problem is. When the classmethod
clang.cindex.TranslationUnit.from_source() is called, it creates an index and a
little while later passes it to the constructor:
> if index is None:
> index = Index.create()
> [...]
> return cls(ptr, index=index)
However, the constructor only checks that the index is indeed a valid Index
object, but does not store it in any way (I am omitting the documentation
string and empty lines for brevity):
> def __init__(self, ptr, index):
> assert isinstance(index, Index)
> ClangObject.__init__(self, ptr)
As a consequence, after TranslationUnit.from_source() terminates, the index has
a reference count of zero and it is destroyed by python's garbage collector. I
believe that this is not something that should happen. Indeed, if I insert
self.index = index
just after the assert clause, my little snippet in test.py starts to work as
expected.
Can somebody involved in python bindings take a look at this, please? I have
only started to dabble with clang about a day ago and I am not confident enough
to propose a definite solution.
--
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 26395] New: Analyzer says undefined behavior in uniform_int_distribution
https://llvm.org/bugs/show_bug.cgi?id=26395
Bug ID: 26395
Summary: Analyzer says undefined behavior in
uniform_int_distribution
Product: libc++
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jared.gr...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The clang static analyzer flags this code as having undefined behavior. Note
that if I change "size_t" to "unsigned" then things look fine. It looks like
the engine is 32-bit but it's going to try a 64-bit shift maybe? I'm totally
guessing here.
.../c++/v1/algorithm:2920
warning: The result of the '>>' expression is undefined
__mask0_ = __w0_ > 0 ? _Engine_result_type(~0) >> (_EDt - __w0_) :
^
To reproduce:
$ cat x.cpp
#include
#include
size_t genRandom(size_t maxValue) {
std::minstd_rand engine;
std::uniform_int_distribution dist{0, maxValue};
return dist(engine);
}
$ clang++ x.cpp -std=c++14 --analyze
--
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 26396] New: [3.8 regression] -Wreturn-stack-address false positives
https://llvm.org/bugs/show_bug.cgi?id=26396
Bug ID: 26396
Summary: [3.8 regression] -Wreturn-stack-address false
positives
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: l...@bobbyperu.info
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Since very recently we're getting false-positive -Wreturn-stack-address
warnings:
template
class QMap
{
public:
T value(const T &t = T()) const
{
return t;
}
};
struct A {};
void test()
{
QMap map;
map.value();
}
$ clang++ testcase.cpp -c
testcase.cpp:7:16: warning: returning address of local temporary object
[-Wreturn-stack-address]
--
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 26397] New: Missing debug info if address sanitizer is in use: "no symbol in current context"
https://llvm.org/bugs/show_bug.cgi?id=26397 Bug ID: 26397 Summary: Missing debug info if address sanitizer is in use: "no symbol in current context" Product: clang Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: k...@ruggedinbox.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15767 --> https://llvm.org/bugs/attachment.cgi?id=15767&action=edit minimal program souce that reproduces the problem Hello everyone, I hope I am reporting this the right way. Please excuse me if this bug has been reported or even fixed already, but I could only try this with the pre-compiled clang 3.7.1 binary on Ubuntu 14.04 (amd64). It seems like clang is emitting binaries with faulty or missing debug information in some cases when address sanitizer is used. The attached file (main.cpp) provides a minimal example. If compiled with clang++ -fsanitize=address -o testcase -g -O0 main.cpp gdb (version 7.10.1) is unable to print the value of variable `i`. In particular, if one tries to run gdb testcase -ex "b main.cpp:6" -ex r -ex "p i" then gdb reports: No symbol "i" in current context. If one compiles without the `-fsanitize=address` option, gdb prints a value for i. Please let me know in case you need more information. -- 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 26398] New: Regression: -Wnull-dereference (part of -Wall) even applies to expressions that are not evaluated.
https://llvm.org/bugs/show_bug.cgi?id=26398
Bug ID: 26398
Summary: Regression: -Wnull-dereference (part of -Wall) even
applies to expressions that are not evaluated.
Product: clang
Version: 3.8
Hardware: PC
OS: other
Status: NEW
Severity: release blocker
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: e...@80386.nl
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I just upgraded from LLVM+Clang 3.7.1 to LLVM+Clang 3.8.0rc1 and I noticed that
the following code now generates a compiler warning/error:
$ cat bla.c
#define some_generic_function(x) \
_Generic(*(x), \
int: some_generic_function_int)(x)
static int *some_generic_function_int(int *x) {
return x;
}
void some_function(void);
void some_function(void) {
some_generic_function((int *)0);
}
$ x86_64-unknown-cloudabi-cc -O3 -Wall -Werror bla.c
bla.c:11:3: error: indirection of non-volatile null pointer will be deleted,
not trap [-Werror,-Wnull-dereference]
some_generic_function((int *)0);
^~~
bla.c:2:14: note: expanded from macro 'some_generic_function'
_Generic(*(x), \
^~~~
bla.c:11:3: note: consider using __builtin_trap() or qualifying pointer with
'volatile'
bla.c:2:14: note: expanded from macro 'some_generic_function'
_Generic(*(x), \
^
1 error generated.
The warning should obviously not trigger in this case; the expression passed to
_Generic() is not evaluated. This is also not an uncommon construct. With
_Generic() you often want to match a type without any cv-qualifiers on the
pointer type. Dereferencing the expression is an easy way to get rid of those.
--
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 26399] New: Lit fails some tests when PATH has quoted paths
https://llvm.org/bugs/show_bug.cgi?id=26399 Bug ID: 26399 Summary: Lit fails some tests when PATH has quoted paths Product: Test Suite Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: test35...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15768 --> https://llvm.org/bugs/attachment.cgi?id=15768&action=edit An example of the output in a failing condition In TestRunner.py, _executeShCmd (at line 292) fails when PATH has quoted paths in it: if not executable: executable = lit.util.which(args[0], cmd_shenv.env['PATH']) if not executable: raise InternalShellError(j, '%r: command not found' % j.args[0]) ...and well, the commands invoked are a bit problematic: Command invoked: env "PATH=C:\LLVM\build\tools\clang\test\Driver\Output;C:/LLVM/build/Debug/bin;C:/LLVM/build/Debug/bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin;C:\Program Files (x86)\Windows Kits\10\bin\x86;;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\tools;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\ide;C:\Program Files (x86)\HTML Help Workshop;;C:\Program Files (x86)\MSBuild\14.0\bin\;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\;C:\WINDOWS\SysWow64;;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\NativeBinaries\x86;C:\Program Files (x86)\Python35-32\Scripts\;C:\Program Files (x86)\Python35-32\;C:\Fossil;C:\Tcl\bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files\CollabNet\Subversion Client;C:\Python34\;C:\Python27\;C:\Python34\Scripts;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\PharosSystems\Core;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\gtk\bin;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Universal Extractor;C:\Program Files (x86)\Universal Extractor\bin;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\chromium_workspace\depot_tools;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Windows Phone TShell\;C:\Program Files (x86)\CMake\bin;C:\Program Files\TortoiseHg\;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Python27\;C:\Python33\;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;%JAVA_HOME%\bin;C:\Python33\Scripts;C:\Program Files (x86)\Nmap; C:\Windows\System32\wbin\;C:\wbin;"C:\Users\Alexander Riccio\AppData\Local\nasm";" C:/LLVM/build/Debug/bin/clang.EXE -target x86_64-scei-ps4 C:\LLVM\llvm\tools\clang\test\Driver\ps4-linker-win.c -### 2>&1| C:/LLVM/build/Debug/bin\FileCheck.EXE --check-prefix=CHECK-PS4-LINKER C:\LLVM\llvm\tools\clang\test\Driver\ps4-linker-win.c Output: 59> Command 2: "Riccio\AppData\Local\nasm;" "C:/LLVM/build/Debug/bin/clang.EXE" "-target" "x86_64-scei-ps4" "C:\LLVM\llvm\tools\clang\test\Driver\ps4-linker-win.c" "-fuse-ld=gold" "-###" 59> Command 2 Result: 127 59> Command 2 Output: 59> 59> 59> Command 2 Stderr: 59> 'Riccio\\AppData\\Local\\nasm;': command not found ...which causes a test to fail. -- 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 26400] New: [CUDA] cannot find matching tex2D
https://llvm.org/bugs/show_bug.cgi?id=26400
Bug ID: 26400
Summary: [CUDA] cannot find matching tex2D
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: wujing...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
texture texA;
__global__ void readTexels(float* d_out) {
float4 v = tex2D(texA, 0.0f, 0.0f);
*d_out = v.x + v.y + v.z + v.w;
}
$ clang++ texture.cu -c --cuda-gpu-arch=sm_35
texture.cu:4:14: error: no matching function for call to 'tex2D'
float4 v = tex2D(texA, 0.0f, 0.0f);
^
/usr/local/cuda/include/texture_indirect_functions.h:522:39: note: candidate
template ignored: couldn't infer template argument 'T'
__TEXTURE_INDIRECT_FUNCTIONS_DECL__ T tex2D(cudaTextureObject_t texObject,
float x, float y)
...
nvcc can compile this file. The declaration of the matching tex2D is in
texture_fetch_functions.h, and its definition is in
texture_fetch_functions.hpp.
--
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 26401] New: undefined reference to boost::gregorian::greg_month::get_month_map_ptr()
https://llvm.org/bugs/show_bug.cgi?id=26401 Bug ID: 26401 Summary: undefined reference to boost::gregorian::greg_month::get_month_map_ptr() Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: 565434...@qq.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15769 --> https://llvm.org/bugs/attachment.cgi?id=15769&action=edit compiler errors clang++ -std=c++11 -I /home/liukai/local/include/boost SceneServer.cpp -o SceneServer -L/home/liukai/local/lib -lboost_date_time always was failure. SceneServer/SceneServer.cpp.1.o: In function `unsigned short boost::date_time::month_str_to_ushort(std::__cxx11::basic_string, std::allocator > const&)': /home/liukai/local/include/boost/date_time/date_parsing.hpp:67: undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()' clang: error: linker command failed with exit code 1 (use -v to see invocation) But I changed 'clang++' to 'gcc' that displayed successfully. Who can tell me why? -- 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
