I'm transferring our build system from Make to meson/ninja.
when trying to set up a cross-file for ARC, executing the meson setup:
meson setup --buildtype PATH/TO/BUILD/DIR debug --cross-file PATH/TO/FILE
i receive an error:
meson.build:1:0: ERROR: Unknown compiler(s): [['/efs/data/public/synopsis/ARC-2018.06/MetaWare/arc/bin/ccac']]
here's my cross file:
[binaries]
c = '/efs/data/public/synopsis/ARC-2018.06/MetaWare/arc/bin/ccac'
cpp = '/efs/data/public/synopsis/ARC-2018.06/MetaWare/arc/bin/ccac'
ar = '/efs/data/public/synopsis/ARC-2018.06/MetaWare/arc/bin/ccac'
[host_machine]
system = 'linux'
cpu_family = 'arc'
cpu = 'hs36'
endian = 'little'
Any ideas ?
in the meson documentation, it appears as arc architecture is supported.
https://mesonbuild.com/Reference-tables.html
Update:
gnu's ARC compiler is supported.
Solved:
after reaching meson's developers mailing list,
we are adding implementation for synopsis's proprietary compiler in meson's source and will commit the changes to meson's project.
Take a look at Compiler ids table - there is no ARC compiler, and I checked meson sources in meson/mesonbuild/compilers and didn't find ccac. So, there is no support for ARC compiler in meson. You can contact Synopsys about plans for integration, the best contact there I know for this is Alexey Brodkin.
Related
My env:
Qt source: dev branch
cmake version: 3.18.4.0
os: windows
Build step:
cd qt_source
mkdir build
cd build
cmake -DMAKE_BUILD_TYPE=Release ..
Then error raised:
ERROR: C++11 <random> is required and is missing or failed to compile.
ERROR: detected a std::atomic implementation that fails for function pointers. Please apply the patch corresponding to your Standard Library vendor, found in qtbase/config.tests/atomicfptr
How can I debug this?
Update on 2020/10/26:
I used the vcpkg install qt5 and it works.
I'd recommend you to use a bit more stable Qt branch, e.g. 5.15.1 or 5.12, otherwise you should be aware that dev branch is on-going development of new features and Qt 6 (as of 01/11/2019), and all bug fixes that are not only relevant for Qt 5 (as of 15/05/2020).
From my practical experience, current dev branch always need some tricks to use and brings lots of problems. If you still need to test some feature that is available only in dev -- consider switch to some stable branch and cherry-pick changes you are interested in.
I was getting this error when trying to build Qt itself from sources with Visual Studio 16 2019 generator. Turned out, it is not supported (yet?), so I had to use Ninja generator instead (and set C/C++ compiler to cl.exe) - then the configuration and build went fine.
So perhaps that is the case with building projects too - you should check if you are using Ninja (and switch to it if not).
I am trying to install cilk++ according to this website and am at the steps in section "Cilk Plus Runtime". When I go to build, I get the following output:
$ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=./install ..
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
-- Configuring incomplete, errors occurred!
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeOutput.log".
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeError.log".
I thought clang and clang++ (which I checked with --version are indeed installed) would be sufficient. Do I need to update clang and clang++? There are no troubleshooting steps on the instructions website, so I'm not sure what I need to do to finally get cilk++ up and running on my laptop.
Thanks in advance,
Anthony
Expanding on my comment:
When you configure this Cilk Plus Runtime with CMake, CMake first verifies the compiler by attempting to compile a simple test program (see here). If the compilation fails, CMake prints the error you see:
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
On the Intel Cilk Plus runtime Github page (cilkrts), it has some compiler requirements listed for those trying to build this library:
You need the CMake tool and a C/C++ compiler that supports the Cilk language extensions. The requirements for each operating systems are:
Common: CMake 3.4.3 or later Make tools such as make
Linux: Tapir/LLVM compiler, or GCC* 4.9.2 or later (depracated), or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel(R) C++ Compiler v12.1 or later (depracated)
OS X: Tapir/LLVM compiler, or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel C++ Compiler v12.1 or later (depracated)
Since you are using Clang as your compiler, be sure it is a Cilk-enabled branch of Clang, as specified in the requirements. Or, you can try to use the Tapir/LLVM compiler.
I am trying to build an Objective-C ARC enabled library using CMake. When using the "Unix Makefiles" generator I run into a warning:
method possibly missing a [super dealloc] call
I don't run into this warning when using the XCode generator. Is there a flag I can pass to CMake to make sure that the command line build also recognizes this to be an ARC build and not have that warning generated?
Thanks
You need to let CMake know that you want to build the project with ARC. Otherwise, it will show the warning.
Option 1
However, CTSetObjCArcEnabled is only available only if we have cmake-toolkit installed. If it is not installed, you can use the following:
set_property (TARGET target_name APPEND_STRING PROPERTY
COMPILE_FLAGS "-fobjc-arc")
Option 2 (deprecated since 3.0)
Use CTSetObjCARCEnabled. Reference is available here:
Enables or disables Objective-C Automatic Reference Counting on a per-directory, per-target or per-source basis.
CTSetObjCARCEnabled(<value>
<DIRECTORY | TARGETS targets... | SOURCES sources... >)
Useful Tip
Also, as recommended from this answer, it is helpful to use the following to make sure the project is compiled with ARC enabled:
#if ! __has_feature(objc_arc)
#error "ARC is off"
#endif
An alternative approach is to specify per-target compiler flags. This could be considered more inline with modern CMake:
target_compile_options(target_name PUBLIC "-fobjc-arc")
Note: using PUBLIC will transitively forward this compiler flag to other targets depending on this one. Replacing by PRIVATE will prevent this propagation.
XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC works for me. See https://github.com/forexample/testapp/blob/master/CMakeLists.txt
set_target_properties(
${APP_NAME}
PROPERTIES
MACOSX_BUNDLE YES
XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC YES
)
Another option if you want all Objective-C(++) files to be built with ARC:
set(CMAKE_OBJC_FLAGS "-fobjc-arc")
set(CMAKE_OBJCXX_FLAGS "-fobjc-arc")
In the 2.x version of CMake, the cmake option CMAKE_BUILD_TYPE controlled options to be passed to the compiler. For example, if CMAKE_BUILD_TYPE=RelWithDebInfo then the options passed to the compiler was CMAKE_CXX_FLAGS_RELWITHDEBINFO for C++ and CMAKE_C_FLAGS_RELWITHDEBINFO for C (http://binglongx.wordpress.com/tag/cmake_build_type/).
In the new 3.x version of CMake there are commands add_compile_options and target_compiler_options for adding options to the compiler (What is the modern method for setting general compile flags in CMake?).
Questions
How do I define which build type CMake should use? Is it still, for example, cmake -DCMAKE_BUILD_TYPE=Debug?
How do I make use of this build type in my CMakeLists.txt?
Has CMake defined all the build types, or can I define custom, additional, build types?
Has CMake set any default compiler options for each of the build types (for example -g for the Debug build type)?
Please try to stick to a single question per question in the future. You might risk getting closed as too broad otherwise. Also, you are more likely to get good answers for well-defined, precise questions.
How do I define which build type CMake should use? Is it still, for
example, cmake -DCMAKE_BUILD_TYPE=Debug?
Yes, this did not change.
How do I make use of this build type in my CMakeLists.txt?
Use generator expressions. For example:
target_compile_options(my_program PUBLIC $<$<CONFIG:Debug>:-Werror>)
# Warnings are errors for debug build only
Has CMake defined all the build types, or can I define custom,
additional, build types?
You can add your own type if the defaults don't cut it for you. Note though that this can be a bit fiddly, so I wouldn't do it unless you have good reasons. Take a look at CMAKE_CONFIGURATION_TYPES.
Has CMake set any default compiler options for each of the build types
(for example -g for the Debug build type)?
CMake does a pretty good job at choosing the right defaults for the different configurations. In particular, Debug and RelWithDebInfo builds generate symbols correctly (-g on gcc) and Release builds are optimized quite well.
Context: I have several loops in an Objective-C library I am writing which deal with processing large text arrays. I can see that right now it is running in a single threaded manner.
I understand that LLVM is now capable of auto-vectorising loops, as described at Apple's session at WWDC. It is however very cautious in the way it does it, one reason being the possibility of variables being modified due to CPU pipelining.
My question: how can I see where LLVM has vectorised my code, and, more usefully, how can I receive debug messages that explain why it can't vectorise my code? I'm sure if it can see why it can't auto-vectorise it, it could point that out to me and I could make the necessary manual adjustments to make it vectorisable.
I would be remiss if I didn't point out that this question has been more or less asked already, but quite obtusely, here.
Identifies loops that were successfully vectorized:
clang -Rpass=loop-vectorize
Identifies loops that failed vectorization and indicates if vectorization was specified:
clang -Rpass-missed=loop-vectorize
Identifies the statements that caused vectorization to fail:
clang -Rpass-analysis=loop-vectorize
Source: http://llvm.org/docs/Vectorizers.html#diagnostics
The standard llvm toolchain provided by Xcode doesn't seem to support getting debug info from the optimizer. However, if you roll your own llvm and use that, you should be able to pass flags as mishr suggested above. Here's the workflow I used:
1. Using homebrew, install llvm
brew tap homebrew/versions
brew install llvm33 --with-clang --with-asan
This should install the full and relatively current llvm toolchain. It's linked into /usr/local/bin/*-3.3 (i.e. clang++-3.3). The actual on-disk location is available via brew info llvm33 - probably /usr/local/Cellar/llvm33/3.3/bin.
2. Build the single file you're optimizing, with homebrew llvm and flags
If you've built in Xcode, you can easily copy-paste the build parameters, and use your clang++-3.3 instead of Xcode’s own clang.
Appending -mllvm -debug-only=loop-vectorize will get you the auto-vectorization report. Note: this will likely NOT work with any remotely complex build, e.g. if you've got PCH's, but is a simple way to tweak a single cpp file to make sure it's vectorizing correctly.
3. Create a compiler plugin from the new llvm
I was able to build my entire project with homebrew llvm by:
Grabbing this Xcode compiler plugin: http://trac.seqan.de/browser/trunk/util/xcode/Clang%20LLVM%20MacPorts.xcplugin.zip?order=name
Modifying the clang-related paths to point to my homebrew llvm and clang bin names (by appending '-3.3')
Placing it in /Library/Application Support/Developer/5.0/Xcode/Plug-ins/
Relaunching Xcode should show this plugin in the list of available compilers. At this point, the -mllvm -debug-only=loop-vectorize flag will show the auto-vectorization report.
I have no idea why this isn't exposed in the Apple builds.
UPDATE: This is exposed in current (8.x) versions of Xcode. The only thing required is to enable one or more of the loop-vectorize flags.
Assuming you are using opt and you have a debug build of llvm, you can do it as follows:
opt -O1 -loop-vectorize -debug-only=loop-vectorize code.ll
where code.ll is the IR you want to vectorize.
If you are using clang, you will need to pass the -debug-only=loop-vectorize flag using -mllvm option.