This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/48365] Non-constant references in std::valarray::operator
- From: "gdr at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 14 Jun 2011 14:18:18 +0000
- Subject: [Bug libstdc++/48365] Non-constant references in std::valarray::operator
- Auto-submitted: auto-generated
- References: <bug-48365-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gdr at gcc dot gnu.org
--- Comment #5 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 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<T>& 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.