Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gtoso]

Hi,
Compile with both debug and optimize enabled is wrong?
In other words -O2 interfere with debugging? (particularly in Mac OSX)
If you need to know the optimizations enabled by this in OSX they are:

Code: [Select]

       -O1 Optimize.  Optimizing compilation takes somewhat more time, and a
           lot more memory for a large function.

           With -O, the compiler tries to reduce code size and execution time,
           without performing any optimizations that take a great deal of
           compilation time.

           -O turns on the following optimization flags: -fdefer-pop
           -fdelayed-branch -fguess-branch-probability -fcprop-registers
           -floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp
           -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs
           -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -fmerge-constants

           -O also turns on -fomit-frame-pointer on machines where doing so
           does not interfere with debugging.

           -O doesn't turn on -ftree-sra for the Ada compiler.  This option
           must be explicitly specified on the command line to be enabled for
           the Ada compiler.

       -O2 Optimize even more.  GCC performs nearly all supported
           optimizations that do not involve a space-speed tradeoff.  The
           compiler does not perform loop unrolling or function inlining when
           you specify -O2.  As compared to -O, this option increases both
           compilation time and the performance of the generated code.

           -O2 turns on all optimization flags specified by -O.  It also turns
           on the following optimization flags: -fthread-jumps -fcrossjumping
           -foptimize-sibling-calls -fcse-follow-jumps  -fcse-skip-blocks
           -fgcse  -fgcse-lm -fexpensive-optimizations -fstrength-reduce
           -frerun-cse-after-loop  -frerun-loop-opt -fcaller-saves -fforce-mem
           -fpeephole2 -fschedule-insns  -fschedule-insns2 -fsched-interblock
           -fsched-spec -fregmove -fstrict-aliasing
           -fdelete-null-pointer-checks -freorder-blocks  -freorder-functions
           -funit-at-a-time -falign-functions  -falign-jumps -falign-loops
           -falign-labels -ftree-pre

           Please note the warning under -fgcse about invoking -O2 on programs
           that use computed gotos.

           In Apple's version of GCC, -fstrict-aliasing, -freorder-blocks, and
           -fsched-interblock are disabled by default when optimizing.
EDIT: Some info here.

[Stu Redman]

Optimize might optimize out some variables from your full backtrace, and have confusing effects when single-stepping through source. Otherwise it should be fine to use the both together. At least unless on MacOS which I don't know. 

[Kry]

-O2 especially has a tendency to unroll loops, etc, and generally speaking the compiled code won't match the source's flow. I wouldn't like that to be the case, but it all depends on if we want to give people debug build... which we most likely want.

[gtoso]

So what is it better in your opinion:
only one build with debug and -O2 (or -O1) that people use?
Or one debug build without optimization to use only for debug (maybe even with debug wxMac)
and a build without debug and -O2 (or even -O3) for normal use?

[Stu Redman]

I'd say, the first one for SVN builds, the second one for releases.

[gtoso]

I'd say, the first one for SVN builds, the second one for releases.

I agree.
Asap I update my 2.2.5 packages accordingly.
Do you know where I can find the amule applications icons at high resolution? See here.

[Festor]

and a build without debug and -O2 (or even -O3) for normal use?

-O3 is bad... 

[gtoso]

and a build without debug and -O2 (or even -O3) for normal use?

-O3 is bad... 

Ok, thanks.

I was tempted to make too a Leopard only version, more optimized (only for G4-G5/Intel using -fast and maybe gcc 4.2.1 instead of 4.0.1), but -fast implies -O3:

Code: [Select]

       -fast
           Optimize for maximum performance. -fast changes the overall
           optimization strategy of GCC in order to produce the fastest
           possible running code for PPC7450 and G5 architectures. By default,
           -fast optimizes for G5. Programs optimized for G5 will not run on
           PPC7450. To optimize for PPC7450, add -mcpu=7450 on command line.

           -fast currently enables the following optimization flags (for G5
           and PPC7450).  These flags may change in the future.  You cannot
           override any of these options if you use -fast except by setting
           -mcpu=7450 (or -fPIC, see below).

           -O3 -falign-loops-max-skip=15 -falign-jumps-max-skip=15
           -falign-loops=16 -falign-jumps=16 -falign-functions=16
           -malign-natural (except when -fastf is specified) -ffast-math
           -fstrict-aliasing -funroll-loops -ftree-loop-linear
           -ftree-loop-memset -mcpu=G5 -mpowerpc-gpopt -mtune=G5  (unless
           -mtune=G4 is specified).  -fsched-interblock -fgcse-sm -mpowerpc64

           To build shared libraries with -fast, specify -fPIC on the command
           line as -fast turns on -mdynamic-no-pic otherwise.

           Important notes: -ffast-math results in code that is not
           necessarily IEEE-compliant.  -fstrict-aliasing is highly likely to
           break non-standard-compliant programs.  -malign-natural only works
           properly if the entire program is compiled with it, and none of the
           standard headers/libraries contain any code that changes alignment
           when this option is used.

           On Intel target, -fast currently enables the following optimization
           flags:

           -O3 -fomit-frame-pointer -fstrict-aliasing
           -momit-leaf-frame-pointer -fno-tree-pre -falign-loops

           All choices of flags enabled by -fast are subject to change without
           notice.


[Festor]

-O3: This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide with gcc 4.x.
The behavior of gcc has changed significantly since version 3.x. In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x.
Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors).

The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.

From: http://www.gentoo.org/doc/en/gcc-optimization.xml

[gtoso]

From: http://www.gentoo.org/doc/en/gcc-optimization.xml

lol Apple in its -fast do almost everything that should not be done!!!

[Stu Redman]

Using -O3 is not recommended for gcc 4.x.

Looks like the gcc guys fucked up way more than just creating stupid warnings about && and ||.