Bug 13384 - error: non-lvalue in assignment - message a little misleading for C++
Summary: error: non-lvalue in assignment - message a little misleading for C++
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3.1
: P2 minor
Target Milestone: 4.2.0
Assignee: Gabriel Dos Reis
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2003-12-11 16:36 UTC by gianni
Modified: 2005-12-12 20:12 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 2.95.3 3.2.3 3.3.4 3.4.0 4.0.0
Last reconfirmed: 2005-11-26 08:57:41


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gianni 2003-12-11 16:36:15 UTC
The code below :

struct C
{
    int a;

    C()
      : a(1)
    {
    }
};

template<typename T> void func()
{
    T() = T();
}

int main()
{
    func<C>();
    func<int>();
}

Produces the error message

"error: non-lvalue in assignment"

As you can see, the first instantiation (func<C>) is quite happy to call assign
on an rvalue.  The second (func<int>) uses the built-in operator= which does not
allow assignment to non-lvalue.  While the message is accurate, it would be IMHO
better if the message was:

"error: non-lvalue in built-in assignment" (suggestions welcome)

This message geneaology is probably from the C compiler and is a little
misleading for C++.
Comment 1 Wolfgang Bangerth 2003-12-11 17:05:24 UTC
I can confirm the behavior, though I'm not sure whether we really 
need to change the error message. Gaby -- you're the diagnostics 
maintainer, so it's your call. 
 
W. 
Comment 2 Andrew Pinski 2004-03-13 06:43:04 UTC
Icc 6.0 produces:
pr13384.cc(15): error: expression must be a modifiable lvalue
      T() = T();
      ^
          detected during instantiation of "void func<T>() [with T=int]" 

compilation aborted for pr13384.cc (code 2)
Comment 3 Andrew Pinski 2005-01-29 13:32:04 UTC
But note C++ has a definition of lvalue and rvalues so the message is still correct in the C++ sense.
Comment 4 Gabriel Dos Reis 2005-11-26 08:57:41 UTC
(In reply to comment #1)
> I can confirm the behavior, though I'm not sure whether we really 
> need to change the error message. Gaby -- you're the diagnostics 
> maintainer, so it's your call. 

I believe it is OK to add "built-in" for the purpose of removing
ambiguities.

-- Gaby

Comment 5 Gabriel Dos Reis 2005-12-01 12:00:28 UTC
Subject: Bug 13384

Author: gdr
Date: Thu Dec  1 12:00:17 2005
New Revision: 107816

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107816
Log:
        PR c/13384
        * c-common.c (lvalue_error): Fix wording.
testsuite/
        PR c/13384
        * gcc.dg/pr17730-1.c: Adjust.
        * gcc.dg/lvalue1.c (main): Likewise.
        * gcc.dg/lvalue-2.c: Likewise.
        * g++.dg/pr7503-3.C

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-common.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/opt/pr7503-3.C
    trunk/gcc/testsuite/gcc.dg/lvalue-2.c
    trunk/gcc/testsuite/gcc.dg/lvalue1.c
    trunk/gcc/testsuite/gcc.dg/pr17730-1.c

Comment 6 Gabriel Dos Reis 2005-12-01 12:01:27 UTC
Fixed in 4.2.x (mainline).
Comment 7 Jakub Jelinek 2005-12-05 08:02:57 UTC
Subject: Bug 13384

Author: jakub
Date: Mon Dec  5 08:02:53 2005
New Revision: 108045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108045
Log:
	PR c/13384
	* gcc.dg/gomp/atomic-5.c: Adjust.
	* g++.dg/gomp/atomic-5.C: Likewise.

Modified:
    branches/gomp-20050608-branch/gcc/testsuite/ChangeLog.gomp
    branches/gomp-20050608-branch/gcc/testsuite/g++.dg/gomp/atomic-5.C
    branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/gomp/atomic-5.c