'SR.1419' is used uninitialized in this function...

'SR.1419' is used uninitialized in this function...

[Benjamin Redelings]

Hello,

    I'm testing 4.0 snapshot 2005-01-15 by trying to compile my 
program.  I get error messages like the following a few times:

    'SR.1419' is used uninitialized in this function...

I'm guessing that this is an SSA name and should not be reported to the 
user.  Is this a known bug?  Should I file a PR?

-BenRI

Re: 'SR.1419' is used uninitialized in this function...

[Andrew Pinski]

On Jan 25, 2005, at 12:58 PM, Benjamin Redelings wrote:

> Hello,
>
>    I'm testing 4.0 snapshot 2005-01-15 by trying to compile my 
> program.  I get error messages like the following a few times:
>
>    'SR.1419' is used uninitialized in this function...
>
> I'm guessing that this is an SSA name and should not be reported to 
> the user.  Is this a known bug?  Should I file a PR?

Yes it is known but it is most likely a bug in your code.
The problem is that SR.1419 should really be named
"<<unnamed>>.structmember".

-- Pinski

Re: 'SR.1419' is used uninitialized in this function...

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| On Jan 25, 2005, at 12:58 PM, Benjamin Redelings wrote:
| 
| > Hello,
| >
| >    I'm testing 4.0 snapshot 2005-01-15 by trying to compile my
| > program.  I get error messages like the following a few times:
| >
| >    'SR.1419' is used uninitialized in this function...
| >
| > I'm guessing that this is an SSA name and should not be reported to
| > the user.  Is this a known bug?  Should I file a PR?
| 
| Yes it is known but it is most likely a bug in your code.
| The problem is that SR.1419 should really be named
| "<<unnamed>>.structmember".

Not really.  I've already filled a PR (which I think  you quickly
closed) where SR.xxxx should have been A::i (where A is a base
class).  I wanted to fix this by using DECL_ABSTRACT_ORIGIN but RTH
thinks that is not appropriate.  Anyhow, we need to put a back
reference to the original tree that was SRAed.

-- Gaby

Re: 'SR.1419' is used uninitialized in this function...

[Benjamin Redelings]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Gabriel Dos Reis wrote:

>Andrew Pinski <pinskia@physics.uc.edu> writes:
>
>| On Jan 25, 2005, at 12:58 PM, Benjamin Redelings wrote:
>| 
>| > Hello,
>| >
>| >    I'm testing 4.0 snapshot 2005-01-15 by trying to compile my
>| > program.  I get error messages like the following a few times:
>| >
>| >    'SR.1419' is used uninitialized in this function...
>| >
>| > I'm guessing that this is an SSA name and should not be reported to
>| > the user.  Is this a known bug?  Should I file a PR?
>| 
>| Yes it is known but it is most likely a bug in your code.
>| The problem is that SR.1419 should really be named
>| "<<unnamed>>.structmember".
>
>Not really.  I've already filled a PR (which I think  you quickly
>closed) where SR.xxxx should have been A::i (where A is a base
>class).  I wanted to fix this by using DECL_ABSTRACT_ORIGIN but RTH
>thinks that is not appropriate.  Anyhow, we need to put a back
>reference to the original tree that was SRAed.
>
>-- Gaby
>  
>

I now have a 30-line test-case (attatched) which triggers two bugs:
a) the structure member has a name, but is not named.
b) the structure member is not actually used, despite the warning.

Ways to make the problem go away include:
a) make a function non-virtual
b) make a function not a template
c) remove the undefined, and supposedly unused variable.
d) turn off all optimization.

-BenRI

[-- Attachment #2: test-SR4.C --]
[-- Type: text/x-c++src, Size: 668 bytes --]

struct branchview;

struct iterator 
{
  unsigned circuits;  // Warning goes away if you remove this line

  virtual branchview operator*() const;  // Warning goes away if you remove 'virtual'

  iterator() {}
};

struct branchview 
{
  iterator my_iterator() const {return iterator();}

  branchview(){}
};

inline branchview iterator::operator*() const {
  return branchview();
}

// You have to do this inside a template to get the bug, I think.
template<class iterator_t>
inline void append(const iterator_t& start, branchview& t) {
  iterator_t i = start;
  t = *i;
}

void iterator_set(const branchview& bv1,branchview& bv2) {
  append(bv1.my_iterator(),bv2);
}

Re: 'SR.1419' is used uninitialized in this function...

[Richard Henderson]

On Tue, Jan 25, 2005 at 12:48:58PM -0800, Benjamin Redelings wrote:
> struct branchview;
> 
> struct iterator 
> {
>   unsigned circuits;  // Warning goes away if you remove this line
> 
>   virtual branchview operator*() const;  // Warning goes away if you remove 'virtual'
> 
>   iterator() {}
> };
> 
> struct branchview 
> {
>   iterator my_iterator() const {return iterator();}
> 
>   branchview(){}
> };
> 
> inline branchview iterator::operator*() const {
>   return branchview();
> }
> 
> // You have to do this inside a template to get the bug, I think.
> template<class iterator_t>
> inline void append(const iterator_t& start, branchview& t) {
>   iterator_t i = start;
>   t = *i;
> }
> 
> void iterator_set(const branchview& bv1,branchview& bv2) {
>   append(bv1.my_iterator(),bv2);
> }

The result of my_iterator is unnamed, and the element circuits
is indeed uninitialized when it it copied to "i" in append.

Ergo I do not see the warning as actively incorrect, modulo the
name used in the warning text.



r~

Re: 'SR.1419' is used uninitialized in this function...

[Jonathan Wakely]

On Tue, Jan 25, 2005 at 12:48:58PM -0800, Benjamin Redelings wrote:

> I now have a 30-line test-case (attatched) which triggers two bugs:
> a) the structure member has a name, but is not named.
> b) the structure member is not actually used, despite the warning.

It's used in the compiler-generated copy constructor, which would be
something like this:

    iterator(const iterator& other) : circuits(other.circuits) {}

and it is called when branchview::my_iterator returns by value.

> Ways to make the problem go away include:
> a) make a function non-virtual
> b) make a function not a template
> c) remove the undefined, and supposedly unused variable.
> d) turn off all optimization.

Or alternatively, initialise the variable in the constructor:

    iterator() : circuits() {}

jon

-- 
Dull but sincere filler