[Bug libstdc++/49022] New: [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[Bug libstdc++/49022] New: [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[flast at flast dot jp]

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

           Summary: [C++0x] std::begin and std::end specialized for
                    std::valarray with some operators are missing.
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: flast@flast.jp


Currently, std::begin and std::end specialized for std::valarray are exist.
However operators for std::valarray are using Expression Template technique.
And std::begin and std::end specialized for those are not exist.

For example, GCC rejects following code.
==== testcase.cc ====
#include <valarray>

void f()
{
    std::valarray<int> x,y;
    std::begin(x + y);
}
====

output:
$ g++-4.6 -std=c++0x testcase.cc
testcase.cc: In function 'void f()':
testcase.cc:6:23: error: no matching function for call to
'begin(std::_Expr<std::_BinClos<std::__plus, std::_ValArray, std::_ValArray,
int, int>, int>)'
testcase.cc:6:23: note: candidates are:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/initializer_list:86:38:
note: template<class _Tp> constexpr const _Tp*
std::begin(std::initializer_list<_Tp>)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:48:57:
note: template<class _Container> decltype (__cont->begin())
std::begin(_Container&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:58:63:
note: template<class _Container> decltype (__cont->begin()) std::begin(const
_Container&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/range_access.h:87:28:
note: template<class _Tp, unsigned int _Nm> _Tp* std::begin(_Tp (&)[_Nm])
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/valarray:1126:30:
note: template<class _Tp> _Tp* std::begin(std::valarray<_Tp>&)
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/valarray:1136:36:
note: template<class _Tp> const _Tp* std::begin(const std::valarray<_Tp>&)

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.05.17 13:54:13
     Ever Confirmed|0                           |1

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr@integrable-solutions.ne
                   |                            |t

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 14:41:25 UTC ---
Frankly, I have no idea what is missing vs the letter of the FDIS. Tips?

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot
                   |                            |com

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 14:48:35 UTC ---
To expand: *if* the '+' itself is allowed per the specs to return something !=
std::valarray, and the specs only mandate std::begin and std::end overloads
taking std::valarray& and const std::valarray& I don't see where is the bug in
our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't
followed the recent discussion about ranges in any detail, I may be missing
something.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-17 14:52:41 UTC ---
[valarray.syn] paragraph 4 

   for every function taking a const valarray<T>&, identical functions
   taking the replacement types shall be added;

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 15:03:37 UTC ---
Ah, ok, now I see, it's just that std::begin and std::end fall under 26.6.1/4.
Only the const std::valarray& version, if I understand correctly. I can look
into it reasonably soon, seems easy.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 15:09:44 UTC ---
Double Sigh! I was hoping very few overloads would be enough... If we are
really talking about many I would be in favor of raising the issue, indeed.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu.org
         AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
                   |com                         |gnu.org

--- Comment #5 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-05-17 15:04:48 UTC ---
(In reply to comment #2)
> To expand: *if* the '+' itself is allowed per the specs to return something !=
> std::valarray, and the specs only mandate std::begin and std::end overloads
> taking std::valarray& and const std::valarray& I don't see where is the bug in
> our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't
> followed the recent discussion about ranges in any detail, I may be missing
> something.


LWG failed to resist the longstanding temptation to turn valarray into
yet another container.  You can't turn it into an container and yet
make is possible for implementations to EFFECTIVELY exploit the lack
of aliasing guarantees.  If looks like everytime I turn my back LWG
jumps tto do something to valarray.
Either we have a flood of begin/end functions decorated with __enable_if
stuff or we make it a defect in LWG.

Sigh.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #7 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-05-17 15:14:04 UTC ---
(In reply to comment #6)
> Double Sigh! I was hoping very few overloads would be enough... If we are
> really talking about many I would be in favor of raising the issue, indeed.

The issue is even trickier than that:  If you were allowed to write those
functions, what would begin() and end() return?  a pointer into a 
soon-to-be-destroyed valarray? 

I think this is a defect in the standard.  I just sent an email.

-- Gaby

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 15:17:01 UTC ---
Ok, I'll follow the discussion...

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-17 15:27:01 UTC ---
The workaround for users is to construct a valarray from the expr:

    std::valarray<int> result(x + y);
    std::begin( result );

That avoids the problem of returning an iterator into a temporary which no
longer exists.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 15:49:25 UTC ---
For sure that works.

Gaby, just to make sure we are on the same page: did you send a message to the
reflector about this issue already? Or do you want me (us) to do that? Shall we
suspend this PR in the meanwhile?

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 15:54:19 UTC ---
All in all, now that I understand the issue with the temporary, this seems
really sort of a NAD, maybe the wording needs only clarifying that you don't
want to add std::begin and std::end overloads, no?

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #13 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-05-17 16:24:57 UTC ---
(In reply to comment #11)
> All in all, now that I understand the issue with the temporary, this seems
> really sort of a NAD, maybe the wording needs only clarifying that you don't
> want to add std::begin and std::end overloads, no?

yes, my recommendation (in the email I sent LWG reflector) was to remove
the begin/end pairs -- at least for the version that takes a const valarray&.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #12 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-05-17 16:23:37 UTC ---
(In reply to comment #10)
> For sure that works.
> 
> Gaby, just to make sure we are on the same page: did you send a message to the
> reflector about this issue already? Or do you want me (us) to do that? Shall we
> suspend this PR in the meanwhile?

Yes, I did send an email to c++std-lib.  Apparently, there is some kind
of partial network outage at the TAMU CSE so there might be a delay.
Yes, it makes sense to suspend this PR in the meantime.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-17 16:43:01 UTC ---
Let's suspend this, for now. Thanks Gaby.

[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-18 08:59:26 UTC ---
Discussion on the LWG reflector started at c++std-lib-30761

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 12:04:56 UTC ---
I had another look at this issue. Something I didn't realize at the time is
that simply adding begin() and end() overloads taking a const _Expr& is not
going to work in practice for the usages we care about, like the range-based
for-loop, unless one manages somehow to pass the *same* temporary _Expr to
both. I think we have an issue with that, I don't know if it's in the specs of
the range-based for-loop vs the valarray case at issue, or just in the GCC
implementation of the latter. Anyway, if I add the overloads:

  template<class _Clos, typename _Tp>
    inline const _Tp*
    begin(const _Expr<_Clos, _Tp>& __ex)
    { return std::__addressof<const _Tp>(__ex()[0]); }

  template<class _Clos, typename _Tp>
    inline const _Tp*
    end(const _Expr<_Clos, _Tp>& __ex)
    { return std::__addressof<const _Tp>(__ex()[0]) + __ex.size(); }

Then, the snippet:

  std::valarray<int> v1{ 0, 1, 2, 3, 4 }, v2{ 5, 6, 7, 8, 9};

  for (int i : v1 + v2)
    { std::cout << i << std::endl; } 

compiles but then misbehaves at compile-time, per valgrind too: apparently we
don't have a proper range. Note that the following misbehaves exactly in the
*same way*, and this appears to support my conjecture that we have a problem
somewhere with two different temporary _Expr passed to the begin and end
overloads:

  for (auto b = std::begin(v1 + v2), e = std::end(v1 + v2); b < e; ++b)
    { std::cout << *b << std::endl; }

Maybe we should somehow point out this specific point in LWG 2058?

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[daniel.kruegler at googlemail dot com]

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

--- Comment #17 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-06-14 12:20:21 UTC ---
(In reply to comment #16)
> I had another look at this issue. Something I didn't realize at the time is
> that simply adding begin() and end() overloads taking a const _Expr& is not
> going to work in practice for the usages we care about, like the range-based
> for-loop, unless one manages somehow to pass the *same* temporary _Expr to
> both. 

[..] 

> Maybe we should somehow point out this specific point in LWG 2058?

I think that Gaby has expressed exactly this problem in the discussion around
LWG 2058, therefore I would suggest to add an exclusion sentence to
[valarray.syn] p4 in regard to the begin/end overloads. I don't think that the
library should support more than the most simple use-case in regard to valarray
range support.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 12:51:45 UTC ---
(In reply to comment #16)
> Then, the snippet:
> 
>   std::valarray<int> v1{ 0, 1, 2, 3, 4 }, v2{ 5, 6, 7, 8, 9};
> 
>   for (int i : v1 + v2)
>     { std::cout << i << std::endl; } 
> 
> compiles but then misbehaves at compile-time, per valgrind too: apparently we
> don't have a proper range. Note that the following misbehaves exactly in the
> *same way*, and this appears to support my conjecture that we have a problem
> somewhere with two different temporary _Expr passed to the begin and end
> overloads:
> 
>   for (auto b = std::begin(v1 + v2), e = std::end(v1 + v2); b < e; ++b)
>     { std::cout << *b << std::endl; }

Hmm, then range-based for is implemented incorrectly, I'll take a look.
It should be identical to

auto&& range = v1 + v2;
for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
  { ... }
(see 6.5.4 [stmt.ranged])

of course the same problem is present for any temporary expression:
std::string s = "hello"
  for (auto b = std::begin(s+"!"), e = std::end(s+"!"); b != e; ++b)
but it should work correctly as:
  for (auto c : s+"!")

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 13:01:24 UTC ---
Ah, no the problem is std::__addressof<const _Tp>(__ex()[0]) which takes the
address of a temporary returned by operator[]

The range-based for seems to do the right thing

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 13:23:29 UTC ---
Created attachment 24519
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24519
patch

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 13:22:13 UTC ---
I'm not sure, really. I'm going to attach a variant which more explicitly only
uses return by const ref and shows the same fundamental problem for me.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 13:27:03 UTC ---
To be clear: I fully agree with the exclusion sentence. But I had to play a bit
with this stuff to realize that really adding overloads to begin() and end()
cannot work.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 13:50:56 UTC ---
Ok, now I see, it's the operator[] of _BinBase which returns by value, I
overlooked that. Thus, fine it seems confirmed that range-based for-loop itself
is Ok, but making sure we have return by const ref everywhere for _Expr seems
unmanageable.

Thus, again, confirmed that I agree with removing the overloads.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #24 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-06-14 13:54:13 UTC ---
(In reply to comment #18)

> It should be identical to
> 
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
>   { ... }
> (see 6.5.4 [stmt.ranged])

This will not work with expression template-based implementation
of valarray.  The reason is that `range' may be a surrogate, and
you are likely to get rubbish addresses.

I urge people to drop range-based iteration on valarrays.
It wasn't something we were dieing for.  It grew out of
someone's idea of "uniformity" that failed to appreciate
that a valarray is not your usual container.

- Gaby

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #25 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-06-14 14:01:30 UTC ---
(In reply to comment #23)
> Ok, now I see, it's the operator[] of _BinBase which returns by value, I
> overlooked that. 

Yes, "val" in "valarray" stands for "value", e.g. a valarray
is a fundamentally a value, from a conceptual point of view; not an object.

Range-based "for" is fundamentally container-oriented in the
sense that it assumes that the container is an *object* that
resides in memory, and the iteration really visits each cell in
that object.  A valarray is a *value*, and each individual
value in that array may be produced by any mean, e.g. surrogates.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #26 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-14 14:02:15 UTC ---
... among other things, std::valarray, at variance with the containers, does
*not* have member begin and end, thus I don't even think novice programmers may
have expectations about that.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW

--- Comment #27 from Paolo Carlini <paolo.carlini at oracle dot com> ---
DR2058 is now WP, thus we are supposed to reassess this. Now, according to the
resolution, additional 'begin' and 'end' overloads shall *not* be added, thus I
understand that we are already fine, right?

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[daniel.kruegler at googlemail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2612 bytes --]

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

--- Comment #28 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Paolo Carlini from comment #27)
Yes.
>From gcc-bugs-return-425743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 04 11:50:50 2013
Return-Path: <gcc-bugs-return-425743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31488 invoked by alias); 4 Jul 2013 11:50:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31427 invoked by uid 48); 4 Jul 2013 11:50:47 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
Date: Thu, 04 Jul 2013 11:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-29776-4-Di2EHpnQki@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-29776-4@http.gcc.gnu.org/bugzilla/>
References: <bug-29776-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00250.txt.bz2
Content-length: 581

http://gcc.gnu.org/bugzilla/show_bug.cgi?id)776

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30453|0                           |1
        is obsolete|                            |

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 30454
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0454&actioníit
gcc49-pr29776.patch

It wasn't actually that hard to improve the VRs in some cases.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #29 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Great.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #30 from Gabriel Dos Reis <gdr at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #27)
> DR2058 is now WP, thus we are supposed to reassess this. Now, according to
> the resolution, additional 'begin' and 'end' overloads shall *not* be added,
> thus I understand that we are already fine, right?

Indeed.