search for: declspec

Hi all, I am trying to use llvm-gcc to link shared libraries on windows/mingw32. When I try to link libraries that contain functions declared with __declspec(dllexport) someFunction(); I get the link error: Cannot export _someFunction: symbol not found Removing the declspec directive solves the problem, but this is not a very feasible solution for me. Using 'regular' gcc does not have this problem. Should I consider this a bug? Thanks,...

> I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > When I try to link libraries that contain functions declared with >  __declspec(dllexport) someFunction(); > > I get the link error: > >  Cannot export _someFunction: symbol not found dllexport declspec should be put on the function definition, in this example there is nothing to export - dllexport without function body is meaningless. -- With best regards, Anton...

...115.html ). I think the wonderful feature of the MinGW/Cygwin ld is the option --enable-auto-import. The option is limited to COFF, but LINK.exe doesn't have it. Could we add the feature to lld-link ? If it is possible, many people will change the coding pattern for using DLL. -- no more if-def declspec(dllimport) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160318/b9537b22/attachment.html>

...-fcolor-diagnostics -vectorize-loops -vectorize-slp -o /home/kpawar/SAFECode/LLVM_SRC/llvm/projects/safecode/tools/clang/lib/Parse/Release+Asserts/Parser.o -x c++ tools/clang/lib/Parse/Parser.cpp 1. /home/kpawar/SAFECode/LLVM_SRC/llvm/projects/safecode/tools/clang/lib/Parse/../../include/clang/Sema/DeclSpec.h:855:3: current parser token 'SourceLocation' 2. /home/kpawar/SAFECode/LLVM_SRC/llvm/projects/safecode/tools/clang/lib/Parse/../../include/clang/Sema/DeclSpec.h:38:1: parsing namespace 'clang' 3. /home/kpawar/SAFECode/LLVM_SRC/llvm/projects/safecode/tools/clang/lib/Parse/../../incl...

...lved and no .linkonce discard directive is needed. I would name it dllimport_inline or something similar. While it makes sense to mimic MSVC behavior and MSDN doc for C++ codes, it is not very clear to me what should be the correct semantics when a C99 inline function carries a dllimport/dllexport declspec. For example, inline __declspec(dllimport) int foo() { return 100; } extern inline int foo(); Currently clang ignores the dllimport attribute, so what's left will be: inline int foo() { return 100; } extern inline int foo(); // this declaration demands an out-of-line definition The second de...

...rror LNK2005: _WatchCursor already defined in cursors.obj R.lib(R.dll) : error LNK2005: _ArrowCursor already defined in cursors.obj R.lib(R.dll) : error LNK2005: _R_Interactive already defined in main.obj I have tried just about everything I can think of (including the obvious commenting out the declspec dllimport statements in cursors.c) - to no avail. Actually that works but it's a desperate hack and causes the app to crash later on! I've run out of ideas and I would appreciate a new set of eyes looking at this to see what I'm obviously doing wrong. PS: I am compiling with MSDev...

I've got an example where I think that there should be some loop-invariant optimization happening, but it's not. Here's the C code: #define DIM 8 #define UNROLL_DIM DIM typedef double InArray[DIM][DIM]; __declspec(noalias) void f1( InArray c, const InArray a, const InArray b ) { #pragma clang loop unroll_count(UNROLL_DIM) for( int i=0;i<DIM;i++) #pragma clang loop unroll_count(UNROLL_DIM) for( int j=0;j<DIM;j++) #pragma clang loop unroll_count(UNROLL_DIM) for( int k=0;k<DIM...

...I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but take this class as an example: struct __declspec(dllexport/dllimport) X { X() {} }; Such constructs with empty or simple inline functions can be found for example in Microsoft headers or even libc++ headers. Ignoring the dllexport/import attribute for such functions would seem most sensible (and can be implemented easily), but MSVC does t...

...had to modify the definition of the classes and functions that I need in order to have something like: class LLVM_EXPORT Compilation { . }; rather than class Compilation { . }; with LLVM_EXPORT being defined as: #ifdef _WIN32 #ifdef BUILD_LLVM #define LLVM_EXPORT __declspec(dllexport) #else #define LLVM_EXPORT __declspec(dllimport) #endif #else #define LLVM_EXPORT #endif Now, as I mentioned before, that approach works fine up to LLVM+Clang 3.5.1, but it fails with LLVM+Clang 3.6. Not for all the classes/functions that I need to export/imp...

...39;-GL' > In file included from perllib.c:10: > In file included from ..\lib\CORE\perl.h:3060: > In file included from .\win32thread.h:4: > ./win32.h(284,25) : error: 'selectany' can only be applied to data items > with external linkage > That line is: extern const __declspec(selectany) union { unsigned __int64 __q; double __d; } __PL_nan_u = { 0x7FF8000000000000UI64 }; If it's written like so, clang-cl accepts it: union U { unsigned __int64 __q; double __d; }; extern const __declspec(selectany) U __PL_nan_u = { 0x7FF8000000000000UI64 }; I guess cl.exe applies the...

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you don't put __declspec(dllexport) / __declspec(dllimport) on the > code, but macros that...

Hi, On Linux I observed [root at localhost poolalloc]# find . -name *.a ./Release+Asserts/lib/LLVMDataStructure.a ./Release+Asserts/lib/poolalloc.a ./Release+Asserts/lib/AssistDS.a ./Release+Asserts/lib/libpoolalloc_fl_rt.a ./Release+Asserts/lib/libpoolalloc_rt.a ./Release+Asserts/lib/libpa_pre_rt.a ./Release+Asserts/lib/libcount.a On cygwin I observed kpawar at KPAWAR-LT

...from perllib.c:10: >> In file included from ..\lib\CORE\perl.h:3060: >> In file included from .\win32thread.h:4: >> ./win32.h(284,25) : error: 'selectany' can only be applied to data items >> with external linkage >> > > That line is: > extern const __declspec(selectany) union { unsigned __int64 __q; double > __d; } __PL_nan_u = { 0x7FF8000000000000UI64 }; > > If it's written like so, clang-cl accepts it: > union U { unsigned __int64 __q; double __d; }; > extern const __declspec(selectany) U __PL_nan_u = { 0x7FF8000000000000UI64 > }...

...e function. The visible global state is the set of all data that is not defined or referenced outside of the compilation scope, and their address is not taken." Phil On Thu, Nov 17, 2016 at 9:50 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > If I understood it correctly, __declspec(noalias) is not the same as > specifying restrict on each parameter. > > > > It means in the mentioned example a, b & c don't modify or reference any > global state, but they are free to alias one another. > > > > You could specify restrict on each one to indic...

...gt; > increase parallelism in the build or larger projects or operating > systems. > > My experience is that headers don't necessarily form the best source of > truth about the API exported from a library. If you follow the Windows > model of marking exported APIs explicitly (declspec(dllexport) or > something) > then okay, but that's a Windows extension and not common in other systems. > Linker scripts seem to be a more popular method; does the tool read linker > scripts to form the content of a TBD file? > Otherwise I'm not seeing a generic improvement i...

...In file included from ..\lib\CORE\perl.h:3060: >>> In file included from .\win32thread.h:4: >>> ./win32.h(284,25) : error: 'selectany' can only be applied to data >>> items with external linkage >>> >> >> That line is: >> extern const __declspec(selectany) union { unsigned __int64 __q; double >> __d; } __PL_nan_u = { 0x7FF8000000000000UI64 }; >> >> If it's written like so, clang-cl accepts it: >> union U { unsigned __int64 __q; double __d; }; >> extern const __declspec(selectany) U __PL_nan_u = { >>...

...finitions during codegen (this means they survived the inliner) and dropping their body. > While it makes sense to mimic MSVC behavior and MSDN doc for C++ codes, it is > not very clear to me what should be the correct semantics when a C99 inline function > carries a dllimport/dllexport declspec. [...] > An alternative is to generate an error message whenever a C99 inline function is used > with a dllimport/dllexport declspec. I agree. This should be rejected. > In a similar manner, I wonder what should be the correct semantics of: > inline __declspec(dllexport) int foo() { r...

...ture sessions, > more akin a conventional compiler. > I'm interested in something like that. I have a case (which seems similar to one experienced by Nick Capens) where I have a lot of pure functions (Functions that only reference first-level indirections of their input parameters, a-la declspec(noalias) in VC++) that I'd like to store and avoid re-generating. There were some issues with constants being pooled by the execution engine iirc, but if there're plans to implement what Oscar's thinking of I'd love to be in on it. - Sherief

> > I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > > When I try to link libraries that contain functions declared with > >  __declspec(dllexport) someFunction(); > > > > I get the link error: > > > >  Cannot export _someFunction: symbol not found > dllexport declspec should be put on the function definition, in this > example there is nothing to export - dllexport without function body > is meaning...

...rror LNK2005: _WatchCursor already defined in cursors.obj R.lib(R.dll) : error LNK2005: _ArrowCursor already defined in cursors.obj R.lib(R.dll) : error LNK2005: _R_Interactive already defined in main.obj I have tried just about everything I can think of (including the obvious commenting out the declspec dllimport statements in cursors.c) - to no avail. Actually that works but it's a desperate hack and causes the app to crash later on! I've run out of ideas and I would appreciate a new set of eyes looking at this to see what I'm obviously doing wrong. PS: I am compiling with MSDev...