This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Question concerning "Local Variables" window and missing variables


> -----Original Message-----
> From: Donna S Womble [mailto:dsw@mbay.net]
> Sent: Tuesday, May 29, 2001 11:39 PM
> To: insight@sourceware.cygnus.com
> Subject: Question concerning "Local Variables" window and missing
> variables
> 
> 
> Hello,  
> 
> Please forgive my naivete...  I have generated a very simple 
> C++ program
> to outline my question/problem.  When I run the following 
> with Insight,
> and I pull up the "Local Variables" window,  it shows that I have
> absolutely no local variables no matter where I set a breakpoint.

This is probably just due to the optimizer getting in your way:

> 
> #include <iostream>
> int main()
> {
>   for (int i(0); i < 10; i++)
>     {
>       double foo(100.);
>       for (int j(10); j < 20; j++)
>         {
>           double goo(i*1000.);
>           double hoo(j*500.);
>           cout << i << "\t" << j << "\t" << goo << "\t" << 
> hoo << endl;
>         }
>     }
>   return 0;
> }
> 

In this example, the C++ compiler KNOWS that "goo" is only used to pass
"i*1000." to the "<<" stream operator; it doesn't NEED to allocate it, and
usually is able to eliminate the local variable completely, even in
non-very-advanced optimosation modes: you see you just create a variable,
set it to some value, pass the value to some other method then delete the
variable... Not very hard to see you can just eliminate it.

The same apply to hoo, of course, and even more to foo (you don't even use
the value of foo anywhere...).

As for i and j, they are loop control variable that the compiler will try to
optimize out as far as possible, especially when the loops are executed a
compile-time-known constant number of times. A smart compiler could even be
able to compile your program as follows:

#include <iostream>
int main()
{
  cout << 0 << "\t" << 10 << "\t" << 0. << "\t" << 5000. << endl;
  cout << 0 << "\t" << 11 << "\t" << 0. << "\t" << 5500. << endl;
    ....
  cout << 9 << "\t" << 19 << "\t" << 9000. << "\t" << 9500. << endl;
  return 0;
}

> 
> Shouldn't one be able to *see* the variable "i" as a local from within
> the scope of the i-loop (e.g. at line 6 = double foo(100.); )??? 
> Likewise for "j", "goo", and "hoo" inside the j-loop.

You can't see them in the debugger as they do not exist in the compiled
program :-)

> 
> Strangely enough, if I define foo, goo, and hoo  as doubles before the
> "i" loop, then I can *see* ALL the variables (including i and j) as in
> the same code (modified) below:

Here you complicate the task of the optimizer, by declaring variables whose
values are computed by using the loop-control variables outside of these
loops. It would take a lot of work for the optimizer to actually be sure
that the declarations for foo, goo and hoo could be moved INSIDE the loops
and thus optimized out...

Note that in fact in C++ it is even more complicated than in C, as 

	XXX xxx = x;

is totally different from

	XXX xxx;
	xxx = x;

In the first case you use the XXX constructor to assign INITIAL value x to
xxx, while in the second case you use a default constructor to create the
xxx variable, the use the assignment operator to give it a NEW value. OK, in
this case (using double instead of a class XXX), the compiler knows that
there is no difference between initialization and
creation-undefined/assignment, but it needs to work as if they were
differences, at least to be able to warn you if you use foo before giving it
a value...

So in this case the compiler will create the foo, goo and hoo variables and
the debugger will see them 8-0)

As for i and j, one can only guess that common-subexpression-elimination of
the foo/hoo/goo variable values involving i and j, the compiler will need to
create the variables as well...

> 
> #include <iostream>
> int main()
> {
>   double foo, goo, hoo;
>   for (int i(0); i < 10; i++)
>     {
>       foo = 100.;
>       int j;
>       for ( j = 10 ; j < 20; j++)
>         {
>           goo = i*1000.;
>           hoo = j*500.;
>           cout << i << "\t" << j << "\t" << goo << "\t" << 
> hoo << endl;
>         }
>     }
>   return 0;
> }
> 
> 
> 
> Am I missing something really simple here??? Please help.

Not really simple; understanding compiler optimization is usually a very
tough exercise :-) the only simple thing here is just blaming the right
tool: GCC (which is NOT buggy in this case anyway) and not GDB.

HTH

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]