Re: c++/1833

Re: c++/1833

[Wolfgang Bangerth]

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org, Giovanni Bajo <giovannibajo@libero.it>
Cc:  
Subject: Re: c++/1833
Date: Thu, 8 May 2003 18:38:11 -0500 (CDT)

 This is a gcc extension: cast-as-lvalue. I personally think it's an evil 
 one.
 
 Binding it to a reference yields all sorts of problems. I closed several 
 duplicates of some such bug recently. Giovanni, check 1920 and 7884, 
 possibly also 7503.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Re: c++/1833

[Gabriel Dos Reis]

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/1833
Date: 09 May 2003 09:05:35 +0200

 Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:
 
 | The following reply was made to PR c++/1833; it has been noted by GNATS.
 | 
 | From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
 | To: gcc-gnats@gcc.gnu.org, Giovanni Bajo <giovannibajo@libero.it>
 | Cc:  
 | Subject: Re: c++/1833
 | Date: Thu, 8 May 2003 18:38:11 -0500 (CDT)
 | 
 |  This is a gcc extension: cast-as-lvalue. I personally think it's an evil 
 |  one.
 
 It should be removed.
 
 -- Gaby

Re: c++/1833

[Nigel Stewart]

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Nigel Stewart <nigels@nigels.com>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/1833
Date: Fri, 04 Apr 2003 12:58:54 +1000

 Wolfgang,
 
 Heeding your advice about aliasing rules, I've replaced
 the cast with a union.  Problem is solved.  However, I
 would suggest that gcc should provide warnings or errors
 in the case of being fed illegal code.
 
 float foo()
 {
 	assert(sizeof(unsigned int)==sizeof(float));
 	union { float f; unsigned int i; } tmp;
 	tmp.i = (127<<23) | (1<<22);
 	return tmp.f;
 }
 
 Thanks for your response, and my apologies for cluttering
 the bug database...
 
 N Stewart
 
 > Nigel,
 > the problem you sent has nothing to do with the problem described in PR 
 > 1833. You are violating aliasing rules. The code in the report is legal, 
 > yours is not.
 > 
 > W.
 

Re: c++/1833

[Wolfgang Bangerth]

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org, <nigels@nigels.com>
Cc:  
Subject: Re: c++/1833
Date: Thu, 3 Apr 2003 11:31:58 -0600 (CST)

 Nigel,
 the problem you sent has nothing to do with the problem described in PR 
 1833. You are violating aliasing rules. The code in the report is legal, 
 yours is not.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Re: c++/1833

[aoliva]

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: aoliva@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, peteb@sitera.com
Cc:  
Subject: Re: c++/1833
Date: 2 Mar 2001 10:26:28 -0000

 Synopsis: inlining sometimes causes incorrect behavior
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: aoliva
 State-Changed-When: Fri Mar  2 02:26:28 2001
 State-Changed-Why:
     There is indeed a bug.  The problem is that the result of the cast is an rvalue, because the cast-to type is not a reference type.  Therefore, a temporary should be created.  However, a temporary cannot be bound to a non-const reference, but g++ happily binds it to frob2's argument, even with -ansi -pedantic.
     Even if the binding-to-non-const were to be done as an extension, it still shouldn't modify variable s; it should modify the temporary, then discard it.
     WRT the difference between the inline and the non-inline functions, the problem is likely to be in the tree level, because the initial RTL dump is already significantly different for the two functions.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1833&database=gcc