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: "paolo.carlini at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 30 Mar 2011 15:29:25 +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
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|denin at mail dot ru |gdr@integrable-solutions.ne
| |t
--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-03-30 15:29:21 UTC ---
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.