* [Bug libstdc++/48365] Non-constant references in std::valarray::operator
2011-03-30 14:11 [Bug libstdc++/48365] New: Non-constant references in std::valarray::operator denin at mail dot ru
@ 2011-03-30 15:44 ` paolo.carlini at oracle dot com
2011-03-31 20:30 ` paolo.carlini at oracle dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-03-30 15:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/48365] Non-constant references in std::valarray::operator
2011-03-30 14:11 [Bug libstdc++/48365] New: Non-constant references in std::valarray::operator denin at mail dot ru
2011-03-30 15:44 ` [Bug libstdc++/48365] " paolo.carlini at oracle dot com
@ 2011-03-31 20:30 ` paolo.carlini at oracle dot com
2011-04-11 18:34 ` paolo.carlini at oracle dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-03-31 20:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-03-31 19:18:28 UTC ---
To further clarify, the issue boils down to class _BinBase1 (and _BinBase2)
using only const ref data members for performance reasons, likewise elsewhere
copies are always carefully avoided (for instance in k *= k[0] in my last
message in the audit trail). I could change that, but I want hear Gaby first.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/48365] Non-constant references in std::valarray::operator
2011-03-30 14:11 [Bug libstdc++/48365] New: Non-constant references in std::valarray::operator denin at mail dot ru
2011-03-30 15:44 ` [Bug libstdc++/48365] " paolo.carlini at oracle dot com
2011-03-31 20:30 ` paolo.carlini at oracle dot com
@ 2011-04-11 18:34 ` paolo.carlini at oracle dot com
2011-06-14 14:11 ` paolo.carlini at oracle dot com
2011-06-14 14:18 ` gdr at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-04-11 18:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-11 18:33:53 UTC ---
Gaby, any comments on this? Thanks in advance.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/48365] Non-constant references in std::valarray::operator
2011-03-30 14:11 [Bug libstdc++/48365] New: Non-constant references in std::valarray::operator denin at mail dot ru
` (2 preceding siblings ...)
2011-04-11 18:34 ` paolo.carlini at oracle dot com
@ 2011-06-14 14:11 ` paolo.carlini at oracle dot com
2011-06-14 14:18 ` gdr at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-06-14 14:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo.carlini at oracle dot
| |com
--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 14:10:48 UTC ---
Gaby, we should somehow resolve this one too...
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/48365] Non-constant references in std::valarray::operator
2011-03-30 14:11 [Bug libstdc++/48365] New: Non-constant references in std::valarray::operator denin at mail dot ru
` (3 preceding siblings ...)
2011-06-14 14:11 ` paolo.carlini at oracle dot com
@ 2011-06-14 14:18 ` gdr at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: gdr at gcc dot gnu.org @ 2011-06-14 14:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread