How does one overwrite the default compile flags for Cython when building with distutils?
My question is similar to this , but the response involved manually running the cython steps - given the progress from 0.12 to 01.9 - is it possible for me to simplyy switch from -O to -O3?
Also have users seen a significant difference in speed depending on this switch?
I am on a windows machine.
If you use a setup.py script you can set the "extra_compile_args" option (see https://stackoverflow.com/a/16402557/2355197). Depending on your code, you can see significant differences. For example, on GCC, -O3 enables the option "-finline-functions" which
considers all functions for inlining.
Davide
Related
I am now a sophomore in university and just started learning compiler few months ago. I am wondering what tool will make it easier if I want to enable -O3 as default option instead of -O1.
To change the global compiler defaults for all projects, you will have to install a new spec file in the place where your GCC installation expects it (for example, /usr/lib/gcc/x86_64-linux-gnu/6/specs). See Spec Files in the GCC documentation. This might work:
*cc1_options:
+ %{!O*:-O3}
*cc1plus_options:
+ %{!O*:-O3}
It enables -O3 if no -O option is set.
Note that this risks breaking quite a few build systems because few of them will expect that -O3 is enabled by default.
To be able to debug and fuzz a whole Linux distribution, I would like to set ASAN (AddressSanitizer, https://en.wikipedia.org/wiki/AddressSanitizer) as default option to gcc. So normally to achieve what I want, generally, I set the following variables before to compile a linux package:
CFLAGS="-fsanitize=address,undefined -Wformat -Werror=format-security -Werror=array-bounds -g"
CXXFLAGS="-fsanitize=address,undefined -Wformat -Werror=format-security -Werror=array-bounds -g"
LDFLAGS="-fsanitize=address,undefined"
and try to compile and run my code. I would like to have it default to gcc.
One option to do it is using spec files: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html. However I didn't find a way to set a "catch all rules" to compile and link all my c/c++ code with AddressSanitizer.
My questions are:
Any example how to do it using spec files?
Is that the best approach to do it?
Any other alternative approach?
First of all, be sure to take a look at existing whole-distro Asan enablings in Tizen (also here) and Gentoo.
In general there are two main approaches:
customize your build system to enable Asan by default, usually using CFLAGS and CXXFLAGS; this won't always work because many packages ignore them (I think that's what Hanno Boeck did in Gentoo)
replace /usr/bin/gcc, /usr/bin/g++ and /usr/bin/cc (and may x86_64-linux-gnu-gcc, x86_64-linux-gnu-g++) with wrappers which would add Asan flags and redirect calls to original executables (this is the approach we eventually took in Tizen and found it very successful)
As a side note, I'd suggest to add the following options
CFLAGS += -fsanitize-recover=address,undefined
otherwise boot will fail at too early stages. Also look at suggested settings ASAN_OPTIONS in above links, it took people long time to figure them out.
I have recently been reading up on linkers and I'm having trouble understanding this compilation code. If I were to run gcc -Wl,--hash-style=both example.c, what difference will it make as opposed to me simply running gcc example.c. And also, what does --hash-style means
what does --hash-style means
--hash-style allows you to change the format of hashtable which is used for runtime symbol resolution (see Drepper's article, section "The GNU-style Hash Table" for details). The GNU hashtable format is said to be slightly faster.
If I were to run gcc -Wl,--hash-style=both example.c,
what difference will it make as opposed to me simply running gcc example.c
It depends on how your distro's GCC was configured. AFAIK most use either both or gnu styles by default. Both simply means that linked files will include, um, both gnu and sysv hashtables. This shouldn't matter unless you try to run your program on a system with dynamic linker which does not understand GNU hashtables. In that case, if program was built with -Wl,--hash-style=gnu, you'll get an error at startup about unsupported hashtable format.
I have what I imagine will be an easy question. How do I create a 64-bit build using ifort? I'm using "ifort -Ofast -o program.exe .f". I've set the compilervars to intel64 and am working on win7 using a xeon processor. I've looked through the menu of compiler flags but haven't been able to identify what I need. I see there's a -m64 option for mac users but that won't help me.
A second question, would there be that big of a performance issue between a gfortran -m64 build relative to the same using ifort?
Thanks!
In ifort, you need to invoke the ifortvars.sh (or .csh) script with the "intel64" argument to get the x64 compiler. In fact, you are required to specify that argument (either as intel64 or ia32), so look to see how it is invoked in your environment and fix the reference. This is not selected with an option to the ifort command.
As for performance comparisons, I would point you at Polyhedron, an independent software reseller in the UK. They do multi-compiler comparisons on fixed hardware. Click on "Compiler Comparisons" in the left column. In their tests, gfortran is in 5th place (ifort is 1st).
I'm interested in answers, approaches, and ideas out of the box. At a high level, the main page is pretty sparse and they mainly list -g, with one level, suggesting that -O0 is also either very helpful or essential.
But I'm wondering what other clang flags can be given to give maximum debugging. Is there an equivalent to gcc's -ggdb3 which includes some of the source or annotations directly in the object output? Or could there be? Is it possible and helpful to recompile the OS and its original libraries to have debugging (and if so, if I'm using Debian, can I have it write the debugging into the main .deb package instead of putting a separate debugged .deb package which stores debugging data in /usr/lib/debug?)? Will a static build of a binary affect the ability to see a good stacktrace? And is there anything that needs to be done to ensure that addr2line works well? Is it needed to compile all libraries (even glibc) with clang to get the maximum debugging benefit? I note that there is a project to recompile Debian with clang, and otherwise am open to a distribution that does so or otherwise places emphasis on debugging.
On Linux there are also options like an LD_PRELOAD set to /lib/libSegFault.so, or a set of LD_LIBRARY_PATH reassignments to /usr/lib/debug instead of the usual /usr/lib location (including redirecting libc itself to the debugged version). Is there a central place or external sources for answers to this question of how to enhance debuggability of a binary? The bigger mystery is clang, since I see in the long gcc man page that there are various options which can increase debugging (or reduce optimisations), but on the other hand the documentation for clang only shows a smaller set. It's possible that clang will accept more options than given, including gcc flags (which may either translate to a no-op or to more debugging - hard to tell without a canonical source of information).
Also from a package build perspective, since an external package may not respect CFLAGS, I've redirected /usr/bin/strip to be a no-op command that always succeeds, but other ideas on ensuring compliance are suggested (I believe that pkgsrc does a good job of wrapping gcc and the linker in shell scripts - useful to insert mandatory flags). Also there may be various ld options that can be passed to increase debugging of the outputted target. Also, it's quite possible that BSD (including FreeBSD 10, based upon clang) may have a different linking architecture which could make it easier to request and find debugged symbols in the generated libraries and executables.
To take debugging more broadly defined, I've set LD_WARN=yes, LD_DEBUG=unused, SEGFAULT_SIGNALS="all", LD_PRELOAD=.../libSegFault.so (as mentioned above), and LD_BIND_NOW=yes. Also I believe I can prefer that gcc search for libraries in /usr/lib/debug - above the standard search paths using strategic -Bs. Also, using --whole-archive for a static build might ensure that more objects are included in the linked output. There's also ulimit -c unlimited, and on Linux a nice way to differentiate core files like:
sysctl -w kernel.core_pattern="core.%t.SIG-%s.PID-%p.ID-%g-%u.%h.%E"
For gcc I've used and seen flags like: -O0 -fno-omit-frame-pointer -fverbose-asm -ggdb3 -mno-omit-leaf-frame-pointer -mtune=generic -fvar-tracking -D_GLIBCXX_DEBUG=1 -frecord-gcc-switches -femit-class-debug-always -fmath-errno -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -fno-merge-debug-strings -mieee-fp -mtune=generic -static-libgcc -fexceptions -fvar-tracking -fbounds-check -rdynamic -UNDEBUG -DDEBUG=1 (-ffreestanding -static-libgcc -pass-exit-codes) -fno-stack-check (since I believe I've read that the latter can interfere with debugging)
Other flags are there for other reasons but the emphasis is to be on maximum debugging. With all or most of the above, it's unclear to what extent clang would support or use there, or whether there are other options.
Clang does not support the -ggdb3 flag, only -g, as you have noticed. If you try to use it, you'll get the message:
clang: warning: argument unused during compilation: '-ggdb3'
so you can run your entire command line through Clang and it will tell you which of those GCC flags it supports and which it does not, some will print warnings, others may error out, but Clang will not silently ignore them. Here are the ones that Clang rejected when I tried your long command: -static-libgcc and -pass-exit-codes.
As pointed out in another SO answer, clang -cc1 --help can be used to list supported compilation flags, where we see the following which may be of interest to you:
-disable-llvm-optzns: Don't run LLVM optimization passes
-fno-elide-constructors: Disable C++ copy constructor elision
-mdisable-fp-elim: Disable frame pointer elimination optimization