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

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

[denin at mail dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365

           Summary: Non-constant references in std::valarray::operator
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: denin@mail.ru


Created attachment 23819
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23819
Test code

When calling "valarray*scalar" arithmetic operators, where scalar is the
element of valarray, it is modified during execution, thus influencig the
result, though STL definition says that parameters of the operator are const
references, and the result is the new valarray object.
Attached is the code that produces output "4:12", while "4:6" expected, even
when compiled with -O0.

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

[paolo.carlini at oracle dot com]

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.

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

[paolo.carlini at oracle dot com]

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.

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

[paolo.carlini at oracle dot com]

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.

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

[paolo.carlini at oracle dot com]

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...

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

[gdr at gcc dot gnu.org]

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.