Let's say that someone wants to extend the OpenMP functionality, by adding, for example a new directive newdir with some clauses e.g newclause in order to use a code in the form
#pragma omp newdir (newclause)
or something like that. I know that OpenMP is a language extension and therefore this requires the modification of the gcc source code to support the new syntax (and of course the corresponding changes in the libgomp runtime). I am looking for documentation on how this can be done, if not detailed, at least some hints as a starting point for further research on this subject. Thanks.
I did not try anything yet, this is just a question
Related
I'm looking for a simple way to localize certain g++ (g++-4.9 to be specific) compile options to certain lines of code or at least targeted functions. I'm interested generally speaking, but also specifically to the -fast-math, -ffinite-math-only and -fno-signed-zeros options.
I presume that localization at the *.cpp file level is possible with make utility, but I'm hoping there is a way to enable it in the code itself, through #pragma or __attribute__ or something. I want to do this not only to minimize dependencies to external files (i.e. risk of incorrect makefile) but also to hopefully hyperlocalize certain FP behavior to specific equations within a function.
Alternatively, if localization of FP behavior by inline directives is NOT possible, what can I do to at least trigger a compile time error if desired compiler directive is NOT enabled in project build (e.g. makefile is lost or inappropriately modified).
I would presume that such inline optimization might be compiler specific, g++ in this case, but that is a compromise I'm willing to take.
In gcc you can use function attribute optimize:
void f () __attribute__ ((optimize("fast-math"), optimize("finite-math-only"), optimize("no-signed-zeros")));
I'm not sure that you are using the "localize" word correctly. Localization is related to adapting software to users of different human languages (French, Russian, Chinese...)
Perhaps you want to ask the compiler to optimize some functions with other optimization flags.
This is possible using #pragma GCC optimize etc... or using some function attributes
You might be able to turn on some bits of this with the fpmath option in a function attribute, but this was not clear to me from the docs. In light of that, I will focus on detection instead:
-fast-math already turns on -ffinite-math-only, so you don't need to worry about that. The docs for -fast-math say:
This option causes the preprocessor macro FAST_MATH to be
defined.
Which means it can be detected via
#ifndef __FAST_MATH__
#error "The -fast-math compiler option is required"
#endif
I have not yet found a compile-time way to detect the presence of -fno-signed-zeros
I want to use the aspectc++ compiler for a C++11-project. I have read in the manual, that c++11 support will come with version 2. I thought that aspect weaving happens only on the code level, so why does it depend on the used C++ version? Why does aspectc++ care the source code when it just has to weave the aspects to generate a composed piece of code? Is there a way to use aspectc++ for C++11 source code? Or is there an alternative which can handle it?
This post is already a bit older, i know.
Nevertheless I'd like to answer the question why aspectC++ depends on the C++-version:
aspectC++ internally parses the code (amongst other things to identify the locations where to weave the code). Not all of this can be done by external parsers therefore it needs to understand the syntax basically itself.
Some new c++-constructions from C++11 like attributes ([[...]]) could not be handeled by the AspectC++-compiler version < 2.0.
To use c++11 for compiling just use -std=c++11
Hello, i want to start running some microbenchmarks on Apples Swift-language.
However i feel it is hard to find proper documentation for the different options in regards of compiler optimization.
I have read a lot of questions and articles about other peoples microbenchmarks of the language, however it would be nice to have some firm documentation on the subject.
In the latest beta, the ones to use seems to be:
-Onone
No optimizations
-O
Safe optimizations?
-Ounchecked (Replaced -Ofast)
Unsafe optimizations, (No checks for integer overflow, array out of bounds etc)
My question is, are these all my possible options? And does anybody have some resource that documents this?
EDIT:
I have found similar documention to the one i need about objective-c with gcc here:
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html section 2.8. This is what i need for Swift..
I'm using GCC 4.7.2. My code is rather heavy on template, STL and boost usage. When I compile and there is an error in some class or function that is derived from or uses some boost/STL functionality, I get error messages showing spectacularly hideous return types and/or function arguments for my classes/function.
My question:
Is there a prettyprint type of thing for GCC warnings/errors containing boost/STL types, so that the return types shown in error messages correspond to what I've typed in the code, or at least, become more intelligible?
I have briefly skimmed through this question, however, that is about GDB rather than GCC...
I've also come across this pretty printer in Haskell, but that just seems to add structure, not take away (mostly) unneeded detail...
Any other suggestions?
I asked a similar question, where someone suggested I try gccfilter. It's a Perl script that re-formats the output of g++ and colorizes it, shortens it, hides full pathnames, and lots more.
Actually, that suggestion answers this question really well too: it's capable of hiding unneeded detail and pretty-printing both STL and boost types. So: I'll leave this here as an answer too.
The only drawback I could see is that g++ needs to be called from within the script (i.e., piping to it is not possible at the time). I suspect that's easily fixed, and in any case, it's a relatively minor issue.
You could try STLfilt as mentioned in 'C++ Template Metaprogramming' by David Abrahms & Alesky Gurtovoy.
The book contains a chapter on template message diagnostics. It suggests using the STLFilt /showback:N to eliminate compiler backtrace material in order to get simplified output.
Is it possible to write your own gnatcheck rules, and if so, can someone point me to a good reference? I am searching for a particular "style" that is being used, and would love if I could simply write a rule that says if you see said style, it will throw up a warning, or an error, this way we can flag when this isn't following a particular standard.
A bit of background may be helpful here. While the style checks hold out a lot of promise for enforcing user style guidelines, that isn't exactly what they are for.
The main purpose of those checks is to enforce Ada Core's (The folks who maintain the compiler) style on the sources of the Ada compiler itself. You may notice that the checks get automatically turned on if you try compiling one of the compiler's own source files.
It doesn't really serve AdaCore's purposes at all if the styles enforced by the checks themselves are user-configurable, so they added no feature like that.
Your first option if you want to use it yourself is to just stick to AdaCore's coding style. I haven't found it horrible in the past, so you may just look at doing that.
Still, making some kind of configurability would be a really cool feature for somebody to add. If you go this route, you probably would have to make it configurable (with the current behavior as the default), rather than just changing the checks. The reason is that you'd have to modify the compiler sources to accomplish this, and as I mentioned above, the compiler turns the checks on when compiling itself. You really don't want to have to reformat a ton of working Gnat compiler source files.
I'd really like to see someone do this at some point, as it would make the checks much more useful to those of us who work for someone besides AdaCore.
In addition to trashgod's reference, I think Section 7.1 of this PDF might be of some help:
http://extranet.eu.adacore.com/articles/HighIntegrityAda.pdf
For reference, the existing GNAT style checking is described in the GNAT User's Guide under ยง3.2.5 Style Checking. As the rules are enforced by the compiler, additional rules would require corresponding modifications.