I have installed clang and llvm version 9 using instructions from https://apt.llvm.org/ .
Next I try to get my version of openmp from clang compiler, so I created file openmp_v.cpp:
#include <unordered_map>
#include <cstdio>
#include <omp.h>
int main(int argc, char *argv[])
{
std::unordered_map<unsigned,std::string> map{
{200505,"2.5"},{200805,"3.0"},{201107,"3.1"},{201307,"4.0"},{201511,"4.5"}};
printf("We have OpenMP %s.\n", map.at(_OPENMP).c_str());
printf("Version: %d.\n", _OPENMP);
return 0;
}
and compile it:
clang++-9 -std=c++17 -fopenmp openmp_v.cpp -o openmp_v -fopenmp=libiomp5
The result is:
We have OpenMP 3.1.
Version: 201107.
The problem is that the openmp version should be 4.5 and not 3.1, because clang-9 support openMp 4.5.
I even installed libomp-9-dev and nothing have changed.
Also, I have located llvm-9 include and lib files, which are in: /usr/lib/llvm-9
and try to add them as:
clang++-9 -std=c++17 -fopenmp openmp_v.cpp -o openmp_v -fopenmp=libiomp5 -I /usr/lib/llvm-9/include/openmp -L /usr/lib/llvm-9/lib/
But it still doen't work.
EDIT: replaced placeholder with reply.
After a bit of conversation with one of the clang developers, it's not really clear if this is a bug in clang or more a feature. IMHO, it could be that the version string for _OPENMP was not correctly set, when clang 9.0 was branched from the mainline code version.
The mainline version in the repository correctly reports 201511 for _OPENMP, which corresponds to OpenMP API Version 4.5. I think this is correct, as clang (to my knowledge) does not yet fully support OpenMP 5.0.
So, clang 10.0.0 will correctly report the version number. I'm not sure if there will be a bugfix release of clang 9.0.0 that will also fix this issue.
Hope that helps!
Related
I was using Xcode 11 to compile zbar for my iOS Device.
However it gives me this error:'iterator' file not found
Some code:
#ifndef _ZBAR_IMAGE_H_
#define _ZBAR_IMAGE_H_
/// #file
/// Image C++ wrapper
#ifndef _ZBAR_H_
# error "include zbar.h in your application, **not** zbar/Image.h"
#endif
#include <assert.h>
#include <iterator>
#include "Symbol.h"
#include "Exception.h"
I have tried to clean and rebuild and this didn't seem to work.
Environment:
Mac OS Catalina 10.15 Beta (19A558d)
Xcode 11.0(11A420a)
C11
<iterator> is a c++ reference, please refer to here.
so,
a. Renaming the image.c to image.cpp
or
b. Compile with g++, NOT gcc
would be helpful.
Context
I read Clang's "Controlling Diagnostics via Pragmas" section about turning off particular warnings. It works well in general for all warnings except for -Wgnu-zero-variadic-macro-arguments.
The code is:
MyHeader.hpp
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wgnu-zero-variadic-macro-arguments"
#import "header generating -Wgnu-zero-variadic-macro-arguments warning"
#pragma clang diagnostic pop
Problem
Clang generates -Wgnu-zero-variadic-macro-arguments warnings while compiling translation units importing MyHeader.hpp.
Env
Clang Version:
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
OS: Mac OS X 10.9.5
This seems to be working in Xcode 6.4 (6E35b). The pragma suppresses the warning now.
I have -Weverything in build settings. Without the diagnostic ignore I definitely get the warning:
Token pasting of ',' and __VA_ARGS__ is a GNU extension
Output from Terminal to match your Env section:
$ clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
Using the following code:
#define DEBUG
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wgnu-zero-variadic-macro-arguments"
#import "Macros.h"
#pragma clang diagnostic pop
In which Macros.h contains:
#ifdef DEBUG
#define AssLog(condition, message, ...) NSAssert(condition, message, ##__VA_ARGS__)
#else
#define AssLog(condition, message, ...) if (!condition) NSLog((#"%# [Line %d] " message), [NSString stringWithUTF8String:__PRETTY_FUNCTION__], __LINE__, ##__VA_ARGS__)
#endif
Since this answer is the top result for clang's error:
Token pasting of ',' and VA_ARGS is a GNU extension
C++20 doesn't require the token pasting operator (##__VA_ARGS__) and regular __VA_ARGS__ will work.
see example here
The accepted answer works well for this specific issue, but if you are trying to actually kill the warning rather than hiding it, you can compile with -std=gnu++11 or -std=gnu++1y or whatever the relevant gnu compliant standard would be for your code base. I was having this same warning and it took some digging to realize what it was trying to tell me. This is for CLang++ but there should be a GCC equivalent.
Relevant Warning
Token pasting of ',' and VA_ARGS is a GNU extension
Env
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
I'm writing a little self-educational project. It has to do with Clang and LLVM internals hacking.
But while I was investigating the code base and reading documentation, strange things were going on with the build process.
What I am trying to do for starters is to build LLVM and Clang for SPARC target. But this rather simple task turns out to be quiet challenging.
I use sources from the stable release 3.4.2 and folder tree looks like that:
llvm/
...
projects/
...
test-suite <-- test-suite-3.4.src.tar.gz extracted here
tools/
...
clang/ <-- cfe-3.4.2.src.tar.gz extracted here
....
tools/
....
extra <-- clang-tools-extra-3.4.src.tar.gz extracted here
And from the intermediate folder (which lays on the same level as llvm) I call the following:
../llvm/configure --disable-optimized --enable-targets=sparc \
--prefix=/home/wf34/projects/helloClang/built
Surprisingly, resulting clang and llvm cannot deal with SPARC arch.
../built/bin/clang file2.c -S --target=sparc-unknown-linux -emit-llvm -o -
Gives (amongst the others) following line:
clang: warning: unknown platform, assuming -mfloat-abi=soft
Result is the same, if I write just --target=sparc.
Finally, attaching result of the llc --version:
LLVM (http://llvm.org/):
LLVM version 3.3
Optimized build.
Default target: x86_64-pc-linux-gnu
Host CPU: corei7-avx
Registered Targets:
cpp - C++ backend
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
Thank you for your insight and ideas!
Edit
Actually, having all that written, I have a guess that maybe I might have been mistaken while getting and untaring and setting the source from stable release. Maybe I would be better off following manual steps directly and getting source from svn trunk. I will fall back to that option if I won't receive any more meaningful suggestion.
I have implemented a checker in clang. I have compiled it and now i am using it to check on a c file which includes stdio.h file. I am giving below command to run the checker :
clang -cc1 -analyze -analyzer-checker=alpha.core.FuncPrototype funcprototypetest.c
I am getting below error :
funcprototypetest.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
Can anybody help me with a proper way to handle this error.When i compile the funcprototype.c file independently with gcc, it gets compiled. So i am not getting what can be the issue?
Thanks in advance.
Answer found here: http://permalink.gmane.org/gmane.comp.compilers.clang.devel/37462
You mast use
clang --analyze -Xclang -analyzer-checker=alpha.core.FuncPrototype funcprototypetest.c
instead
clang -cc1 -analyze -analyzer-checker=alpha.core.FuncPrototype funcprototypetest.c
I've been trying to compile Qt for iOS, but I've been having some crazy problems that noone else seems to be having (at least according to what I read in the past day).
I followed the instructions from this article:article url
I cloned a the latest Qt 4.8 from git: $ git clone git://gitorious.org/qt/qt.git
I made the qt-lighthouse-ios-simulator folder, cd to it.
I ran the long line of code from the article: $ ../qt/configure -qpa -xplatform qpa/macx-iphonesimulator-g++ -arch i386 -developer-build -release -opengl es2 -no-accessibility -no-qt3support -no-multimedia -no-phonon-backend -no-svg -no-webkit -no-scripttools -no-openssl -no-sql-mysql -no-sql-odbc -no-cups -no-iconv -no-dbus -static -nomake tools -nomake demos -nomake docs -nomake examples -nomake translations
opensource license
yes I accept the agreement
I get these errors:
In file included from /System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/Accessibility.h:13,
from /System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/HIServices.h:49,
from /System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:34,
from generators/mac/pbuilder_pbx.cpp:56:
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/AXUIElement.h:65: error: CGCharCode has not been declared
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/AXUIElement.h:65: error: CGKeyCode has not been declared
After struggling with this, searching here and there, and finding nothing useful (even nothing about what CGKeyCode or CGCharCode actually are, I decided to "hack" it and just added the definitions to pbuilder_pbx.cpp:
typedef u_int16_t CGCharCode; /* Character represented by event, if any */
typedef u_int16_t CGKeyCode; /* Virtual keycode for event */
Then another file couldn't compile, with the same errors. After adding them to a couple of files, I eventually added them to qcore_mac_p.h, then some files complained that they didn't know what u_int16_t was, so I added
typedef unsigned short u_int16_t; /* compile, god damn you!!! */
to the same header.
Now everything compiled but there was this linker error:
ld: in /System/Library/Frameworks//CoreGraphics.framework/CoreGraphics, missing required architecture x86_64 in file for architecture x86_64
Here's where I'm stuck. Any help?
Additional information:
gcc --version : i686-apple-darwin10-g++-4.2.1
iOS SDK: I have both 4.2 and 4.3
OS X version: 10.6.7
Xcode version (if it matters): 4.0.2
The problem somehow magically doesn't exist, when I tried the same thing on a different Mac with OS X 10.7.1
I have no idea how and why, but now qmake compiles and links.