This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/48365] Non-constant references in std::valarray::operator


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]