http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #6 from joseph at codesourcery dot com ---
I see nothing that says anything about the sequencing of side effects in
initialization expressions with respect to the actual initialization
itself, or parts thereof - either to require a p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #5 from jimis ---
Andreas: On a second thought, this paragraph only talks about the order
*within* the initialisation list. But no matter of that order, the
initialisation list is always evaluated to:
{
.ai_fam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #4 from jimis ---
Thanks Andreas, that's the reference I was looking for!
I guess since this code triggers unspecified behaviour, a warning would be even
more needed. :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #3 from Andreas Schwab ---
6.7.9 Initialization
23 The evaluations of the initialization list expressions are indeterminately
sequenced with respect to one another and thus the order in which any side
effects occur is unspecified.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #2 from jimis ---
(In reply to Marek Polacek from comment #1)
> I see nothing surprising here; an assignment expression has the value of the
> left operand after the assignment. So we 1) set query2.ai_flags to
> AI_PASSIVE, 2) use thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
