[Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std

[Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std

[thakis at chromium dot org]

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

            Bug ID: 59165
           Summary: gcc looks up begin(), end() for for-range loops for
                    ints in namespace std
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thakis at chromium dot org

This compiles, but shouldn't:

$ cat gcc4.8bug.cc 
// builds with gcc4.8, but shouldn't
namespace std {
int* begin(int i) { return (int*)0; }
int* end(int i) { return (int*)0; }
}

int main() {
  for (int a : 10) { }
}
$ gcc-4.8.1 -c gcc4.8bug.cc  -std=c++11
# works


The standard says that begin() and end() for foreach loops should be looked up
in the associated namespace of the type of the expression (6.5.4p1)

"""otherwise, begin-expr and end-expr are begin(__range) and end(__range),
respectively, where begin and end are looked up in the associated namespaces
(3.4.2). [ Note: Ordinary unqualified lookup (3.4.1) is not performed. — end
note ]"""

10 has type int, which is a fundamental type, and hence doesn't have an
associated namespace. So this shouldn't compile. (It doesn't compile in clang.)



$ gcc-4.8.1 --version
gcc-4.8.1 (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>From gcc-bugs-return-434828-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 18 04:46:31 2013
Return-Path: <gcc-bugs-return-434828-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 310 invoked by alias); 18 Nov 2013 04:46:30 -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 32732 invoked by uid 48); 18 Nov 2013 04:46:25 -0000
From: "dongsheng.song at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
Date: Mon, 18 Nov 2013 04:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dongsheng.song at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-57897-4-nlG0qh4GK7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57897-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57897-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-11/txt/msg01605.txt.bz2
Content-length: 682

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW897

--- Comment #6 from Dongsheng Song <dongsheng.song at gmail dot com> ---
After revert r192062, I can build gcc smoothly.

$ svn log -r 192062
------------------------------------------------------------------------
r192062 | uros | 2012-10-04 13:53:22 +0800 (Thu, 04 Oct 2012) | 4 lines

        * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables.
        * configure: Regenerate.
------------------------------------------------------------------------

2012-10-04  Uros Bizjak  <ubizjak@gmail.com>

        * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables.
        * configure: Regenerate.

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Well, this changed only post-C++11 in
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1442 which is
simply unimplemented. Frankly, I'm not even sure we want to implement the
proposed resolution right now (for comparison, ICC doesn't). In case, changing
things like (in cp_parser_perform_range_for_lookup):

      member_begin = perform_koenig_lookup (id_begin, vec,
                        /*include_std=*/true,
                        tf_warning_or_error);

would be easy, I guess.

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to thakis from comment #0)
> This compiles, but shouldn't:

You add declarations to namespace std which is undefined behaviour, so any
result is valid.

The DR looks wrong to me, the point of treating std as an associated namespace
is that std::begin and std::end will be found for user-defined containers, not
just the standard containers.  I don't know why core decided to change that.

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think I remember the rationale now: std::begin and std::end only work if
c.begin() and c.end() xist, in which case range-based for will use those
members directly anyway.

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> I think I remember the rationale now: std::begin and std::end only work if
> c.begin() and c.end() xist, in which case range-based for will use those
> members directly anyway.

This is not really the *reason* for the language change. The actual reason
becomes a bit clearer when looking at the dup of CWG 1442:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1445

I remember that this dup was actually inspired by the observation that
BOOST_FOR_EACH behaved subtly different to the language for-each lookup rules,
albeit both constructs are intended to perform the same thing. CWG 1442 just
ensured that the lookup rule in for each corresponds to existing lookup rules
in other places and is thus easier to understand.
>From gcc-bugs-return-435198-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 20 09:52:34 2013
Return-Path: <gcc-bugs-return-435198-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8290 invoked by alias); 20 Nov 2013 09:52:34 -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 8261 invoked by uid 48); 20 Nov 2013 09:52:31 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
Date: Wed, 20 Nov 2013 09:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
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: cc
Message-ID: <bug-59204-4-ZZJM4aI6GX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59204-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59204-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01975.txt.bz2
Content-length: 605

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
This looks like a manifestation of the core language issue

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1558

to me.
>From gcc-bugs-return-435199-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 20 10:15:29 2013
Return-Path: <gcc-bugs-return-435199-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 519 invoked by alias); 20 Nov 2013 10:15:28 -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 442 invoked by uid 48); 20 Nov 2013 10:15:21 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59209] New: builtin memcpy in inlined function is not optimized away if count is derived from src pointer difference
Date: Wed, 20 Nov 2013 10:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59209-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-11/txt/msg01976.txt.bz2
Content-length: 2809

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY209

            Bug ID: 59209
           Summary: builtin memcpy in inlined function is not optimized
                    away if count is derived from src pointer difference
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: olegendo at gcc dot gnu.org

This was originally reported here:
http://gcc.gnu.org/ml/gcc-help/2013-11/msg00137.html

I've reduced the case to the following.

This one works OK, because the 'count' constant seems to be propagated.

static void copy_func (const char* src, char* dst, int count)
{
  __builtin_memmove (dst, src, count);
}

int test_copy (const char* x)
{
  char r;
  copy_func (x, &r, 1);
  return r;
}

SH output (single byte read and return, as expected):
__Z9test_copyPKc:
.LFB2244:
        rts
        mov.b    @r4,r0


However, if 'count' is derived from the src pointer difference (as it's done by
std::copy), the builtin memmove/memcpy is not optimized away and a call to
_memcpy remains:

static void copy_func2 (const char* src_start, const char* src_end, char* dst)
{
  __builtin_memmove (dst, src_start, src_end - src_start);
}

int test_copy2 (const char* x)
{
  char r;
  copy_func2 (x, x + 1, &r);
  return r;
}

It seems it's not really related to the memcpy built-in stuff itself.  For
example this one has the same problem, where the count is actually known to be
constant '1' after inlining, but the loop is not eliminated:

static void copy_func3 (const char* src_start, const char* src_end, char* dst)
{
  auto count = src_end - src_start;
  while (count-- > 0)
    *dst++ = *src_start++;
}

int test_copy3 (const char* x)
{
  char r;
  copy_func3 (x, x + 1, &r);
  return r;
}

        add     #-4,r15
        mov     r15,r1      // r1 = &r
        mov     r4,r3       // r3 = r4 = x
        add     #3,r1       // r1 = &r + 3
        add     #1,r3       // r3 = x + 1
.L3:
        mov.b   @r4+,r2     // r2 = *src_start++
        mov.b   r2,@r1      // *dst = r2
        cmp/eq  r3,r4       // T = r3 == r4
        add     #1,r1       // dst += 1
        bf      .L3         // if (T == 0) goto L3

        mov     r15,r0
        add     #-12,r0
        mov.b   @(15,r0),r0
        rts
        add     #4,r15


On the other hand, the following:

static void copy_func4 (const char* src_start, const char* src_end,
                        unsigned int* dst)
{
  unsigned int count = src_end - src_start;
  *dst = count;
}

unsigned int test_copy4 (const char* x)
{
  unsigned int r;
  copy_func3 (x, x + 1, &r);
  return r;
}

results in the expected return of a constant '1':
        rts
        mov    #1,r0

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-12-10
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com
   Target Milestone|---                         |4.9.0
     Ever confirmed|0                           |1

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Mine.

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> ---
Author: paolo
Date: Fri Jan  3 11:11:31 2014
New Revision: 206313

URL: http://gcc.gnu.org/viewcvs?rev=206313&root=gcc&view=rev
Log:
/cp
2014-01-03  Paolo Carlini  <paolo.carlini@oracle.com>

    Core DR 1442
    PR c++/59165
    * parser.c (cp_parser_perform_range_for_lookup): Don't pass true
    as include_std to perform_koenig_lookup.
    (cp_parser_postfix_expression): Adjust.
    * pt.c (tsubst_copy_and_build): Likewise.
    * semantics.c (perform_koenig_lookup): Remove bool parameter.
    (omp_reduction_lookup): Adjust.
    * name-lookup.c (lookup_arg_dependent_1): Remove bool parameter.
    (lookup_arg_dependent): Likewise.
    (lookup_function_nonclass): Adjust.
    * name-lookup.h: Adjust declaration.
    * cp-tree.h: Likewise.

/testsuite
2014-01-03  Paolo Carlini  <paolo.carlini@oracle.com>

    Core DR 1442
    PR c++/59165
    * g++.dg/cpp0x/range-for28.C: New.
    * g++.dg/cpp0x/range-for3.C: Update.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/range-for28.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/cp/name-lookup.h
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/cpp0x/range-for3.C

[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Done.