When we use the functions __xray_patch and __xray_unpatch, what exactly do they do? What does "patching" mean in the context of LLVM Xray?
Related
here are some built-in functions about atomic operations in the documentation:
__c11_atomic_init
__c11_atomic_thread_fence
__c11_atomic_store
__c11_atomic_load
__c11_atomic_exchange
__c11_atomic_compare_exchange_strong
__c11_atomic_compare_exchange_weak
__c11_atomic_fetch_add
...
I want to look at the source code implemented by Clang? Their implementation may be in a source file, but I did not find it.
I am building Yocto 2.5(Sumo) with Gstreamer 1.14 and OpenCV 3.4.5
I am getting this error while compiling Gstreamer:
build_xwayland_mq/tmp/work/aarch64-mx8m-poky-linux/gstreamer1.0-plugins-bad/1.14.4.imx-r0/recipe-sysroot/usr/include/opencv2/imgproc/types_c.h:445:21: error: conflicting declaration of C function 'CvMoments cvMoments(const cv::Moments&)'
CV_INLINE CvMoments cvMoments(const cv::Moments& m)
same error in imgproc_c.h:360:13
I saw someone solved this by building with OpenCV 4 instead, but we need OpenCV 3.4.5 for our own project.
Anyone know how to resolve this conflict?
too long for comment..
I did just quick search, found this:
https://www.yoctoproject.org/pipermail/meta-freescale/2019-March/023888.html
There is some problem in includes .. I guess in mentioned hpp files there are some types that are not declared in that imgproc_c.h for 3.4, but already are moved there for opencv 4 (just my guess).
You just need to add those hpp on all places (in gst plugins bad) where you find include for imgproc_c.h.
Take inspiration from this.. or maybe it itself will solve your issue:
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-opencv-fix-build-for-opencv-3-4-2.patch?h=thud
The patch is for yocto thud.. but perhaps it does not matter for GStreamer.
In worst case you will have to backport it or make your own patch for sumo.
Or if you can try update to thud (should be small difference) or newer and check if it persists.
When I use std::map's merge(source) I got an error:
error: no member named 'merge'
However, the std::map::merge should be there since c++17.
I do add set(CMAKE_CXX_STANDARD 17) and -stdlib=libc++. The std::map::extract is already there. Is this a bug in clang-7?
If I get rid of -stdlib=libc++, the gcc header does contain std::map::merge. Then I can compile. But I do need -stdlib=libc++ for my project. Any idea?
I dig around and find out that the merge neither exists in llvm/include/c++/v1/map nor in llvm/include/c++/v1/experimental/map. So which header should I include for that? Or the c++17 support in clang-7 is still problematic?
It's in LLVM 8 but not 7. It's item p0083r3 in the C++17 status table, and here's the commit:
https://github.com/llvm/llvm-project/commit/5c4e07ae5c6f7f467b436f1b24f41ef4cf9897b3
From the tag list it doesn't look like it's been back-ported to 7.
Rad Studio Rio 10.3.1, CLANG.
The simple code throws an exception in the assignment operator (y=x): 'std#bad_alloc'
typedef std::variant< std::string, int> MVariant;
MVariant x=10;
MVariant y;
y=x;
I cannot see the reason. What am I missing?
I think that the problem is not in Rad Studio itself. It is about CLANG. This is known bug 33222 that seems to only affect libstdc++'s std::variant (and other constructs using the same combination). The problem is related to friend function to templates.
The variant from libc++ doesn't seem to use the technique of friends that libstdc++ used.
See get<string> for variants fail under clang++ but not g++
There are ARM32's JumpTable description in ArmAsmPrinter.cpp,
but there aren't any information of AArch64's JumpTable in AArch64AsmPrinter.cpp
But,
Compiler can emit JumpTable to Binaries.
So, how does LLVM do it?