Re: [cfe-users] Unexpected include directories when cross-compiling
> Another thing I noticed occurs when using the -sysroot option. clang then > tries to use $sysroot/usr/include. In my oppinion it should use > $sysroot/include instead. I could be wrong here, but --sysroot and --isysroot (with some hand waiving) means use /usr/include to find headers and /usr/lib to find libraries. That is, --sysroot and --isysroot point to the top or root of the tree. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Replacement for -fdevirtualize?
Hi Everyone, I'm catching a warning when trying to use -fdevirtualize under Clang. $ make /usr/local/bin/clang++ -DNDEBUG -g -O2 -fdevirtualize -march=native -c eax.cpp clang: warning: optimization flag '-fdevirtualize' is not supported ... I believe its equivalent to Microsoft's __declspec(novtable), and I believe/know Clang supports the MS platform. Does Clang offer an equivalent flag? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Integrated assembler, -arch i386 and ILP32
Hi Everyone, We took a bug report on some line assembly code (https://github.com/weidai11/cryptopp/issues/72). I have two questions at the end on Clang, Apple and ILP32. The code performs the following: asm volatile ( // save ebx in case -fPIC is being used // TODO: this might need an early clobber on EDI. # if BOOL_X32 || BOOL_X64 "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx" # else "push %%ebx; cpuid; mov %%ebx, %%edi; pop %%ebx" # endif : "=a" (output[0]), "=D" (output[1]), "=c" (output[2]), "=d" (output[3]) : "a" (input), "c" (0) ); BOOL_X32 is set when __ILP32__ is defined. BOOL_X86 is defined when __i386__ (and friends) is defined. BOOL_X64 is defined when __x86_64__ (and friends) is defined. We set the conditions based on " System V Application Binary Interface, AMD64 (With LP64 and ILP32 Programming Models)", http://sites.google.com/site/x32abi/documents/abi.pdf. The compiler error is: $ make cpu.o clang++ -DNDEBUG -g2 -O2 -arch i386 -fPIC -march=native -pipe -c cpu.cpp cpu.cpp:104:4: error: register %rbx is only available in 64-bit mode "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx" ^ :1:8: note: instantiated into assembly here pushq %rbx; cpuid; mov %ebx, %edi; popq %rbx ^ cpu.cpp:104:4: error: register %rbx is only available in 64-bit mode "pushq %%rbx; cpuid; mov %%ebx, %%edi; popq %%rbx" ^ :1:42: note: instantiated into assembly here pushq %rbx; cpuid; mov %ebx, %edi; popq %rbx ^~~~ 2 errors generated. It appears Clang sets ILP32 related defines when using -arch i386: $ clang++ -arch i386 -dM -E - < /dev/null | egrep -i "(86|64|ilp)" #define _ILP32 1 #define __ILP32__ 1 ... #define __i386 1 #define __i386__ 1 #define i386 1 As far as I know, when using ILP32, we must interact with the stack using 64-bit values. My first question is, is _ILP32_ and _i386_ supposed to be defined together? According to the docs I found, its not an expected/legal configuration. _ILP32_ and _x86_64_ is an expected/legal configuration. My second question is, how should I work around this? Should I special case Clang on Apple and attempt to push a 32-bit value? Or should I do something else? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Integrated assembler, -arch i386 and ILP32
> BOOL_X32 is set when __ILP32__ is defined. BOOL_X86 is defined when > __i386__ (and friends) is defined. BOOL_X64 is defined when __x86_64__ > (and friends) is defined. We set the conditions based on " System V > Application Binary Interface, AMD64 (With LP64 and ILP32 Programming > Models)", http://sites.google.com/site/x32abi/documents/abi.pdf. Forgot to mention I believe "OS X ABI Function Call Guide" [1] is Apple's controlling document, but it does not mention the define. Jeff [1] http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/Mac_OS_X_ABI_Function_Calls.pdf ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Integrated Assembler, JNZ and "unknown token in expression"
Hi Everyone, I'm catching a compile error with some inline assembly under Clang 3.4 provided by Ubuntu 14.04 LTS. The compile error is shown below (with macro expansion), but the essence is "JNZ 1b;" is producing "error: unknown token in expression". Any ideas how I can work around the issue? Thanks in advance. ** clang++ -DNDEBUG -g2 -O2 -fPIC -march=native -pipe -c gcm.cpp gcm.cpp:812:3: error: unknown token in expression ASJ(jnz,1, ... ^ ./cpu.h:272:23: note: expanded from macro 'ASJ' #define ASJ(x, y, z) GNU_ASJ(x, y, z) ^ ./cpu.h:266:27: note: expanded from macro 'GNU_ASJ' #define GNU_ASJ(x, y, z) #x " " #y #z ";" NEW_LINE ^ :297:2: note: expanded from here "jnz" ^ :69:7: note: instantiated into assembly here jnz 1b; ^ ** This particular code block uses Intel syntax, but the problem is not encountered until the JNZ is encountered. This may be related: "LLVM Bug 24232 - [X86] Inline assembly operands don't work with .intel_syntax", http://llvm.org/bugs/show_bug.cgi?id=24232 . But I can only say "may" because hundreds of other lines of Intel syntax are fine. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] How to enable Initialization Order Fiasco sanitizer from the command line?
Hi Everyone, We have a C++ library and a test script that grinds though various configurations. It include various sanitizers. The script is a security gate, and the self tests must pass for a release. I want to add the Initialization Order Fiasco sanitizer as a command line option, and not a envar export. There are some reasons for it, like a positive confirmation the option exists and explicit invocation of the checker. How do I enable Initialization Order Fiasco sanitizer from the command line? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Does Integrated Assembler need Output Operands listed as Clobbered?
We have a user reporting a crash under Apple's Clang 7.0.2. The code is: __asm__ volatile( #if BOOL_X64 || BOOL_X32 ".byte 0x48, 0x0f, 0xc7, 0xf0;\n" // rdrand rax #else ".byte 0x0f, 0xc7, 0xf0;\n"// rdrand eax #endif "setc %1; " : "=a" (val), "=qm" (rc) : : "cc" ); The byte instructions are the op-codes for 'rdrand' instruction. Apple Clang was late to provide them, so we have an implementation regardless of downlevel compilers. They are also available for downlevel GCC compilers in a hosted environment where the iron provides a modern CPU. The same user reports adding EAX or RAX as a clobber clears the issue. Does Clang's Integrated Assembler need Output Operands listed as Clobbered? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] How to detect LLVM Visual Studio Toolset on Windows?
We took a bug report for LLVM Visual Studio Toolset on Windows. It appears LLVM defines _MSC_VER but it cannot consume the same programs that Microsoft's compilers can. We now have to figure out a way to detect Clang in this configuration and work around its shortcomings. The "Getting Started with the LLVM System using Microsoft Visual Studio" points us to the FAQ at http://llvm.org/docs/FAQ.html. The FAQ does not discuss how to detect the configuration or the preprocessor macros that are in effect. How do we detect LLVM Visual Studio Toolset on Windows? ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] How to detect LLVM Visual Studio Toolset on Windows?
On Sun, Mar 13, 2016 at 3:42 PM, Csaba Raduly wrote:
> Hi Jeffrey,
>
> Have you tried checking for __clang__ ?
Thanks Csaba.
The user stated the toolchain does not define some of the familiar
ones, like __clang__. From
http://github.com/weidai11/cryptopp/issues/147:
This toolset defines MSC_VER as 1600
__clang__ macro is not defined
I trying to get a dump of the preprocessor now to confirm it ('clang++
-dM -E - < NULL').
Jeff
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] C/C++ system include dirs when cross-compiling
On Thu, Mar 24, 2016 at 11:48 AM, Arnaud Allard de Grandmaison via cfe-users wrote: > Hi Patrick, > > This is a common case when cross compiling, so clang knows how to use a > gcc-toolchain installation: you just have to pass it the "--sysroot=..." and > "--toolchain=..." arguments, and it will get the header files and linker / > assembler for your target --- assuming your gcc-toolchain has a standard > layout. That last caveat is the one that gives me the most trouble on Ubuntu. They seem to have an odd layout for their ARM-HF toolchain, and using --sysroot fails to compile/link. Also see "g++-arm-linux-gnueabi cannot compile a C++ program with --sysroot", http://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armel-cross/+bug/1375071. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] C/C++ system include dirs when cross-compiling
On Thu, Mar 31, 2016 at 11:50 AM, Patrick Boettcher via cfe-users wrote: > Hi, > > On Thu, 24 Mar 2016 16:48:30 +0100 > Arnaud Allard de Grandmaison wrote: > >> Hi Patrick, >> >> This is a common case when cross compiling, so clang knows how to use >> a gcc-toolchain installation: you just have to pass it the >> "--sysroot=..." and "--toolchain=..." arguments, and it will get the >> header files and linker / assembler for your target --- assuming your >> gcc-toolchain has a standard layout. > > I'm getting back to you after (some vacations and) having compared > linaro's latest toolchain to the one I built. > > Linaro provides a sysroot-package which does not contain > c++-header-files. Instead they are located in the gcc-package, as in > my package, in > > /include/c++// > > I'm unable to convince clang(++) to include this search-dir using any > combination of the following options with variations on the path name. > > --gcc-toolchain= > -B > --sysroot= > > sysroot works a little bit, but only for c-include which are located in > /usr/include. > > Using gcc-linaro-5.3-2016.02-x86_64_aarch64-elf I would highly > appreciate an example of how to invoke clang++ for cross-compilation > with this gcc and its includes? > > My current try is: > > TARGET=aarch64-elf \ > GCC_ROOT=~/Downloads/gcc-linaro-5.3-2016.02-x86_64_aarch64-elf \ > ~/devel/upstream/build/bin/clang++ \ > -v \ > --target=$TARGET \ > --gcc-toolchain=$GCC_ROOT/$TARGET \ > --sysroot=$GCC_ROOT/$TARGET/sysroot \ > -nostdlib \ > -o testCCompiler.cpp.obj -c \ > -std=c++11 \ > test.cpp > > test.cpp is empty except #include which it doesn't find. > > Linaro's gcc has all include paths in its search list. > > Thanks in advance for any help, We found Ubuntu (perhaps Debian) broke the cross-compile using --sysroot some time ago. Also see "g++-arm-linux-gnueabi cannot compile a C++ program with --sysroot", https://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armel-cross/+bug/1375071. We were working around the broken C++ header includes by specifically calling them out with -I. See the comment "Fix C++ header paths for Ubuntu" at https://github.com/weidai11/cryptopp/blob/master/setenv-embedded.sh#L96. ARM's "GCC ARM Embedded Tools" works as expected. Its maintained by ARM employees. Also see the PPA at https://launchpad.net/gcc-arm-embedded. Since the time of the Launchpad bug report, the linker no longer works, either. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] C/C++ system include dirs when cross-compiling
>> We were working around the broken C++ header includes by specifically >> calling them out with -I. See the comment "Fix C++ header paths for >> Ubuntu" at >> https://github.com/weidai11/cryptopp/blob/master/setenv-embedded.sh#L96. > > That's what I did as well to work around. > >> ARM's "GCC ARM Embedded Tools" works as expected. Its maintained by >> ARM employees. Also see the PPA at >> https://launchpad.net/gcc-arm-embedded. > > Yeah, but is the problem clang not looking into the right paths or > gcc-toolchains having changed their layouts. Comparing older > gcc-toolchains I had in my attic it seems that clang is not looking hard > enough. It sounds like a Clang bug. If you can reduce it to a minimal test case, consider filing a bug report. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] How to check for std::atomic availability?
I'm having trouble parsing docs like http://llvm.org/releases/3.3/tools/clang/docs/LanguageExtensions.html and http://clang.llvm.org/docs/LanguageExtensions.html. I see there's a 'has_feature(c_atomic)'. Its not quite what I am looking for. How do I check for the availability of c++ atomic so I can use: std::atomic_thread_fence(std::memory_order_acq_rel); Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] When did Clang provide C++11 mutex?
I'm having trouble determining feature availability at compile time. We don't use Autotools and friends; rather, we use the preprocessor. I've been through the release notes from 2.8 through 3.5 (form: ), and I can't find mention of mutex. I've also been to the latest docs, and I can't find a __has_feature(cxx_mutex) or similar (http://clang.llvm.org/docs/LanguageExtensions.html). Finally, I visited http://clang.llvm.org/cxx_status.htmlbut there is no topic or item for mutex. There is a statement "Clang 3.3 and later implement all of the ISO C++ 2011 standard", so I guess that's the version I should use in the absence of better information. When did Clang provide C++11 mutex? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] When did Clang provide C++11 mutex?
>> I'm having trouble determining feature availability at compile time. >> We don't use Autotools and friends; rather, we use the preprocessor. >> >> I've been through the release notes from 2.8 through 3.5 (form: ), and >> I can't find mention of mutex. Whoops... here was the form: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html. >> I've also been to the latest docs, and I can't find a >> __has_feature(cxx_mutex) or similar >> (http://clang.llvm.org/docs/LanguageExtensions.html). >> >> Finally, I visited http://clang.llvm.org/cxx_status.htmlbut there is >> no topic or item for mutex. There is a statement "Clang 3.3 and later >> implement all of the ISO C++ 2011 standard", so I guess that's the >> version I should use in the absence of better information. > > std::mutex is not a feature of the compiler (clang). It is a feature > of the C++ Standard Library (libcxx). > > You should look for the header. If the following compiles, > then mutex should be available: Oh, that's a good point; thanks. That should work for both LLVM Clang and Apple Clang (mostly same tool; different versioning schemes). Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang Analyzer: false positive or am I missing something?
On Sat, Jun 25, 2016 at 2:01 PM, Andrew Fuller via cfe-users
wrote:
> I'm trying to understand an issue reported by Clang's static analysis tool.
> The code below demonstrates the issue:
>
> $ cat problem.c
> #include
>
> int main() {
> #if VARIANT==1
>uint32_t data = 0xdeadbeef;
>uint8_t* byte = (uint8_t*)&data;
>uint8_t value = byte[0];
> #elif VARIANT==2
>uint32_t data = 0xdeadbeef;
>uint8_t* byte = (uint8_t*)&data;
>uint8_t value = byte[1];
> #elif VARIANT==3
>uint32_t data[1] = {0xdeadbeef};
>uint8_t* byte = (uint8_t*)&data[0];
>uint8_t value = byte[0];
> #elif VARIANT==4
>uint32_t data[1] = {0xdeadbeef};
>uint8_t* byte = (uint8_t*)&data[0];
>uint8_t value = byte[1];
> #else
> #error "Define VARIANT={1,2,3,4}"
> #endif
>return value;
> }
>
I recall seeing this before, but I don't recall if its valid C:
uint8_t* byte = (uint8_t*)&data;
uint8_t value = byte[0];
Are you getting other compiler warnings with it? If not, try -Wall -Wextra.
Jeff
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Use of undeclared identifier '_tzcnt_u64'
Hi Everyone,
We got a user report of a compile failure using Apple's Clang. I don't
know the exact Apple Clang version at the moment. Its on OS X 10.11,
and its probably the one bundled with the latest Xcode.
Here's the error report
(https://groups.google.com/forum/#!topic/cryptopp-users/BI8yGpr2XNo):
misc.h:675:23: error: use of undeclared identifier '_tzcnt_u64'
misc.h:790:22: error: use of undeclared identifier '_blsr_u64';
did you mean '__blsr_u32'?
Here's the code in question from misc.h (from
http://github.com/weidai11/cryptopp/blob/master/misc.h):
#if defined(__GNUC__) && defined(__BMI__)
return (unsigned int)_tzcnt_u64(v);
#elif defined(__GNUC__) && (GCC_VERSION >= 30400)
return (unsigned int)__builtin_ctzll(v);
#elif ...
#endif
And from misc.h (from http://github.com/weidai11/cryptopp/blob/master/misc.h):
#if defined(__GNUC__) && defined(__BMI__)
template <>
inline bool IsPowerOf2(const word64 &value)
{
return value > 0 && _blsr_u64(value) == 0;
}
#endif
I believe both symbols are available in
http://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined&text=_blsr_u64&expand=421):
#if defined(__GNUC__) && defined(__BMI__)
#include
#endif
Given __BMI__ is defined, why are we catching the "undeclared identifier" error?
Thanlk in advance/
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Use of undeclared identifier '_tzcnt_u64'
We needed this goodness for Clang. Its another case of Clang
pretending to be another compiler, but failing to consume a program.
The frustrating thing is, we have dedicated code paths for Clang,
including inline assembly that works around its integrated assembler
bugs. If Clang would stop pretending to be other compilers, then
things would "just work".
#if defined(__GNUC__) && defined(__BMI__)
# include
+# if defined(__clang__)
+# define _tzcnt_u32(x) __tzcnt_u32(x)
+# define _tzcnt_u64(x) __tzcnt_u64(x)
+# define _blsr_u32(x) __blsr_u32(x)
+# define _blsr_u64(x) __blsr_u64(x)
+# endif
#endif
On Sat, Jun 25, 2016 at 9:41 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> We got a user report of a compile failure using Apple's Clang. I don't
> know the exact Apple Clang version at the moment. Its on OS X 10.11,
> and its probably the one bundled with the latest Xcode.
>
> Here's the error report
> (https://groups.google.com/forum/#!topic/cryptopp-users/BI8yGpr2XNo):
>
> misc.h:675:23: error: use of undeclared identifier '_tzcnt_u64'
> misc.h:790:22: error: use of undeclared identifier '_blsr_u64';
> did you mean '__blsr_u32'?
>
> Here's the code in question from misc.h (from
> http://github.com/weidai11/cryptopp/blob/master/misc.h):
>
> #if defined(__GNUC__) && defined(__BMI__)
> return (unsigned int)_tzcnt_u64(v);
> #elif defined(__GNUC__) && (GCC_VERSION >= 30400)
> return (unsigned int)__builtin_ctzll(v);
> #elif ...
>
> #endif
>
> And from misc.h (from http://github.com/weidai11/cryptopp/blob/master/misc.h):
>
> #if defined(__GNUC__) && defined(__BMI__)
> template <>
> inline bool IsPowerOf2(const word64 &value)
> {
> return value > 0 && _blsr_u64(value) == 0;
> }
> #endif
>
> I believe both symbols are available in
> http://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined&text=_blsr_u64&expand=421):
>
> #if defined(__GNUC__) && defined(__BMI__)
> #include
> #endif
>
>
> Given __BMI__ is defined, why are we catching the "undeclared identifier"
> error?
>
> Thanlk in advance/
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] /usr/bin/ld: cannot find libclang_rt.ubsan_standalone-arm.a: No such file or directory
I'm working on Raspberry Pi 3. Its an ARMv8 device with CRC but without Crypto extensions. It also uses a 32-bit OS and hard float configuration. I'm trying to track down a crash that happens under both GCC and Clang on this platform. Other ARM platforms are OK, and i686 and x86_64 are OK. I compiled the program with the following CXXFLAGS. -march=armv8-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -fsanitize=undefined The compiler driver invokes the linker, and it includes the CXXFLAGS. The link results in: $ make clang++ -pthread -march=armv8-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -fsanitize=undefined -Wl,-rpath=\$ORIGIN build/obj/cli/x509.o build/obj/cli/compress.o build/obj/cli/pubkey.o build/obj/cli/tls_proxy.o build/obj/cli/utils.o build/obj/cli/cc_enc.o build/obj/cli/asn1.o build/obj/cli/math.o build/obj/cli/speed.o build/obj/cli/tls_server.o build/obj/cli/main.o build/obj/cli/tls_client.o -L. -lbotan-1.11 -lrt -o ./botan /usr/bin/ld: cannot find /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.ubsan_standalone-arm.a: No such file or directory /usr/bin/ld: cannot find /usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.ubsan_standalone_cxx-arm.a: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:1521: recipe for target 'botan' failed Grepping is not finding the missing library: $ sudo find / -name '*ubsan*' /usr/lib/arm-linux-gnueabihf/libubsan.so.0.0.0 /usr/lib/arm-linux-gnueabihf/libubsan.so.0 /usr/lib/gcc/arm-linux-gnueabihf/4.9/libubsan.so /usr/lib/gcc/arm-linux-gnueabihf/4.9/libubsan.a /usr/share/doc/libubsan0 /var/lib/dpkg/info/libubsan0:armhf.postrm /var/lib/dpkg/info/libubsan0:armhf.md5sums /var/lib/dpkg/info/libubsan0:armhf.postinst /var/lib/dpkg/info/libubsan0:armhf.symbols /var/lib/dpkg/info/libubsan0:armhf.list /var/lib/dpkg/info/libubsan0:armhf.shlibs And: $ sudo dpkg -S libclang_rt.ubsan_standalone_cxx-arm.a dpkg-query: no path found matching pattern *libclang_rt.ubsan_standalone_cxx-arm.a* It appears at least some of the saniziters are available on some of the compilers. My questions are: * Does Clang support UBsan on ARM? * If so, what package normally supplies it? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang and intel syntax assembly
> - Compile the code using clang with the following command. An assembly > manifest hello.s will be generated > clang -m32 -S -masm=intel hello.c -O1 > > - Assemble the asm file using clang: > clang -m32 -mllvm --x86-asm-syntax=intel hello.s > > It fails with the following error output: > > hello.s:10:2: error: invalid operand for instruction > mov dword ptr [esp], str > ^ > I don't know if its your problem, but be careful of using Intel syntax. You should prefer AT&T syntax. Also see "Inline assembly operands don't work with .intel_syntax", https://llvm.org/bugs/show_bug.cgi?id=24232. We try to support Clang in a cross-platform library. On Windows we had to break the compile and error with "Unsupported configuration" because we have thousands of lines of Intel assembly meant to be consumed by MS tools (or compatible tools). Clang would be fine if it stopped pretending to be other compilers and took the code paths written for it (on Windows Clang defines _MSC_VER and it wanders into MS code paths). Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Problems with hexadecimal constant, _mm_set_epi64x and sign conversion
I'm having trouble with Travis during testing. The failed test is available at https://travis-ci.org/Tarsnap/scrypt/jobs/360781179. Clang has rejected my attempts to use the constant (no suffix, ULL and LL): MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCF, 0x71374491428A2F98)); MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCFULL, 0x71374491428A2F98ULL)); MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCFLL, 0x71374491428A2F98LL)); The message the compiler provides is: crypto_sha256_shani.c:50:44: error: implicit conversion changes signedness: 'unsigned long' to 'long long' [-Werror,-Wsign-conversion] The code came from Intel and I doubt it is defective. How do I trick Clang to accept the hexadecimal value? Thanks in advance. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Problems with hexadecimal constant, _mm_set_epi64x and sign conversion
On Mon, Apr 2, 2018 at 12:30 PM, Matthew Fernandez via cfe-users wrote: > What version of Clang are you using? I cannot tell from the Travis config. I > cannot reproduce this with -Wall -Wextra with any of the Clangs I happen to > have on hand (3.8.0, 4.0.1, 5.0.0). > I believe the Clang version is 5.0. I think you may need -Wsign-conversion. The problem is being worked at https://github.com/Tarsnap/libcperciva/issues/44. Also see https://github.com/Tarsnap/libcperciva/commit/7a3113828fd2 Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] error: unknown target CPU 'pentium-m'
On Tue, Oct 2, 2018 at 4:46 AM George Anchev via cfe-users wrote: > ... > So one cannot target architecture 'pentium-m' yet > -mtune for it is possible for that CPU? How can this > be used practically? IOW: how should I modify my > script? Also see https://lists.llvm.org/pipermail/cfe-dev/2016-March/048049.html ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Power9 and __builtin_byte_in_range
I'm trying to compile a Power9 program with Clang 7.0: $ $HOME/llvm/bin/clang++ -mcpu=power9 -maltivec TestPrograms/test_ppc_power9.cxx TestPrograms/test_ppc_power9.cxx:6:11: error: use of undeclared identifier '__builtin_byte_in_range' bool x = __builtin_byte_in_range(b, r); ^ 1 error generated. I'm not sure if Clang 7.0 uses another builtin, or if Clang does not support Power9. I guess I have one of two questions: 1. What is LLVM's name for __builtin_byte_in_range? 2. Which Clang compilers support Power9? Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] _Decimal128 on PowerPC
Hi Everyone,
I'm testing Steven Munroe's pveclib library
(https://github.com/munroesj52/pveclib). It is testing OK with GCC,
but I am having trouble with Clang.
I've been able to test up to Clang 9 and with/without -std=c11, but I
keep encountering two errors:
decpowof2.c:30:7: error: GNU decimal type extension not supported
const _Decimal128 decpowof2 [] = {
decpowof2.c:31:8: error: invalid suffix 'DL' on floating constant
1.0E+0DL, /* 2**0 */
I believe _Decimal128 and the DL suffixes are part of ISO/IEC TS 18661
or N2341 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2341.pdf).
I think I am missing the right combination of Clang compiler and options.
What compiler or options are needed for Clang?
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] need help with clang
On Mon, Sep 20, 2021 at 1:26 AM Pi Pony via cfe-users
wrote:
> ...
> It's so I can learn to use LLVM and Clang better and contribute to the
> community, please pass the knowledge further.
>
> for ( struct { int i; char* ptr; } loopy = { 0, "LLVM" };
>
> loopy.i < 10 && * loopy.ptr != 0;
>
> ++ loopy.i, ++ loopy.ptr )
>
> { ... }
This is probably better suited for Stack Overflow.
It looks like you're coming from some other language. Try this instead.
$ cat test.c
#include
struct loopy
{
int i;
char* ptr;
};
int main(int argc, char* argv[])
{
struct loopy loops[] =
{
{0, "LLVM"},
{0, NULL}
};
for (struct loopy* ptr = loops;
ptr->i < 10 && ptr->ptr != NULL;
++ptr)
{
/* ... */
}
return 0;
}
$ clang test.c -o test.exe
$ ./test.exe
$
Jeff
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On Mon, Sep 20, 2021 at 7:37 AM John Emmas via cfe-users
wrote:
>
> Hi there - I'm building quite a complex Windows program here using
> VS2019. Obviously there's an EXE and there's maybe 30 or so DLLs. Some
> DLL's might have code which looks like this in a header file:-
>
> class whatever {
> static int revision_num;
> };
>
> or if there's no class involved it'd maybe look like this:-
>
> extern int revision_num;
>
> ...
> But if I switch VS2019 to use Clang (when building the EXE) Clang's
> linker will complain that it can't find the variable 'revision_num'.
> But of course, 'revision_num' is an internal variable that's private to
> the DLL - so the EXE should never need to know about it...
'revision_num' is declared static. Try 'extern static int revision_num'.
Getting this sort of thing to compile under different compilers can be
tricky. Especially when exporting templates.
Jeff
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
> ... > I checked this morning and sure enough the "/Ob" option doesn't get sent > if I build with VS2019 and Clang - so I'm guessing "/Ob0" wouldn't be > recognised by Clang's compiler? > > So does Clang have it's own command-line option to disable inline > function expansion? Or is that something which hasn't been implemented > for Clang? Thanks, The U&L option is -fno-inline. But I think Clang has an option to consume MSVC style options, so you may be able to use /Ob. I think you can check which MSVC style options Clang accepts with 'clang-cl /?' or 'clang-cl -?'. I don't use Clang on Windows, so I'm not really the person to answer your Windows questions. Sorry about that. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On Wed, Sep 22, 2021 at 7:21 AM John Emmas via cfe-users wrote: > > On 21/09/2021 14:24, John Emmas via cfe-users wrote: > > > > clang-cl /? reveals that it'll handle the Microsoft variant of /Ob0 > > ... > All the signs here are that Clang is still trying to inline stuff - even > when it's been told not to... so is there some way I could check if it > responds correctly to "/Ob0"? Maybe ask a question on cfe-dev ? LLVM dev would probably be a good place to bring up the topic. Several people work on the Windows port. There's one person in particular who does most of the heavy lifting (but I don't recall the person's name). LLVM dev is where to find the people. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On Thu, Sep 23, 2021 at 12:48 PM David Blaikie via cfe-users wrote: > > On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users > wrote: >> ... >> Over on llvm-dev I'm trying to persuade them that declaring something as >> __declspec(dllimport) should automatically exclude it from being >> inlined. And to be honest, I'd be quite surprised if that's not what >> Microsoft intended. > > I think if it's clearly demonstrated that that's Microsoft's implementation - > that no matter how hard you ask it to optimize and how simple the function > is, that it won't inline a dllexported function that's inline in a header > (both implicitly inline in a class definition, and probably check the case of > a standalone dllexported inline non-member function in a header) that I'd say > (though I have little sway/weight in this design decision) clang-cl should > implement the same behavior, because it is observable/can be relied upon as > you have (though also - dllexported variables should be defined somewhere, > generally) & an opt-in flag to what is the current behavior > (dllexport-inlining). I think this is the old binary compatibility problem, like exceptions crossing module boundaries. I think part of the problem is, Microsoft does not publish a specification. For years Borland had to figure it out by reverse engineering what MS was doing. I guess the situation has not gotten any better. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] cfe-users list moving to LLVM Discourse
On Wed, Jan 12, 2022 at 1:00 PM Tanya Lattner via cfe-users < cfe-users@lists.llvm.org> wrote: > The cfe-users mailing list will be moved to LLVM Discourse under the > “Using Clang” category (under Clang Frontend). All archives will be > migrated. *This list will be no longer be in use starting February 1, > 2022. *Please see this blog post for all details: > https://blog.llvm.org/posts/2022-01-07-moving-to-discourse > That's unfortunate. If you would like to continue to get notifications regarding Using Clang, > you must do the following: > > 1) Sign up for an account on LLVM Discourse (you may use your GitHub > account): > https://llvm.discourse.group/ > You should look at their Terms of Service. They are obscene. I'm not going to be their product and be forced into perpetual agreements that can't be terminated. You should reconsider indemnifying them. If they want indemnification, they should buy an insurance policy like the rest of the world. And I think you're a fool to agree to arbitration. There's a reason companies choose arbitration rather than settling disputes in the court system. https://meta.discourse.org/tos Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
