intializing the variables and compling with optimization

intializing the variables and compling with optimization

[J M Sharath Bharadwaj bharadwaj]

hi All,

Is GCC going to perform a better optimization, if I am going to
initialize the variable explicitly. I am asking this because I was
reading the GCC online doc for warning options like as in
http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Warning%20Options

Any comments

Sharath Bharadwaj

Re: intializing the variables and compling with optimization

[Andrew Haley]

J M Sharath Bharadwaj bharadwaj wrote:
> hi All,
> 
> Is GCC going to perform a better optimization, if I am going to
> initialize the variable explicitly. I am asking this because I was
> reading the GCC online doc for warning options like as in
> http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Warning%20Options

This is a strange question.

If you read an uninitialized variable your program contains undefined
behaviour, and optimization is going to be the least of your problems.
If you don't read from an uninitialized variable it doesn't matter.

Andrew.

Re: intializing the variables and compling with optimization

[John Fine]

J M Sharath Bharadwaj bharadwaj wrote:
> Is GCC going to perform a better optimization, if I am going to
> initialize the variable explicitly. I am asking this because I was
> reading the GCC online doc for warning options like as in
> http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Warning%20Options
>
>   
Maybe you need to give some example code to explain the question you are 
trying to ask.

The optional warning for uninitialized automatic variables may catch 
programming errors  that involve actual use of uninitialized values, but 
more often it generates false warnings where the compiler fails to 
understand the flow of control and doesn't realize no possible path 
through the code uses the uninitialized value.

Many programmers add an unnecessary initial value to variables, so they 
can eliminate the false warning while leaving that type of warning 
enabled (for its benefits when the code really is wrong).
In most cases adding an unnecessary initialization will make the code 
slightly less optimized.  I'm sure one could construct some strange 
example in which adding an unnecessary initialization would make the 
code more optimal, but it would need to be pretty strange.

Re: intializing the variables and compling with optimization

[J M Sharath Bharadwaj bharadwaj]

hi Andrew,

I was talking about warning option called -Wuninitialized
Here in the below code, compiler gives warning like " might be used
uninitialized in this function" for x ,
{
  int x;
  switch (y)
   {
    case 1: x = 1;
      break;
    case 2: x = 4;
      break;
    case 3: x = 5;
   }
  foo (x);
}

If the value code{y} is always 1, 2 or 3, then code{x} is
always initialized, but GCC doesn't know this. So it emits a warning.

My question was, if I am going to initialize the variable x to some
value. is that going to help for the compiler to perform better
optimization, without giving ant warnings

Sharath.



On Fri, Jul 11, 2008 at 7:19 PM, Andrew Haley <aph@redhat.com> wrote:
> J M Sharath Bharadwaj bharadwaj wrote:
>>
>> hi All,
>>
>> Is GCC going to perform a better optimization, if I am going to
>> initialize the variable explicitly. I am asking this because I was
>> reading the GCC online doc for warning options like as in
>> http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Warning%20Options
>
> This is a strange question.
>
> If you read an uninitialized variable your program contains undefined
> behaviour, and optimization is going to be the least of your problems.
> If you don't read from an uninitialized variable it doesn't matter.
>
> Andrew.
>

Re: intializing the variables and compling with optimization

[Robert William Fuller]

Maybe you should add a default: case.  That may eliminate the warning.

J M Sharath Bharadwaj bharadwaj wrote:
> hi Andrew,
> 
> I was talking about warning option called -Wuninitialized
> Here in the below code, compiler gives warning like " might be used
> uninitialized in this function" for x ,
> {
>   int x;
>   switch (y)
>    {
>     case 1: x = 1;
>       break;
>     case 2: x = 4;
>       break;
>     case 3: x = 5;
>    }
>   foo (x);
> }
> 
> If the value code{y} is always 1, 2 or 3, then code{x} is
> always initialized, but GCC doesn't know this. So it emits a warning.
> 
> My question was, if I am going to initialize the variable x to some
> value. is that going to help for the compiler to perform better
> optimization, without giving ant warnings
> 
> Sharath.
> 
> 
> 
> On Fri, Jul 11, 2008 at 7:19 PM, Andrew Haley <aph@redhat.com> wrote:
>> J M Sharath Bharadwaj bharadwaj wrote:
>>> hi All,
>>>
>>> Is GCC going to perform a better optimization, if I am going to
>>> initialize the variable explicitly. I am asking this because I was
>>> reading the GCC online doc for warning options like as in
>>> http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Warning%20Options
>> This is a strange question.
>>
>> If you read an uninitialized variable your program contains undefined
>> behaviour, and optimization is going to be the least of your problems.
>> If you don't read from an uninitialized variable it doesn't matter.
>>
>> Andrew.
>>
> 

Re: intializing the variables and compling with optimization

[Andrew Haley]

J M Sharath Bharadwaj bharadwaj wrote:
> hi Andrew,
> 
> I was talking about warning option called -Wuninitialized
> Here in the below code, compiler gives warning like " might be used
> uninitialized in this function" for x ,
> {
>   int x;
>   switch (y)
>    {
>     case 1: x = 1;
>       break;
>     case 2: x = 4;
>       break;
>     case 3: x = 5;
>    }
>   foo (x);
> }
> 
> If the value code{y} is always 1, 2 or 3, then code{x} is
> always initialized, but GCC doesn't know this. So it emits a warning.
> 
> My question was, if I am going to initialize the variable x to some
> value. is that going to help for the compiler to perform better
> optimization, without giving ant warnings

Probably not.  As Robert William Fuller said, use a default case.

Andrew.