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

101–110 of 117 posts

Re: What Are Your GCC Flags?

#101

Post by astrange »

detrino wrote: post #95
DannyBee wrote: post #80

Earlier quoted context omitted.

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

In reality I'm not sure what kind of loop would have an index only fitting in an unsigned type.

On a 32-bit machine an unsigned array index means one object using more than half the address space. It's sensible to use unsigned 64-bit for file sizes, but I think it's quite odd that C programers would use it for a loop or array index. Wrong, but defined, behavior is worse than undefined behavior, you know.

On a 64-bit machine, well, it shouldn't be a problem to use signed long long.

Re: What Are Your GCC Flags?

#102

Post by cokernel_hacker »

byuu wrote: post #67
detrino wrote: post #66

Earlier quoted context omitted.

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

Looks like somebody added -Wswitch-bool just now: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-2...

Re: What Are Your GCC Flags?

#103

Post by astrange »

geocar wrote: post #90

I start with: -Os I really don't like the stack protector. It adds a lot of space to executables, so I turn it off: -fno-stack-protector Arthur told me about: -fno-asynchronous-unwind-tables which seems to save a lot of space. I don't know exactly what it does, but the documentation suggests it does something with debugging, however `-s` doesn't remove it so I have this here. I often work without glibc (don't need it…

For any benefit you'd get from -mregparm, you'd get a much better one by switching to amd64 already! Or are you having to support Windows?

Re: What Are Your GCC Flags?

#104

Post by dap »

astrange wrote: post #99
byuu wrote: post #88

Earlier quoted context omitted.

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…

> 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.

Working with unwind tables is more complicated and many useful debugging tools don't do so.

Re: What Are Your GCC Flags?

#105

Post by AsmMAn »

I don't do GCC anymore but clang instead of, at all. Does -ansi -pedantic -fwritable-strings -Weverything -Wno-missing-noreturn -Wno-padded -Wno-nested-anon-types -Wno-switch-enum count?

Re: What Are Your GCC Flags?

#106

Post by geocar »

astrange wrote: post #103
geocar wrote: post #90

I start with: -Os I really don't like the stack protector. It adds a lot of space to executables, so I turn it off: -fno-stack-protector Arthur told me about: -fno-asynchronous-unwind-tables which seems to save a lot of space. I don't know exactly what it does, but the documentation suggests it does something with debugging, however `-s` doesn't remove it so I have this here. I often work without glibc (don't need it…

For any benefit you'd get from -mregparm, you'd get a much better one by switching to amd64 already! Or are you having to support Windows?

X32 isn't quite everywhere yet, and the larger words add a lot of space. I try not to use them if I don't need it, but I'm definitely looking forward to X32.

Re: What Are Your GCC Flags?

#107

Post by pja »

bjerun wrote: post #54
pja wrote: post #33

Earlier quoted context omitted.

See this LWN article: http://lwn.net/Articles/192624/

So it is not really optimizing the code - more like optimizing the symbol table?

Yes, looks like it. The default symbol lookup can be really slow in some situations, especially in large C++ projects with can contain many symbols that share a long common prefix thanks to C++ name mangling.

Re: What Are Your GCC Flags?

#109

Post by DannyBee »

klodolph wrote: post #96
DannyBee wrote: post #81

Earlier quoted context omitted.

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.

That's exactly the point: they cheat, because it makes code faster except in the small percent of code it breaks.

Let us all now bow our heads to the almighty SPEC gods ...

Re: What Are Your GCC Flags?

#110

Post by byuu »

cokernel_hacker wrote: post #102
byuu wrote: post #67

Earlier quoted context omitted.

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

Looks like somebody added -Wswitch-bool just now: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-2...

Oh wow, I wonder if someone saw this thread, or if that was just a coincidence.

Either way, very cool! Thanks for the heads up! I can't use it now obviously, but I can add a diagnostic disable line that'll work in the future.

Post reply on HN