Re: c++/9537: [3.4 regression] [New parser] problem handling const return types

Re: c++/9537: [3.4 regression] [New parser] problem handling const return types

[jason]

Synopsis: [3.4 regression] [New parser] problem handling const return types

Responsible-Changed-From-To: unassigned->jason
Responsible-Changed-By: jason
Responsible-Changed-When: Mon May  5 21:11:50 2003
Responsible-Changed-Why:
    mine
State-Changed-From-To: analyzed->closed
State-Changed-By: jason
State-Changed-When: Mon May  5 21:11:50 2003
State-Changed-Why:
    fixed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9537

Re: c++/9537: [3.4 regression] [New parser] problem handling const return types

[Wolfgang Bangerth]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Dirk Mueller <mueller@kde.org>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/9537: [3.4 regression] [New parser] problem handling const
 return types
Date: Mon, 3 Feb 2003 10:20:09 -0600 (CST)

 > It seems PR 9440 describes a similiar problem. I've noticed this only after 
 > submitting my report. sorry. 
 
 Looks similar. I'm not quite sure, though, so I leave this one open and 
 post a note against the other one.
 
 Thanks
  W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: c++/9537: [3.4 regression] [New parser] problem handling const return types

[Dirk Mueller]

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

From: Dirk Mueller <mueller@kde.org>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/9537: [3.4 regression] [New parser] problem handling const return types
Date: Mon, 3 Feb 2003 02:33:59 +0100

 bangerth@dealii.org schrieb am Sonntag, den 02. Februar 2003:
 
 
 >     Confirmed. I would say the code is legal, and even if not
 >     then it is certainly true that the error message absolutely
 >     does not make sense at all.
 
 It seems PR 9440 describes a similiar problem. I've noticed this only after 
 submitting my report. sorry. 
 
 
 -- 
 Dirk (received 805 mails today)

Re: c++/9537: [3.4 regression] [New parser] problem handling const return types

[bangerth]

Synopsis: [3.4 regression] [New parser] problem handling const return types

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Sun Feb  2 22:32:13 2003
State-Changed-Why:
    Confirmed. I would say the code is legal, and even if not
    then it is certainly true that the error message absolutely
    does not make sense at all.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9537

c++/9537: [3.4 regression] [New parser] problem handling const return types

[mueller]

>Number:         9537
>Category:       c++
>Synopsis:       [3.4 regression] [New parser] problem handling const return types
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 01 21:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Dirk Mueller
>Release:        3.4 20030201 (experimental)
>Organization:
>Environment:
System: Linux matrix 2.4.19-4GB #6 Thu Jan 30 02:58:14 CET 2003 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/opt/gcc --enable-c99 --enable-long-long --enable-shared --enable-threads --enable-languages=c,c++
>Description:

This testcase: 

=== Cut ===
class String
{
public:
    String();
    String( char *str );
    operator char *();
};

const String operator+( String s1, String ) // <- remove const here
{
  return s1;
}

String valGlue(const String before)
{
    String ret;
    return false ? ret : before + before;
}
=== Cut ===


does no longer compile:

$ g++ -c foo.cc
foo.cpp: In function `String valGlue(String)':
foo.cpp:18: error: non-lvalue in unary `&'

It does compile when removing the const in the marked place, so I'm not sure if this is a bug in the parser or by design. 


http://gcc.gnu.org/ml/gcc/2003-01/msg01643.html

seems to describe a similiar, however not identical problem. 



>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: