«

Lionel B a écrit :
> Not relevant to this thread, but inlining may sometimes actually *reduce*
> code size - e.g. for very small functions (a common case for inlining)
> where the function call (code size) overhead might actually be larger
> than the inlined function code itself...
>
> int foo(const int n)
> {
> return n*n;
> }
>
> int main()
> {
> return foo(3);
> }
>
> On my system (compiled with g++ and -O<whatever>) this produces a smaller
> executable when foo() is declared inline.

In gcc, the functions considered for inlining are much bigger (default
is 600 lines of pseudocode IIRC) unless you tune it to allow only
smaller functions.

In practice, I would use -O3 optimization on very small parts of the
project.

--
Michael

On Tue, 08 Jul 2008 11:40:10 +0200, Michael DOUBEZ wrote:

> Lionel B a écrit :
>> Not relevant to this thread, but inlining may sometimes actually
>> *reduce* code size - e.g. for very small functions (a common case for
>> inlining) where the function call (code size) overhead might actually
>> be larger than the inlined function code itself...
>>
>> int foo(const int n)
>> {
>> return n*n;
>> }
>>
>> int main()
>> {
>> return foo(3);
>> }
>>
>> On my system (compiled with g++ and -O<whatever>) this produces a
>> smaller executable when foo() is declared inline.
>
> In gcc, the functions considered for inlining are much bigger (default
> is 600 lines of pseudocode IIRC) unless you tune it to allow only
> smaller functions.

Sure, the full(ish) story is:

-fno-inline
Don't pay attention to the inline keyword. Normally this option is
used to keep the compiler from expanding any functions inline. Note that
if you are not optimizing, no functions can be expanded inline.

-finline-small-functions
Integrate functions into their callers when their body is smaller
than expected function call code (so overall size of program gets
smaller). The compiler heuristically decides which functions are simple
enough to be worth integrating in this way.

Enabled at level -O2.

-finline-functions
Integrate all simple functions into their callers. The compiler
heuristically decides which functions are simple enough to be worth
integrating in this way.

If all calls to a given function are integrated, and the function is
declared static, then the function is normally not output as assembler
code in its own right.

Enabled at level -O3.

-finline-limit=n
By default, GCC limits the size of functions that can be inlined.
This flag allows coarse control of this limit. n is the size of functions
that can be inlined in number of pseudo instructions.

Inlining is actually controlled by a number of parameters, which may
be specified individually by using --param name=value. The -finline-
limit=n option sets some of these parameters as follows:

max-inline-insns-single
is set to n/2.
max-inline-insns-auto
is set to n/2.

....

--
Lionel B

On Jul 7, 3:23*pm, Rares Vernica <ra...@ics.uci.edu> wrote:
> Hello,
>
> I have a strange problem.
>
> I compile my code with g++ (GCC) 4.1.2. My code runs just fine if I use
> the -O2 optimization flag. valgrind does not report any memory leak.
>
> When I use the -O3 flag, everything falls apart. The program reports
> Segmentation fault. valgrind reports some Invalid read.
>
> Moreover, if I cout something near the line for which valgrind reports
> the invalid read, then everything works fine, no more segmentation faults
> or invalid reads.

Before you follow Gianni's advice, make sure you have initialized
*every* variable, especially pointers.

Rares Vernica wrote:
> I compile my code with g++ (GCC) 4.1.2. My code runs just fine if I use
> the -O2 optimization flag. valgrind does not report any memory leak.
>
> When I use the -O3 flag, everything falls apart. The program reports
> Segmentation fault. valgrind reports some Invalid read.

I had a similar problem when using -O3 in connection
with -fomit-frame-pointer. Boost_Regex would just
segfault on some occasions.

Removed -fomit-frame-pointer and all was fine
(this was gcc 4.2.3 IIRC).

Regards

M.

On Jul 8, 12:32 am, Rares Vernica <ra...@ics.uci.edu> wrote:
> Rares Vernica <ra...@ics.uci.edu> writes:
> > I compile my code with g++ (GCC) 4.1.2. My code runs just
> > fine if I use the -O2 optimization flag. valgrind does not
> > report any memory leak.

> > When I use the -O3 flag, everything falls apart. The program
> > reports Segmentation fault. valgrind reports some Invalid
> > read.

> > Moreover, if I cout something near the line for which
> > valgrind reports the invalid read, then everything works
> > fine, no more segmentation faults or invalid reads.

> It was a bug in my code. Now it works fine with -O3.

> Still, I am a little bit confused how the bug generated a
> segmentation fault only with -O3.

The generated code will be different according to the
optimization level. What the differences may be, we can only
speculate, not having seen your code, nor knowing what error
you'd made.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 7, 7:32*pm, Rares Vernica <ra...@ics.uci.edu> wrote:
> Rares Vernica <ra...@ics.uci.edu> writes:
> > I compile my code with g++ (GCC) 4.1.2. My code runs just fine if I use
> > the -O2 optimization flag. valgrind does not report any memory leak.
>
> > When I use the -O3 flag, everything falls apart. The program reports
> > Segmentation fault. valgrind reports some Invalid read.
>
> > Moreover, if I cout something near the line for which valgrind reports
> > the invalid read, then everything works fine, no more segmentation faults
> > or invalid reads.
>
> It was a bug in my code. Now it works fine with -O3.
>
> Still, I am a little bit confused how the bug generated a segmentation
> fault only with -O3.
>
> Thanks.
> Rares

what was the bug?

Diego Martins <> writes:

> On Jul 7, 7:32Â*pm, Rares Vernica <ra...@ics.uci.edu> wrote:
>> Rares Vernica <ra...@ics.uci.edu> writes:
>> > I compile my code with g++ (GCC) 4.1.2. My code runs just fine if I use
>> > the -O2 optimization flag. valgrind does not report any memory leak.
>>
>> > When I use the -O3 flag, everything falls apart. The program reports
>> > Segmentation fault. valgrind reports some Invalid read.
>>
>> > Moreover, if I cout something near the line for which valgrind reports
>> > the invalid read, then everything works fine, no more segmentation faults
>> > or invalid reads.
>>
>> It was a bug in my code. Now it works fine with -O3.
>>
>> Still, I am a little bit confused how the bug generated a segmentation
>> fault only with -O3.
>>
>> Thanks.
>> Rares
>
> what was the bug?

The bug was related to the number of processing steps required to
produce the results. Because I was updating some counters incorrectly,
the algorithm had to do more steps to produce the results. Still, the
results were correct, but the code was less efficient.

Nevertheless, the processing steps should all be within correct memory
bounds.

Thanks.
Rares