Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #61 > unrolled thread

Re: GCC/G++ compiler: Error goes away when run through debugger

Back to article view | Back to comp.compilers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: GCC/G++ compiler: Error goes away when run through debugger George Neuner <gneuner2@comcast.net> - 2011-03-29 12:18 -0400
    Re: GCC/G++ compiler: Error goes away when run through debugger ike@localhost.claranet.nl (Ike Naar) - 2011-03-29 21:42 +0000
      Re: GCC/G++ compiler: Error goes away when run through debugger George Neuner <gneuner2@comcast.net> - 2011-03-31 01:34 -0400
      Re: GCC/G++ compiler: Error goes away when run through debugger Shankar <shankarke@gmail.com> - 2011-04-01 15:31 -0700

#61 — Re: GCC/G++ compiler: Error goes away when run through debugger

On Sat, 26 Mar 2011 12:35:22 -0700 (PDT), "rhoads@cs.rutgers.edu"
<rhoads@cs.rutgers.edu> wrote:

>I'm using the gcc/g++ compiler under Cygwin (an UNIX emulator that
>runs on windows).
> :
>The -O3 optimizations are supposed to always produce the same
>results.  Running through the debugger is not supposed to change the
>results either.  Has anybody else encountered this behavior?

As Mark mentioned already, your problem is most likely uninitialized
variables.  But that said ...

GCC's -O3 optimization level is widely known to cause strange problems
... almost always because the program is violating assumptions made by
the more advanced optimizations.

The -O2 level typically is safe.  If you think you need the -O3
optimizations, you should individually enable them to see if any
breaks the program.  Specify -O3 only if you find they all work.

George

[toc] | [next] | [standalone]

#66

George Neuner  <gneuner2@comcast.net> wrote:
>GCC's -O3 optimization level is widely known to cause strange problems
>... almost always because the program is violating assumptions made by
>the more advanced optimizations.
>
>The -O2 level typically is safe.  If you think you need the -O3
>optimizations, you should individually enable them to see if any
>breaks the program.  Specify -O3 only if you find they all work.

Sometimes using -O3 makes the program run slower than when using -O2.

[toc] | [prev] | [next] | [standalone]

#69

On Tue, 29 Mar 2011 21:42:12 +0000 (UTC), ike@localhost.claranet.nl
(Ike Naar) wrote:

>George Neuner  <gneuner2@comcast.net> wrote:
>>GCC's -O3 optimization level is widely known to cause strange problems
>>... almost always because the program is violating assumptions made by
>>the more advanced optimizations.
>>
>>The -O2 level typically is safe.  If you think you need the -O3
>>optimizations, you should individually enable them to see if any
>>breaks the program.  Specify -O3 only if you find they all work.
>
>Sometimes using -O3 makes the program run slower than when using -O2.

Yes, inlining and function cloning can greatly increase the code size.
But in particular -O3 enables the "predictive-commoning" and
"tree-vectorize" optimizations.  "predictive-commoning" is an
extension of loop unrolling which tries to identify and avoid
recomputing and/or reloading values that are common to two or more
(not necessarily consecutive) iterations of a loop but which overall
are not loop invariant.  "tree-vectorize" tries to map a loop of
serial operations into an equivalent, but shorter, loop of SIMD
operations.  Both of these optimizations can break badly - and in
quite unexpected ways - when indexed locations are aliased or when
there are iterative data dependencies.  The compiler can't always
figure out when NOT to perform the optimization ... and the results
when the compiler guesses wrong are unpredictable.

George

[toc] | [prev] | [next] | [standalone]

#70

On Mar 29, 2:42 pm, i...@localhost.claranet.nl (Ike Naar) wrote:
> George Neuner  <gneun...@comcast.net> wrote:
>
> >GCC's -O3 optimization level is widely known to cause strange problems
> >... almost always because the program is violating assumptions made by
> >the more advanced optimizations.
>
> >The -O2 level typically is safe.  If you think you need the -O3
> >optimizations, you should individually enable them to see if any
> >breaks the program.  Specify -O3 only if you find they all work.
>
> Sometimes using -O3 makes the program run slower than when using -O2.

I think you should use some tool like valgrind which might immediately
catch the problem that would be going on.

Also when you use -ggdb I think some of the strings are loaded in
the .data section but gets loaded into the .const data section
otherwise.

-

Shankar

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web