🚀 go-pugleaf

(Using a GCC extension, and something vaguely similar to:

	struct s { int ty:3, mark:1, val:28; } x;

	x = (struct s) { ty: 5, mark: 0, val: x.mark ? ... : ... };

GCC winds up assigning to x.mark before computing the value for the
x.val initializer, and hence taking the wrong branch of the ?: expression.)

In article <41fdhb$7nd@light.twinsun.com> Paul Eggert <eggert@twinsun.com>
wrote:
>... the [compound literal and extended initializer] extensions do
>appear in the C9X drafts ...  [What they say] means that the compound
>literal `(struct s) { a: x.b, b: x.a }' evaluates to the value of an
>unnamed object, so the ``overlapping move'' clause does not apply.
>So, as far as the latest public C9X drafts are concerned, the above
>example has well-defined semantics.
>
>That being said, I'm not sure I've boiled down Wing's example to the
>right question; it's possible that Chris Torek is objecting to some
>other part of Wing's example, which is much more complicated than
>my boiled-down version.

No, I think this is in fact the right question, and if GCC intends
to implement the C9X proposal, GCC has gotten it wrong.  (In the
documentation I have for GCC, however, it does not mention any of
this, so that the old `overlapping move' bugaboo may well apply.)

Further discussion probably belongs in a GNU newsgroup.  I will post
this same article to gnu.gcc.bug (separately, as that one requires
mailing it to the mailing list, which I think is auto-gatewayed and
may lose the Newgroups: header).
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA	Domain:	torek@bsdi.com	+1 510 549 1145