From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7755 invoked by alias); 14 Jun 2011 14:18:32 -0000 Received: (qmail 7746 invoked by uid 22791); 14 Jun 2011 14:18:31 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Jun 2011 14:18:18 +0000 From: "gdr at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/48365] Non-constant references in std::valarray::operator X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gdr at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 14 Jun 2011 14:18:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01213.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 Gabriel Dos Reis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gdr at gcc dot gnu.org --- Comment #5 from Gabriel Dos Reis 2011-06-14 14:17:54 UTC --- (In reply to comment #1) > Gaby, can you have a look to this issue? It seems to me that in general, given > the expression templates mechanism we have in place, something like > > k = k[0] * k, (1) > > where k is a valarray, cannot possibly work as intuitively expected, because > the multiplication is expanded "in place": operator= triggers the computation > of the new k[0] and then k[1] which definitely uses the new k[0], contrary to > intuition. Is this actually undefined behavior, like morally in > > operator*(const T& t, const valarray& v) > > t cannot be an element of v? Seems something falling under the special features > of valarray wrt aliasing, but I don't see it mentioned anywhere in C++03. > > Interestingly, if I change (1) to > > k *= k[0] > > which should be in principle equivalent, the behavior is the same on GCC, > whereas another implementation of valarray agrees with GCC in this case. Yes, Paolo, you are right. Valarray computations assume absence of certain form of aliasing, and this appears to be one of them.