I'd like to check for intel intrinsics such as _mm_popcnt_u32 or _mm_blendv_epi8 using cmake. However the function check_symbol_exists doesn't work properly depending on the compiler. (it works with Clang but not with GCC). Indeed it is documented
If the header files declare the symbol as a function or variable then the symbol must also be available for linking (so intrinsics may not be detected).
Is there a simple way to check for those ?
As the CMake documentation also states:
If the symbol is a type, enum value, or intrinsic it will not be
recognized (consider using CheckTypeSize or CheckCSourceCompiles).
So, try to compile a small example with the Intel intrinsic using CheckCSourceCompiles. E.g.:
include(CheckCSourceCompiles)
check_c_source_compiles("
int main() {
int tmp = _mm_popcnt_u32(0);
return 0;
}
"
HAVE_INTRINISC
)
Related
I have updated a project using CGAL 4.13 to CGAL 5.5. It uses the kernel:
typedef CGAL::Exact_predicates_exact_constructions_kernel K;
typedef K::FT dbl;
and some functions do not compile now anymore. For example the one below:
inline void decouple(const dbl& val,dbl& decoupled)
{
...
decoupled=CGAL::Gmpq(val.exact().mpq());
}
../geometricTools.h:476:50: error: 'const ET' {aka 'const class
boost::multiprecision::numberboost::multiprecision::backends::gmp_rational'}
has no member named 'mpq' 476 |
decoupled=CGAL::Gmpq(val.exact().mpq());
A second problem is a line wher e a string ("123/456") is converted to a number:
dbl AlgorithmHdf5::getDbl(int n, int d)
{
...
dbl ret(m_vDbl[ind]); // argument is a std::string
return ret;
}
AlgorithmHdf5.cpp:71:36: error: no matching function for call to
'CGAL::Lazy_exact_ntboost::multiprecision::number<boost::multiprecision::backends::gmp_rational
::Lazy_exact_nt(__gnu_cxx::__alloc_traitsstd::allocator<std::__cxx11::basic_string<char
, std::__cxx11::basic_string >::value_type&)' 71 | dbl ret(m_vDbl[ind]);
these lines used to work with CGAL 4.13 but do not with CGAL 5.5. I'd appreciate any help on this. Compiler: g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Epeck::FT is a wrapper around some rational type that depends on what is available. If you have GMPXX or LEDA, it may use that. In your case you have GMP and a recent enough Boost, so it uses Boost.Multiprecision. If you disable that with -DCGAL_DO_NOT_USE_BOOST_MP, you may get back to the Gmpq your old code was apparently expecting.
Boost.Multiprecision does not use reference counting, so decoupled=val.exact() should be sufficient for that type. To construct from std::string, it may help to first construct a FT::Exact_type (or CGAL::Exact_rational) and then convert that to FT. You may want to file an issue on github about this direct construction from a string, it looks like something that CGAL could support.
This code:
#include <stdio.h>
int main()
{
void (^a)(void) = ^ void () { printf("test"); } ;
a();
}
Compile without warning with clang -Weverything -pedantic -std=c89 (version clang-800.0.42.1) and print test.
I could not find any information about standard C having lambda, also gcc has it's own syntax for lambda and it would be strange for them do this if a standard solution existed.
This behavior seems to be specfic to newer versions of Clang, and is a language extension called "blocks".
The Wikipedia article on C "blocks" also provides information which supports this claim:
Blocks are a non-standard extension added by Apple Inc. to Clang's implementations of the C, C++, and Objective-C programming languages that uses a lambda expression-like syntax to create closures within these languages. Blocks are supported for programs developed for Mac OS X 10.6+ and iOS 4.0+, although third-party runtimes allow use on Mac OS X 10.5 and iOS 2.2+ and non-Apple systems.
Emphasis above is mine. On Clang's language extension page, under the "Block type" section, it gives a brief overview of what the Block type is:
Like function types, the Block type is a pair consisting of a result value type and a list of parameter types very similar to a function type. Blocks are intended to be used much like functions with the key distinction being that in addition to executable code they also contain various variable bindings to automatic (stack) or managed (heap) memory.
GCC also has something similar to blocks called lexically scoped nested functions. However, there are some key differences also note in the Wikipedia articles on C blocks:
Blocks bear a superficial resemblance to GCC's extension of C to support lexically scoped nested functions. However, GCC's nested functions, unlike blocks, must not be called after the containing scope has exited, as that would result in undefined behavior.
GCC-style nested functions also require dynamic creation of executable thunks when taking the address of the nested function. [...].
Emphasis above is mine.
the C standard does not define lambdas at all but the implementations can add extensions.
Gcc also added an extension in order for the programming languages that support lambdas with static scope to be able to convert them easily toward C and compile closures directly.
Here is an example of extension of gcc that implements closures.
#include <stdio.h>
int(*mk_counter(int x))(void)
{
int inside(void) {
return ++x;
}
return inside;
}
int
main() {
int (*counter)(void)=mk_counter(1);
int x;
x=counter();
x=counter();
x=counter();
printf("%d\n", x);
return 0;
}
I'm following Kate Gregory's C++ course on Pluralsight and understand that C++17 introduced a feature for compilers to deduce the type in a template, however the code below returns the error: missing template arguments before 'numbers'
#include <vector>
using std::vector;
int main()
{
vector numbers{ 0, 1, 2 };
return 0;
}
I'm using the MinGW gcc compiler (version 6.3.0) and using "g++ -std=c++1z *.cpp" in the command prompt, so I'm not sure what I'm doing wrong.
I know I can fix it by declaring the type but I wanted to check in case I miss out on other C++17 features through some basic error I'm making.
Your code is OK (but I suggest not to use using std::vector).
The problem is your compiler, g++ 6.3.0, that is too old to support the feature you're trying to use: class template argument deduction and deduction guides.
You need g++ 7 or newer.
I'm trying to use the PiGPIO library with Kotlin Native as a linked library (not using the deamon).
So I'm using C interop with a .def file that references the pigpio.h file.
It works (I managed to get a LED blinking) but there is an issue with the typing of integers.
Althoug I didn't enable the experimental unsigned integers feature, the generated stubs are using type UInt.
For example for the parameters of this function:
#kotlinx.cinterop.internal.CCall public external fun gpioSetMode(gpio: kotlin.UInt, mode: kotlin.UInt): kotlin.Int { /* compiled code */ }
That's OK with me as they are of type unsigned in C and I want this to be as type-safe as possible:
int gpioSetMode(unsigned gpio, unsigned mode);
Now the problem is that the values to be used as parameters for the functions are defined using macro definitions in the .h file. For example for the mode parameter:
#define PI_INPUT 0
#define PI_OUTPUT 1
The generated Kotlin constants corresponding to those values are of type Int:
public const val PI_INPUT: kotlin.Int /* compiled code */
public const val PI_OUTPUT: kotlin.Int /* compiled code */
However, although calling the function with the constant as a parameter is possible:
gpioSetMode(14, PI_OUTPUT) // compiles fine
I can't create a method that takes the mode as a parameter and use it:
fun main() {
setMode(PI_OUTPUT) // fails to compile (Type Mismatch)
}
fun setMode(mode : UInt) {
gpioSetMode(14, mode)
}
Is there a way to force all constants of positive integers to be of type UInt ?
AFAIK, there is no such option in the cinterop tool. In fact, one can say that the problem grows from the library header not using unsigned literals in it's "define" section. But it can be omitted in C, so this header is fine. The tool here is a bit nerdier, so it assumes all integer literals with no additional suffix as the signed typed. About the way that your generated function works. In Kotlin, there is a smart cast concept(see here), but here it is a problem. In this documentation part, there is a note on smart-casting availability only for checks inside a module. In your case, gpioSetMode(gpio, mode) and PI_OUTPUT are located in the same module, while your setMode is in another one.That's why the first call compiles and the second one does not. I managed to workaround it in my small sample like that: just added into my code this like, redefining the constant
import my.*
const val PI_OUTPUT = my.PI_OUTPUT
where my is the library package, most probably pigpio for you. After that, smart casts will be available for the library functions, and all functions you declare in this module.
I need to recover method names dynamically, via reflection calls at runtime. But get strange results for some.
My TestClass contains a method like:
- (void)testMethod6_NSRect:(NSRect)a1 int:(int)a2 int:(int)a3 bool:(Boolean)a4 {
...
}
When enumerating the above classes methods using class_copyMethodList() and fetching the method selectors via method_getName(), I get:
"testMethod6_NSRect:int:int:_Bool:"
Thus, the selector was rewritten somehow (by gcc?) to make "_Bool" from "bool". As far as I tested yet, this seems to be done only for a "bool" selector-part - if I change it to int:(int), as in:
- (void)testMethod1_int:(int)a1 int:(int)a2 int:(int)a3 int:(int)a4 {
...
}
I get the expected:
"testMethod1_int:int:int:int:"
Q:
Does anyone know the rules or a pointer to where I could find them for this "selector rewriting", or am I missing something? Is this only done for "bool"?
I also need to know if this behavior is depending on the gcc-version, osx-version or runtime library version.
I am using (gcc --version):
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
on a (uname -a)
10.8.0 Darwin Kernel Version 10.8.0:
The problem lies in an ugly piece of preprocessor magic in the C99 standard header <stdbool.h>:
#define bool _Bool
C99 defines a type named _Bool which behaves like C++'s bool type. The define is there to be able to use it in C but with the C++ identifier.
Solution:
#undef bool
Try using BOOL instead of Boolean