How can I find the signature of specific functions used for OpenACC by PGI compiler?
For instance, __pgi_uacc_enter or __pgi_uacc_launch functions.
Is there any documentation or header files to find the signature. Or even some documentation regarding not only their signature but also their functionality.
I don't think the signature of those are exposed because they're not things a user calls, but rather they're used from generated code. I'd bet that you're not using the -ta (or -acc) flag at link time. If you link with the OpenACC flag it should provide those symbols.
Related
Using -buildmode=archive produces mylib.a. I'm not fully understanding the steps required to then use this library in another Go program.
I've tried instead generating -buildmode=c-archive which produces a header file and archive, but the headerfile is not designed to be imported using cgo (there is conflicts with imported types).
Research online has yielded the conclusion that -buildmode=c-archive is specifically not designed for cgo use for this reason.
My query is what is -buildmode=archive actually used for if it cannot be included?
I'm not fully understanding the steps required to then use this library in another Go program.
It can be tricky. Need to look into each compiler toolchain for linking them correctly, i.e. gcc/clang etc. and find how, and if it's even possible to link them and use them.
What is -buildmode=archive actually used for if it cannot be included?
From the docs: https://pkg.go.dev/cmd/go
-buildmode=archive
Build the listed non-main packages into .a files. Packages named
main are ignored.
That's what it does, what you do with it, it's up to you, there's tons of information online, for example: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
The freecompilercamp.org has a very good tutorial about defining OpenMP Directives.
However, apart from this I was unable to find any good resource on how to add new directives,
clauses etc for OpenMP in llvm.
Moreover, I am interested in knowing more about what OPENMP_DIRECTIVE_EXT is and how to declare a new one? Any guide about this or how the User defined Reduction is implemented would be helpful. Even a link to the patchset or pull request that added this functionality would be helpful.
Thank you!
Citing the openMP spec -
Compilers can therefore ignore OpenMP directives and conditionally compiled code if support of the OpenMP API is not provided or enabled. A compliant implementation must provide an option or interface that ensures that underlying support of all OpenMP directives and OpenMP conditional compilation mechanisms is enabled. In the remainder of this document, the phrase OpenMP compilation is used to mean a compilation with these OpenMP features enabled.
In other words, the directives are a programming tool to allow compilers to compile code under it if an existing implementation for such a directive exists and otherwise falls back to compiling the code as normal for a cpu. I also found this IBM page which explains the pragmas a bit further.
I didn't really find any other tutorial than the one you mention. You should probably look at the clang tutorials in that site. I think the OpenMP directives are implemented as a clang frontend parser. You need to parse the structured code inside the directive and add a new AST node. This will be compiled to LLVM IR and passed to LLVM where you can do more transformations to the IR.
Is there a way to determine function parameters to a shared library's exported symbols? I am investigating a private OSX framework for curiosity purposes (I'm aware of Apple store policies, etc). I can perform nm -g /path/to/library and determine all of the exported symbols, however, I am curious in determining the parameters that must be passed to these calls.
No, that information is not present in a shared library's symbol table (or any other part of the shared library). That's why you need the header file when you compile against a library.
It is needed to gather the necessary information about the translation unit using the plugin for GCC and to modify AST on its base.
I've already understood how to gather information. But I haven't understand yet how to modify AST before it's passed into CRT. Very little information is available on this subject.
Tell me plese what should I read on this subject? Share thoughts, links.
Thank's.
P.S.
I've already read everything on these links:
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version
http://developer.apple.com/library/mac/#documentation/DeveloperTools/gcc-4.2.1/gccint/index.html#Top
The GCC test suite contains a basic examples of such modifications. See http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/plugin/finish_unit_plugin.c and start_unit_plugin.c shows how to create a var. Unfortunately for more serious modifications the GCC source code are probably your best bet.
Are you tied to GCC for this endeavor? The ROSE compiler is built specifically for performing source-level modification, then handing the resulting code off to a backend compiler.
I have a project compiled using __cdecl calling convention (msvc2010) and I compiled boost using the same compiler using the default settings.
The project linked with boost but I at runtime I got an assert message like this:
File: ...\boost\boost\program_options\detail\parsers.hpp
Line: 79
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
There are the following questions:
what calling convention does boost build with by default on Windows (msvc2010)
how to I compile boost with __cdecl calling convention
why boost wasn't able to prevent linking with code with different calling conventions? I understood that boost has really smart library auto-inclusion code.
Update #1
It looks that boost does compile and link with proper calling convention, still at runtime I get the above problem. I did a sample application using the same code and it works but in my application it fails. The only difference could be from project configuration or includes/stdafx.h
Just use
bjam ... **cxxflags=/Zp4**
while building boost libraries.
As far as I know there's not way to make C++ use cdecl calling conventions (see MSDN Calling Convention). The C++ method calling is just different from C. The only opportunity that you have to use one of the C calling conventions is for functions, which include class static functions in C++. If you know that's the case you can try forcing the option when building by adding the option during the build:
bjam cxxflags=/Gd ...
(see BBv2 Builtin features)
Or to make it "permanent" set up a user-config.jam with your compiler and add it to the build options for all BBv2 msvc builds (see BBv2 Configuration and related docs). As for you other questions:
Boost uses the default calling convention MSVC uses, except for cases where it overrides it at the code level. I don't know where those are as they are library specific. So you'd have to search the code for the "__*" code decorators.
See above for partial answer.
Detection; there are two reasons: There is a limit to how many different options we can reasonably detect for for building as it's an exponential growth of different possible variations so we limit it to the most important cases. And in the case of calling convention, it's not actually possible since it's something that can be changed on a per function basis.
I found the cause of the problem inside one of the shared property files: <StructMemberAlignment>4Bytes</StructMemberAlignment>
If I remove it the code will work. Still, I'm not sure why this is happening and how could I solve it without removing the above code (that was required by another library).
I added another question regarding boost and structure member alignment.