[Bug c++/21672] New: Loses temporary in complex expression

[Bug c++/21672] New: Loses temporary in complex expression

[igodard at pacbell dot net]

The attached source (and compiler output) produces the "testBitset" executable, 
which when run (no command line arguments) prints to std::cerr:

~/ootbc/common/test/src$ testBitset
p is: bitset<A>{a, c, e, g, k}
q is: bitset<A>{b:c, h, j:k}
r is: bitset<A>{a:c, e, g:h, j:k}
but (p|q) is: bitset<A>{d, f, h, j:k}

"bitset" is a class that is similar to std::bitset except that it has one bit 
for each member of the enumeration that is a template argument to bitset. It is 
built on top of std::bitset and all bitset operations ultimately reflect to 
std::bitset.

Stream operator<< is overloaded to display bitsets as shown above. Bitset 
defines operator| to produce a new bitset (of the same type) that is the bitwise 
"or" of the two arguments; this reflects ultimately to std::bitset::operator|=.

The test case "main" contains "bitset<A> r = (p|q);", where "p|q" produces a 
temporary that is immediately used to initialize r. When printed out by 
"std::cerr << r" this prints the correct value for the result of the "|" 
operation.

However, if the "|" result is not stored into a variable but instead the 
temporary is passed directly to the streaming operator<< by "std::cerr << (p|q)" 
then the printed value is garbage. Exploration with the debugger shows that the 
temporary is being overwritten. The temporary should live to the end of the 
largest surrounding expression, which is the whole print statement, but it is 
not.

-- 
           Summary: Loses temporary in complex expression
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-05-19 21:22 -------
Created an attachment (id=8932)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8932&action=view)
source code (compressed)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-05-19 21:22 -------
Created an attachment (id=8931)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8931&action=view)
compiler output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 22:56 -------
Not a bug because:
 friend
 const
 T& operator |(T t1, const T& t2) { return t1 |= t2; }
is being invoked, this comes from:
template<typename T>
class logicalMixin {

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-05-19 23:11 -------
Yes, the friend function is returning a reference to its own argument, though
that seems to disappear as the body gets inlined in *most* cases :-)

So please reopen this as a "missing warning" bug. In most cases of returning
a reference to a function local, like:

int& foo() { int i; return i; }

you get:
~/ootbc/members$ g++ foo.cc
foo.cc: In function `int& foo()':
foo.cc:1: warning: reference to local variable `i' returned

but apparently the warning logic overlooks the same problem when returning
arguments.

Ivan

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:19 -------
(In reply to comment #4)
> but apparently the warning logic overlooks the same problem when returning
> arguments.

Actually it cannot know and here is why,
take the following example:
template<class T> const
 T& operator |(T t1, const T& t2) { return t1 |= t2; }

struct f{ f &operator|=(const f&);};
f i;
f j;

f h = i | j;

We call |= which it self returns a reference so there is no way to the compiler to know it is actually 
returning a local variable or not.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:21 -------
Here is another example where we don't know for sure it shows how the compiler uses operators in 
C++:
template<class T> const
 T& g(T t1, const T& t2) { return t1.h(t2); }

struct f{ f &h(const f&);};
f i;
f j;

f h = g(i , j);

h is the operator for |= and g is the operator for |.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-19 23:27 -------
Subject: Re:  Loses temporary in complex expression

"igodard at pacbell dot net" <gcc-bugzilla@gcc.gnu.org> writes:

| Yes, the friend function is returning a reference to its own argument, though
| that seems to disappear as the body gets inlined in *most* cases :-)
| 
| So please reopen this as a "missing warning" bug. In most cases of returning
| a reference to a function local, like:
| 
| int& foo() { int i; return i; }
| 
| you get:
| ~/ootbc/members$ g++ foo.cc
| foo.cc: In function `int& foo()':
| foo.cc:1: warning: reference to local variable `i' returned
| 
| but apparently the warning logic overlooks the same problem when returning
| arguments.

agreed.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-19 23:31 -------
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:19 -------
| (In reply to comment #4)
| > but apparently the warning logic overlooks the same problem when returning
| > arguments.
| 
| Actually it cannot know and here is why,

Andrew --

  Please, be less hastly when analyzing PRs.  If you look through the
claims, some of them are valid.  

| take the following example:
| template<class T> const
|  T& operator |(T t1, const T& t2) { return t1 |= t2; }
| 
| struct f{ f &operator|=(const f&);};
| f i;
| f j;
| 
| f h = i | j;
| 
| We call |= which it self returns a reference so there is no way to
| the compiler to know it is actually returning a local variable or
| not.

Yes, but not all cases fall under that complication.  Simple cases
should be handled.  Please reopen this PR.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-19 23:35 -------
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Here is another example where we don't know for sure it shows how the compiler uses operators in 
| C++:
| template<class T> const
|  T& g(T t1, const T& t2) { return t1.h(t2); }
| 
| struct f{ f &h(const f&);};
| f i;
| f j;
| 
| f h = g(i , j);
| 
| h is the operator for |= and g is the operator for |.

And we can construct more.  But it does not rule out the fact that we
should handle the simple cases.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:40 -------
(In reply to comment #9)
> And we can construct more.  But it does not rule out the fact that we
> should handle the simple cases.

What assuming |= returns *this, that is just wrong and you know it, if the compiler assumes that, then 
we will get false warnings for places which don't return a reference to a temporary variable.

Also I copied the code from his example so the example in comment #5 is just a reduced testcase for 
his example.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-05-19 23:42 -------
In particular, once you get all the template armwaving out of it:

int& foo(int i) { return i; }

should warn and does not.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:42 -------
(In reply to comment #9)
> And we can construct more.  But it does not rule out the fact that we
> should handle the simple cases.

Also if you read comment #4, the simple cases are already handled.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-19 23:46 -------
(In reply to comment #12)
> In particular, once you get all the template armwaving out of it:
> 
> int& foo(int i) { return i; }
> 
> should warn and does not.

The following example does not warn before 4.0.0:
template<int>
int& foo(int i) { return i; }
int &g = foo<1>(1);

So that problem was already fixed.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-05-19 23:54 -------
So the bug should be changed to "valid, verified, already fixed, won't back port"?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-20 00:12 -------
Subject: Re:  Loses temporary in complex expression

"igodard at pacbell dot net" <gcc-bugzilla@gcc.gnu.org> writes:

| In particular, once you get all the template armwaving out of it:
| 
| int& foo(int i) { return i; }
| 
| should warn and does not.

It does with my compiler:
% cat a.C && g++ -c -Wall a.C 

int& f(int i)
{
   return i;
}
a.C: In function 'int& f(int)':
a.C:2: warning: reference to local variable 'i' returned

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672

[Bug c++/21672] Loses temporary in complex expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-20 00:15 -------
Subject: Re:  Loses temporary in complex expression

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #9)
| > And we can construct more.  But it does not rule out the fact that we
| > should handle the simple cases.
| 
| What assuming |= returns *this, that is just wrong and you know it,

I can't parse that.

| if the compiler assumes that, then we will get false warnings for
| places which don't return a reference to a temporary variable. 

Since you're crediting me of knowing something (I don't know exactly
what :-)) you must also credit me of not wanting false warnings.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21672