Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Are Your GCC Flags?

blog.httrack.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: What Are Your GCC Flags?

#61

Post by near »

I go with:

g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv

fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.)

I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic shift right on signed types, int > 16-bits, etc.

I'm sure my views won't be popular, and I'm not encouraging anyone to follow what I do, just stating my preferences.

I have a love-hate relationship with warnings. My problem is that you end up with false positives that amount more to "how the compiler authors think you should style your code" instead of reporting legitimate issues. When combined with -Werror, it's a show-stopper for no reason.

Clang is much more naggy than GCC. For instance, I frequently switch on boolean variables. Clang doesn't even have a "-Wno-" intrinsic I can push to temporarily disable this.

But there's nothing at all illegal about switching on a boolean value. It annoys me that I need to go back and add unnecessary explicit casting in 100 places in my project to keep Clang quiet, or face real warnings being lost in a sea of false warnings every single time I build my project. I know you can do if(var) { ... } else { ... } ... I don't care. I want to use switch, and I legally am allowed to. Don't bug me about it, Clang.

It also really hates empty statements, eg while(do_something()); warns that there's nothing inside the while loop. I know, the important part is do_something() and its return value. Same for if's, for's, etc. It wants me to put the ; on its own line. Uh, no. That's not my style at all.

And at the same time ... Clang caught a few bugs that GCC overlooked.

So, my current strategy is to build WIPs with GCC at default warnings and Clang with the sledgehammer of -w; and then before any releases, build with maximum warnings on both compilers and analyze each one for legitimate issues. I also run with valgrind to catch many other types of issues, like using uninitialized variables and memory leaks.

Re: What Are Your GCC Flags?

#62

Post by abrahamsen »

ggreer wrote: post #25

The 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…

I really wish for a -Weverything flags that would enable all warnings, even the stupid, useless ones. I'd then put -Wno- to disable those.

Re: What Are Your GCC Flags?

#63

Post by joveian »

nly wrote: post #35
userbinator wrote: post #14

-Os Then if any functions are a bottleneck, compile them with function-specific O2 or O3.

-Os doesn't always produce smaller code than -O2

It also unfortunately breaks a lot of things and exposes more gcc bugs than the commonly used options. I wish "make the output code as small as possible" was the usual thing compilers tried to do.

Re: What Are Your GCC Flags?

#64

Post by e28eta »

near wrote: post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

> Clang is much more naggy than GCC. For instance, I frequently switch on boolean variables. Clang doesn't even have a "-Wno-" intrinsic I can push to temporarily disable this.

I don't know how responsive they are, but you might try filing a bug.

Re: What Are Your GCC Flags?

#66

Post by detrino »

near wrote: post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

From clang's source code:

    // switch(bool_expr) {...} is often a programmer error, e.g.
    // switch(n && mask) { ... } // Doh - should be "n & mask".
    // One can always use an if statement instead of switch(bool_expr).
I agree that clang should not warn on this without asking for warnings and even then it should be possible to disable it. Maybe it would be a good idea to file a bug report.

That being said, I can't imagine why you would ever choose to switch on a bool, and even go to the trouble to add a cast instead of just writing an if statement.

Also, my clang and g++ with "-Wall -Wextra" does not warn on an empty while statement.

Re: What Are Your GCC Flags?

#67

Post by byuu »

detrino wrote: post #66
near wrote: post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

From clang's source code: // switch(bool_expr) {...} is often a programmer error, e.g. // switch(n && mask) { ... } // Doh - should be "n & mask". // One can always use an if statement instead of switch(bool_expr). I agree that clang should not warn on this without asking for warnings and even then it should be possible to disable it. Maybe it would be a good idea to file a bug report. That being said, I can't imagin…

Thanks for digging that up. Interesting to see their rationale. Seems like they could extend the test to not warn if it's just switch(var) only, but it might have to happen at a different eval level for that to work.

> I can't imagine why you would ever choose to switch on a bool

In my case, it's for opcode execution. They consist of various bit fields that control the behavior, some are only 1-bit wide, some are 2-bits to 5-bits wide. The implementation is a series of switch statements, one after the other, that have cases for all possible values. So by using switch() in all cases, the code looks consistent.

So this is kind of what I dislike about style choice warnings. It's easy to presume there's no valid use case, until you actually find one later on. I get that people can make mistakes, but when I know for certain that I haven't made a mistake, I don't like having to change my code anyway.

Could I force the boolean values to unsigned types even though they're only 1-bit? Yes. Could I just do if/else anyway here? Yes. But I don't want to. I'm happy with my code, and received no warnings at all when I wrote it with GCC several years ago. It's only a "problem" now that I need Clang to target OS X.

> Also, my clang and g++ with "-Wall -Wextra" does not warn on an empty while statement

Hmm, good to hear. If I get to my dev PC before the post is buried, I'll post the output I was getting.

Re: What Are Your GCC Flags?

#68

Post by plorkyeran »

tenfingers wrote: post #48
xroche wrote: post #46

Earlier quoted context omitted.

-Werror is debatable. On a controlled build environment (with fixed GCC version and fixed distribution), I am convinced this is the way to go. After careful reviews, -Wno-xxx switches can be added on demand (such as -Wno-overlength-strings, haha) to limit annoying/irrelevant messages, but experience shows that having thousands of warnings in logs lead to ignore issues (this is especially true when the codebase is hug…

Except one case (gcc 2.9x), I stopped using a fixed version of a compiler a long time ago, nowdays I only use a fixed build host when needed. -Wall -Wextra -Werror will magically make your build fail because of a new warning which wasn't caught before, or a system library update, or others. In my mind it's way better to just build your software with -Wall/others and implicitly review all warnings before pushing chang…

> The kind of person that would use -Werror, in reality would go perfectly fine without.

Eliminating warnings can often be a hassle for no short-term benefit, and there's a decent number of people who agree that zero warnings is useful but don't actually get around to sticking to that if the compiler doesn't force them to.

The bigger benefit is when working with people that will just ignore warnings completely if you let them.

Re: What Are Your GCC Flags?

#70

Post by DannyBee »

near wrote: post #61

I go with: g++ -std=c++11 -O3 -fomit-frame-pointer -fwrapv fwrapv turns off some "bad" optimizations around signed integer overflow (too likely to cause harm, too unlikely to make a significant performance difference in most cases.) I also use a lot of asserts to verify the behaviors too costly to not rely on for what I do (low-level CPU simulation and such): linear A-Z, 8-bit char, twos-complement math, arithmetic s…

1. -fomit-frame-pointer is implied by O3 on most platforms now

2. "too likely to cause harm, too unlikely to make a significant performance difference in most cases."

Please define "most cases". Without this, GCC will have significant trouble being able to derive the bounds of most loops, and in turn, will not be able to vectorize, unroll, peel, split, etc.

Saying "unlikely to make a significant performance different in most cases" is probably very very wrong for most people. The last benchmarks I saw across a wide variety of apps showed the perf difference was 10% in most cases, and a lot more in others.

Post reply on HN