here's mine:
-u -r -s -t -u -p -i -d
What Are Your GCC Flags?
91–100 of 117 posts
Re: What Are Your GCC Flags?
#92Re: What Are Your GCC Flags?
#93-fno-exceptions I don’t like C++ exceptions. And we don’t use them where I work And none of your code uses the STL nor third party libraries that might throw exceptions either, right [1] [1] "Doing without" http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_excepti...
AFAIK, stl (and beyond that, C++) throw exceptions especially in case of allocation failure (ie. new or push_back() failing to allocate memory), and more generally in case of programming errors (out_of_range, bad_cast etc.), and I am 100% okay with the program aborting() in such situation.
Do you use things like the range-checked `std::vector::at` or `dynamic_cast` with reference types at all then? If so, do you put a breakpoint on `abort` during development?
Re: What Are Your GCC Flags?
#94Very surprising to not see the -std option to actually clarify which language standard is being used. Perhaps that isn't as important in C++ as it is in C.
Is there a way to specify C89 but use the C99 style comments (i.e. //)?
I believe that -std=gnu89 should give you C89 with that particular extension (and some others).
Re: What Are Your GCC Flags?
#95Earlier quoted context omitted.
I'm curious if there is a way to rewrite your loops which use unsigned types to somehow communicate to the compiler that you will not overflow.
You'd have to use annotations or asserts. Or rely on literal whole program analysis to prove upper bounds of parameters/etc (which still may not be possible statically) Otherwise, given as something as simple as for (unsigned i = 0; i You can't say it iterates N/2 times
I took a couple examples where gcc failed vectorization for unsigned indexes and tried to rewrite them in a way that didn't sacrifice 1/2 of the type's range just to satisfy the optimizer. In the first example I could just change a "The results: http://ideone.com/7vidIs
Generated code http://tinyurl.com/le72k4o
Re: What Are Your GCC Flags?
#96Earlier quoted context omitted.
1. that's good to know. I'm all for shortening my cflags line since I don't squelch my Makefile rules. 2. I always get bitten when I try and generalize. I tested this in all of my software, and was not able to detect any performance difference with or without -fwrapv (that is to say, I know you can create extreme edge cases where there's a huge difference, just as you can probably make up one that's slower without -f…
2. You must not write software very amenable. Fun fact btw: GCC and LLVM are the only compilers I know of to assume loops can overflow at all when optimizations are on. Compilers like XLC will actually even assume unsigned loop induction variables will not ovefrlow at O3, unless you give them special flags. :)
> Compilers like XLC will actually even assume unsigned loop induction variables will not ovefrlow at O3
That's not exactly fair. The C standard guarantees that unsigned variables will overflow by wrapping, so if the compiler assumes such a loop won't terminate, it is not conformant.
Re: What Are Your GCC Flags?
#97Earlier quoted context omitted.
We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant one. The problem, of course, is that it destroys the ability to examine performance in production with tools like DTrace and the like. A one-time couple-of-percent improvement in some cases (…
It was very beneficial on the register-starved x86, but I notice less impact on amd64. I definitely also have a debug-mode that builds with -g and without -s -O3 -fomit-frame-pointer.
It's good to have it at least in dev, but many bugs only show up in production, and performance work can only usefully be done on the shipping, optimized code.
Re: What Are Your GCC Flags?
#98The compiler flags for Ag[1] are rather strict these days: -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow \ -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces \ -std=gnu89 -D_GNU_SOURCE -O2 Note that -Wall and -Wextra do not enable all warnings. To keep backwards compatibility, -Wall is basically, "All warnings as of 1990." -Wextra covers a lot of the newer warnings, but still misses a few…
-pedantic-errors is also a very useful flag. -Wstrict-aliasing=1/-Wsuggest-attribute= can give good suggestions during development. Probably not useful for Ag: But I do a lot of numeric stuff so -Wfloat-equal is handy for me. For code using float this should be mandatory: -Wdouble-promotion.
gcc's -Wstrict-aliasing is extremely inaccurate. It doesn't run inside the aliasing machinery; it's just a cheap heuristic inside the C parser. I'd call it a good example of why you shouldn't strive to fix a warning just because it happens to exist.
I thought there was a better tool, but can't find the name, hmm.
Re: What Are Your GCC Flags?
#99Earlier quoted context omitted.
We (as an industry) need to stop using -fomit-frame-pointer, at least by default. I'd be interested to see if there's any real-world workload (not a benchmark) where it makes even a measurable difference, let alone a significant one. The problem, of course, is that it destroys the ability to examine performance in production with tools like DTrace and the like. A one-time couple-of-percent improvement in some cases (…
It was very beneficial on the register-starved x86, but I notice less impact on amd64. I definitely also have a debug-mode that builds with -g and without -s -O3 -fomit-frame-pointer.
amd64 has enough registers that using one for the frame pointer isn't too bad.
On the other hand, some platforms don't need a frame pointer for debugging; if you emit correct unwind tables that's enough for the debugger to construct a backtrace. I haven't looked lately but am pretty sure amd64 ELF is one of them.
Also, modern gcc generates okay debug info for optimized programs such that it's much more likely you can read variables out of a crash in gdb.
Re: What Are Your GCC Flags?
#100The use of 'bytecode' is strange when refering to gcc and C code, perhaps 'object code', or executable would've been better. Bytecode is usually reserved for things like the JVM, or other cases where an interpreter/JIT is needed to run your code.
Couple of points: - The GNU Compiler Collection can compile Java, as well as other languages with "bytecode". - GCC actually has a native intermediate language, it's just not very well advertised.
In real world projects, I have never seen a GNU Compiler not called explicitly, and in fact this article is advising to be extra explicit in compiler flags, so referring to any output code, especially -o with a .o extension, as 'bytecode', is inherently incorrect, regardless of whatever "intermediate" language GCC actually uses, unless you're outputting that intermediate code.