public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/21672] New: Loses temporary in complex expression
@ 2005-05-19 21:20 igodard at pacbell dot net
  2005-05-19 21:22 ` [Bug c++/21672] " igodard at pacbell dot net
                   ` (15 more replies)
  0 siblings, 16 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 21:20 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
@ 2005-05-19 21:22 ` igodard at pacbell dot net
  2005-05-19 21:22 ` igodard at pacbell dot net
                   ` (14 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 21:22 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
  2005-05-19 21:22 ` [Bug c++/21672] " igodard at pacbell dot net
@ 2005-05-19 21:22 ` igodard at pacbell dot net
  2005-05-19 22:56 ` pinskia at gcc dot gnu dot org
                   ` (13 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 21:22 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
  2005-05-19 21:22 ` [Bug c++/21672] " igodard at pacbell dot net
  2005-05-19 21:22 ` igodard at pacbell dot net
@ 2005-05-19 22:56 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:12 ` igodard at pacbell dot net
                   ` (12 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 22:56 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (2 preceding siblings ...)
  2005-05-19 22:56 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:12 ` igodard at pacbell dot net
  2005-05-19 23:19 ` pinskia at gcc dot gnu dot org
                   ` (11 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 23:12 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (3 preceding siblings ...)
  2005-05-19 23:12 ` igodard at pacbell dot net
@ 2005-05-19 23:19 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:21 ` pinskia at gcc dot gnu dot org
                   ` (10 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 23:19 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (4 preceding siblings ...)
  2005-05-19 23:19 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:21 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:27 ` gdr at integrable-solutions dot net
                   ` (9 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 23:21 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (5 preceding siblings ...)
  2005-05-19 23:21 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:27 ` gdr at integrable-solutions dot net
  2005-05-19 23:31 ` gdr at integrable-solutions dot net
                   ` (8 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-19 23:27 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (6 preceding siblings ...)
  2005-05-19 23:27 ` gdr at integrable-solutions dot net
@ 2005-05-19 23:31 ` gdr at integrable-solutions dot net
  2005-05-19 23:35 ` gdr at integrable-solutions dot net
                   ` (7 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-19 23:31 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (7 preceding siblings ...)
  2005-05-19 23:31 ` gdr at integrable-solutions dot net
@ 2005-05-19 23:35 ` gdr at integrable-solutions dot net
  2005-05-19 23:40 ` pinskia at gcc dot gnu dot org
                   ` (6 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-19 23:35 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (8 preceding siblings ...)
  2005-05-19 23:35 ` gdr at integrable-solutions dot net
@ 2005-05-19 23:40 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:42 ` pinskia at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 23:40 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (9 preceding siblings ...)
  2005-05-19 23:40 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:42 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:42 ` igodard at pacbell dot net
                   ` (4 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 23:42 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (10 preceding siblings ...)
  2005-05-19 23:42 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:42 ` igodard at pacbell dot net
  2005-05-19 23:46 ` pinskia at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 23:42 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (11 preceding siblings ...)
  2005-05-19 23:42 ` igodard at pacbell dot net
@ 2005-05-19 23:46 ` pinskia at gcc dot gnu dot org
  2005-05-19 23:54 ` igodard at pacbell dot net
                   ` (2 subsequent siblings)
  15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-19 23:46 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (12 preceding siblings ...)
  2005-05-19 23:46 ` pinskia at gcc dot gnu dot org
@ 2005-05-19 23:54 ` igodard at pacbell dot net
  2005-05-20  0:12 ` gdr at integrable-solutions dot net
  2005-05-20  0:15 ` gdr at integrable-solutions dot net
  15 siblings, 0 replies; 17+ messages in thread
From: igodard at pacbell dot net @ 2005-05-19 23:54 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (13 preceding siblings ...)
  2005-05-19 23:54 ` igodard at pacbell dot net
@ 2005-05-20  0:12 ` gdr at integrable-solutions dot net
  2005-05-20  0:15 ` gdr at integrable-solutions dot net
  15 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-20  0:12 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Bug c++/21672] Loses temporary in complex expression
  2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
                   ` (14 preceding siblings ...)
  2005-05-20  0:12 ` gdr at integrable-solutions dot net
@ 2005-05-20  0:15 ` gdr at integrable-solutions dot net
  15 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2005-05-20  0:15 UTC (permalink / raw)
  To: gcc-bugs


------- 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2005-05-20  0:15 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-19 21:20 [Bug c++/21672] New: Loses temporary in complex expression igodard at pacbell dot net
2005-05-19 21:22 ` [Bug c++/21672] " igodard at pacbell dot net
2005-05-19 21:22 ` igodard at pacbell dot net
2005-05-19 22:56 ` pinskia at gcc dot gnu dot org
2005-05-19 23:12 ` igodard at pacbell dot net
2005-05-19 23:19 ` pinskia at gcc dot gnu dot org
2005-05-19 23:21 ` pinskia at gcc dot gnu dot org
2005-05-19 23:27 ` gdr at integrable-solutions dot net
2005-05-19 23:31 ` gdr at integrable-solutions dot net
2005-05-19 23:35 ` gdr at integrable-solutions dot net
2005-05-19 23:40 ` pinskia at gcc dot gnu dot org
2005-05-19 23:42 ` pinskia at gcc dot gnu dot org
2005-05-19 23:42 ` igodard at pacbell dot net
2005-05-19 23:46 ` pinskia at gcc dot gnu dot org
2005-05-19 23:54 ` igodard at pacbell dot net
2005-05-20  0:12 ` gdr at integrable-solutions dot net
2005-05-20  0:15 ` gdr at integrable-solutions dot net

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).