This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/15180] New: compound literal syntax for POD structs gives parse error
- From: "gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Apr 2004 20:53:38 -0000
- Subject: [Bug c++/15180] New: compound literal syntax for POD structs gives parse error
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PR#12615 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12615) dealt with
parsing bugs for compound literal expressions that are used as
initializer of a variable.
Most of this was fixed in G++ 3.4.0, however there is still one case
where g++ gives an unjustified error: when the compound literal expression
for a POD struct is used to initialze a variable of a subclass of non-
POD type.
=============================== bug1.cc ==================================
struct object
{
unsigned long one_o;
unsigned int allocstamp;
};
struct gcv_object_t
{
unsigned long one_o;
operator object () const;
gcv_object_t (object obj);
gcv_object_t ();
};
void gc_mark (object obj)
{
object target0 = ((object){one_o: 0, allocstamp: 0});
gcv_object_t target1 = gcv_object_t ((object){one_o: 0, allocstamp: 0});
gcv_object_t target2 = (gcv_object_t) ((object){one_o: 0, allocstamp: 0});
gcv_object_t target3; target3 = ((object){one_o: 0, allocstamp: 0});
gcv_object_t target4 = ((object){one_o: 0, allocstamp: 0});
}
==========================================================================
$ g++ -O -c bug1.cc
bug1.cc: In function `void gc_mark(object)':
bug1.cc:20: Fehler: `target4' must be initialized by constructor, not by `{...}'
I think this is a bug because
1. The right hand side of the 'target4' initialization is an expression
(the fact that it is allowed as right-hand-side of the 'target3'
assignment proves this),
2. The right hand side of the 'target4' initialization, to be parsed
as a "initializer-clause" (see [dcl.init]), does not have the
syntax of a "{ initializer-list ,opt }", but rather is an
"assignment-expression", even a "primary-expression".
3. The right hand side is a valid expression of type 'object',
gcv_object_t has a constructor with argument type 'object', and
therefore [class.expl.init] paragraph 1 allows the initialization
of a gcv_object_t variable with an expression of type 'object'.
Environment:
System: Linux honolulu.ilog.fr 2.4.21-0.13mdk #1 Fri Mar 14 15:08:06 EST 2003 i686 unknown unknown GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.4.0/configure --prefix=/home/haible/gnu/arch/linuxgcc34 --enable-shared --enable-threads --enable-__cxa_atexit --enable-languages=c,c++,f77,java,objc --enable-nls
How-To-Repeat:
See above.
------- Additional Comments From bruno at clisp dot org 2004-04-27 20:53 -------
Fix:
The syntaxes for target1, target2, target3 provide workarounds.
--
Summary: compound literal syntax for POD structs gives parse
error
Product: gcc
Version: 3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15180