public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "gdr at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/48365] Non-constant references in std::valarray::operator
Date: Tue, 14 Jun 2011 14:18:00 -0000	[thread overview]
Message-ID: <bug-48365-4-txOihj2LnJ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <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.


      parent reply	other threads:[~2011-06-14 14:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 14:11 [Bug libstdc++/48365] New: " 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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-48365-4-txOihj2LnJ@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).