This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH rs6000] (small C++ patch) Add intrinsics for the new vec_* specified by the C/C++ Language Extension for the CBEA
- From: <Andrew_Pinski at PlayStation dot Sony dot Com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Trevor_Smigiel at PlayStation dot Sony dot com
- Date: Wed, 1 Oct 2008 10:27:00 -0700
- Subject: Re: [PATCH rs6000] (small C++ patch) Add intrinsics for the new vec_* specified by the C/C++ Language Extension for the CBEA
Mark Mitchell <email@example.com> wrote on 09/30/2008 07:59:33 PM:
> Andrew Pinski wrote:
> > I had to add some small support for C++ to support
> > COMPOUND_LITERAL_EXPR to say it is a lvalue.
> > cp/ChangeLog:
> > * tree.c (lvalue_p_1): COMPOUND_LITERAL_EXPR is also an lvalue.
> The C++ change is OK if compound literals are lvalues in C. I'm
> slightly surprised that they are, but if so, it makes sense to treat
> them the same way in C++.
I wonder why you are surprised they are lvalues for C, they were designed
(as I understand it) to provide an anonymous variable.
Anyways here is the quote from the C99 standard which says they are
lvalues, C99 18.104.22.168/5:
If the type name specifies an array of unknown size, the size is
determined by the initializer list as specified in 6.7.8, and the type of
the compound literal is that of the completed array type. Otherwise (when
the type name specifies an object type), the type of the compound literal
is that specified by the type name. In either case, the result is an