[Bug c++/57743] New: Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[Bug c++/57743] New: Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[unmobile at gmail dot com]

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

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

            Bug ID: 57743
           Summary: Code accepted by other recent compilers, but not by
                    g++ - possibly failure to activate ADL
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unmobile at gmail dot com

Created attachment 30401
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30401&action=edit
Reduced test case

$ g++ --version
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3

$ g++ -c puptest0.C
puptest0.C: In member function ‘void SDAG::Closure::packClosure(PUP::er&)’:
puptest0.C:27: error: no match for ‘operator|’ in ‘p |
((SDAG::Closure*)this)->SDAG::Closure::continuations’

Tested with 4.8 and snapshots of 4.9, and all they add to that output (appears
in at least 4.3, 4.4, and 4.6) is column numbering and caret marking of that
exact spot.
(g++-mp-4.9 --version gives "g++-mp-4.9 (MacPorts gcc49 4.9-20130623_0) 4.9.0
20130623 (experimental)")

Reduced test case attached. Defining either of the tested macros lets the code
compile. Commenting either of the friend declarations also lets the code
compile. Moving the friend declarations out of the structure definition (and
making them non-friend) lets the code compile.

The code in question is accepted by clang of various versions including 3.3,
IBM XL C++ 12.01, Intel C++ versions 12.1.5.339 and 13.1 (but rejected by 11.1
with a similar error), and PGI C++ from 11.0 through 13.3.

MSVC++ v16 rejects it (not sure what year that's from). Cray's compiler v8 also
rejects it, again similarly.

The rejections from other compilers, and g++'s own when I vary conditions (cf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57739) might be enlightening. Intel
11.1 and Cray v8 provide no additional information, while MS VC++ is similar to
the related case output:

puptest0.C(27) : error C2679: binary '|' : no operator found which takes a
right-hand operand of type 'A' (or there is no acceptable conversion)
        puptest0.C(24): could be 'void SDAG::operator |(PUP::er &,SDAG::Closure
&)'
        puptest0.C(25): or       'void SDAG::operator |(PUP::er &,SDAG::Closure
*&)'
        while trying to match the argument list '(PUP::er, A)'

Going by the fact that where versions differ, the later version accepts, I
believe that there is a bug in g++ rejecting this code. It seems like any
little tweak lets the compiler apply argument dependent lookup and resolve the
operator successfully, but I don't know why it isn't already.
>From gcc-bugs-return-425347-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 27 22:55:55 2013
Return-Path: <gcc-bugs-return-425347-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2978 invoked by alias); 27 Jun 2013 22:55:55 -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 2935 invoked by uid 48); 27 Jun 2013 22:55:52 -0000
From: "pthaugen at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57741] ICE in tree.c:build_int_cst_wide starting in revision 200394
Date: Thu, 27 Jun 2013 22:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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: pthaugen at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57741-4-kyQIFJNeOG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57741-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57741-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-06/txt/msg01726.txt.bz2
Content-length: 1778

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

--- Comment #2 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Created attachment 30402
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0402&actioníit
full .i file

The proposed patch fixes the error for the reduced testcase and also fixes the
problem for the apsi benchmark, but mesa still hits the same error. Attatching
full .i file. Note that -ffast-math is also needed to reproduce this error.


[pthaugen@igoo 00000004]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O3
-mcpu=power7 -funroll-loops -ffast-math triangle.i
triangle.c: In function 'general_textured_triangle':
triangle.c:471:13: internal compiler error: in build_int_cst_wide, at
tree.c:1214
 static void general_textured_triangle( GLcontext *ctx, GLuint v0, GLuint v1,
             ^
0x1086156f build_int_cst_wide(tree_node*, unsigned long, long)
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1214
0x10861b07 double_int_to_tree(tree_node*, double_int)
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree.c:1068
0x1081405b get_initial_def_for_induction
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:3353
0x1081405b vectorizable_induction(gimple_statement_d*, gimple_stmt_iterator_d*,
gimple_statement_d**)
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5362
0x1080cd27 vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:5784
0x10811f1f vect_transform_loop(_loop_vec_info*)
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:5613
0x108349a7 vectorize_loops()
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:123
0x107475c3 tree_vectorize
    /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:222

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note int does not have an associated namespace which is the issue here.  There
is a defect report against the C++ standard about that.

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[unmobile at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743

--- Comment #2 from Phil Miller <unmobile at gmail dot com> ---
I just went to look at this in more detail, and I'm not sure how to interpret
what I've found. If the DR in question in 225
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#225), following
from 197, that seems to suggest that the other compilers *shouldn't* be be
treating int as if it were associated with the global namespace, since the
standards committee said the lack of associated namespace is Not A Defect. Does
the committee need another nudge on this point, as practice has shifted?

As a user, I'd much prefer if fundamental types were not special-cased in this
setting, with the standard blessing what Clang, IBM, Intel, and PGI have done,
and GCC, Microsoft, and Cray adopting that approach.

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[unmobile at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743

--- Comment #3 from Phil Miller <unmobile at gmail dot com> ---
The latest release of Microsoft Visual C++ (per the version available at
http://rise4fun.com/Vcpp) now accepts this code without complaint.

Cray compilers version 8.2 and onwards also accept this code.

As of my tests against the GCC 4.9.0 release, that seems to leave g++ all alone
(among the myriad compilers I have access to) in not accepting this code.

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Phil Miller from comment #2)
> Does the committee need another nudge on this point, as practice has shifted?

I don't believe practice has shifted. The difference in GCC's behaviour is
probably just a bug related to friend functions not a different interpretation
of ADL for fundamental types.

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-14
                 CC|                            |ville.voutilainen at gmail dot com
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2, 4.9.1, 5.0