public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std
@ 2013-11-18 4:13 thakis at chromium dot org
2013-11-18 10:28 ` [Bug c++/59165] " paolo.carlini at oracle dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: thakis at chromium dot org @ 2013-11-18 4:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org @ 2013-11-18 10:28 ` paolo.carlini at oracle dot com 2013-11-18 10:46 ` redi at gcc dot gnu.org ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: paolo.carlini at oracle dot com @ 2013-11-18 10:28 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org 2013-11-18 10:28 ` [Bug c++/59165] " paolo.carlini at oracle dot com @ 2013-11-18 10:46 ` redi at gcc dot gnu.org 2013-11-18 10:56 ` redi at gcc dot gnu.org ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: redi at gcc dot gnu.org @ 2013-11-18 10:46 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org 2013-11-18 10:28 ` [Bug c++/59165] " paolo.carlini at oracle dot com 2013-11-18 10:46 ` redi at gcc dot gnu.org @ 2013-11-18 10:56 ` redi at gcc dot gnu.org 2013-11-20 9:48 ` daniel.kruegler at googlemail dot com ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: redi at gcc dot gnu.org @ 2013-11-18 10:56 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org ` (2 preceding siblings ...) 2013-11-18 10:56 ` redi at gcc dot gnu.org @ 2013-11-20 9:48 ` daniel.kruegler at googlemail dot com 2013-12-10 10:36 ` paolo.carlini at oracle dot com ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: daniel.kruegler at googlemail dot com @ 2013-11-20 9:48 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org ` (3 preceding siblings ...) 2013-11-20 9:48 ` daniel.kruegler at googlemail dot com @ 2013-12-10 10:36 ` paolo.carlini at oracle dot com 2014-01-03 11:11 ` paolo at gcc dot gnu.org 2014-01-03 11:13 ` paolo.carlini at oracle dot com 6 siblings, 0 replies; 8+ messages in thread From: paolo.carlini at oracle dot com @ 2013-12-10 10:36 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org ` (4 preceding siblings ...) 2013-12-10 10:36 ` paolo.carlini at oracle dot com @ 2014-01-03 11:11 ` paolo at gcc dot gnu.org 2014-01-03 11:13 ` paolo.carlini at oracle dot com 6 siblings, 0 replies; 8+ messages in thread From: paolo at gcc dot gnu.org @ 2014-01-03 11:11 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org ` (5 preceding siblings ...) 2014-01-03 11:11 ` paolo at gcc dot gnu.org @ 2014-01-03 11:13 ` paolo.carlini at oracle dot com 6 siblings, 0 replies; 8+ messages in thread From: paolo.carlini at oracle dot com @ 2014-01-03 11:13 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-01-03 11:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-18 4:13 [Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std thakis at chromium dot org 2013-11-18 10:28 ` [Bug c++/59165] " paolo.carlini at oracle dot com 2013-11-18 10:46 ` redi at gcc dot gnu.org 2013-11-18 10:56 ` redi at gcc dot gnu.org 2013-11-20 9:48 ` daniel.kruegler at googlemail dot com 2013-12-10 10:36 ` paolo.carlini at oracle dot com 2014-01-03 11:11 ` paolo at gcc dot gnu.org 2014-01-03 11:13 ` paolo.carlini at oracle dot com
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).