public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/58184] New: Pointer to overloaded function is non-deduced context
@ 2013-08-17 18:51 aschepler at gmail dot com
  2013-08-18 14:26 ` [Bug c++/58184] " daniel.kruegler at googlemail dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: aschepler at gmail dot com @ 2013-08-17 18:51 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 58184
           Summary: Pointer to overloaded function is non-deduced context
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aschepler at gmail dot com

Created attachment 30669
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30669&action=edit
Sample c++ code

The attached program is ill-formed, but g++ 4.8.1 compiles it with no warnings.

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) 

No output from either command:
g++ -std=c++03 -pedantic -Wall -Wextra main.cpp
g++ -std=c++11 -pedantic -Wall -Wextra main.cpp

Template parameter U cannot be deduced in the expression using f.  I believe
this is true in both C++03 and C++11, although C++11 states it more clearly.

[C++03 14.8.3/2 ; C++11 14.8.2.5/2]
Type deduction is done independently for each P/A pair, and the deduced
template argument values are then combined.

[C++03 14.8.2.4/16]
A template-argument can be deduced from a pointer to function or pointer to
member function argument if the set of overloaded functions does not contain
function templates and at most one of a set of overloaded functions provides a
unique match.

[C++11 14.8.2.1/6]
When P is a function type, pointer to function type, or pointer to member
function type:
 - If the argument is an overload set containing one or more function
templates, the parameter is treated as a non-deduced context.
 - If the argument is an overload set (not containing function templates),
trial argument deduction is attempted using each of the members of the set.  If
deduction succeeds for only one of the overload set members, that member is
used as the argument value for the deduction.  If deduction succeeds for more
than one member of the overload set the parameter is treated as a non-deduced
context.

[C++11 14.8.2.1/8]
Example:
// Ambiguous deduction causes the second function parameter to be a
// non-deduced context.
template <class T> int f(T, T (*p)(T));
int g(int);
char g(char);
int i = f(1, g);  // calls f(int, int (*)(int))

[End Standard quotes.]

Note the final example from C++11 is essentially the same as my example, except
that there is no other template parameter to be deduced, so type deduction
still succeeds.

Also, the current behavior leads to some strange inconsistencies.  The order of
function parameters generally plays no role in type deduction, but if you
reverse the order of f's parameters and arguments in my example, g++ will
reject it.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/58184] Pointer to overloaded function is non-deduced context
  2013-08-17 18:51 [Bug c++/58184] New: Pointer to overloaded function is non-deduced context aschepler at gmail dot com
@ 2013-08-18 14:26 ` daniel.kruegler at googlemail dot com
  2021-07-23  1:07 ` pinskia at gcc dot gnu.org
  2021-12-04 12:15 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2013-08-18 14:26 UTC (permalink / raw)
  To: gcc-bugs

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

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> ---
The same problem exists for gcc 4.9.0 HEAD
>From gcc-bugs-return-427997-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 18 14:29:35 2013
Return-Path: <gcc-bugs-return-427997-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15396 invoked by alias); 18 Aug 2013 14:29:35 -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 15373 invoked by uid 48); 18 Aug 2013 14:29:33 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53976] [SH] Unnecessary clrt after bt
Date: Sun, 18 Aug 2013 14:29: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.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
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:
Message-ID: <bug-53976-4-VaDx4M44pr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53976-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53976-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-08/txt/msg00921.txt.bz2
Content-length: 1003

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

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
One option to get rid of the redundant clrt and sett in BBs that are reached
with a conditional branch would be to add an SH specific RTL pass that analyses
the BBs and eliminates the insns in question.

Another option could be to try and inject artificial sett / clrt insns at the
start of BBs that are reached by conditional branches, and then split them away
to nops or output empty asm with insn length 0.  The idea would be to let other
already existing RTL passes figure out the redundant T bit sets.

There is already a similar functionality in cse.c (cse_condition_code_reg), but
it probably wouldn't kick in, since clrt / sett insns are emitted until the
split1 pass before register allocation and cse2 runs before that.  But still,
maybe another RTL pass would figure it out.  It doesn't necessarily need to be
before register allocation, since the T bit is a hard-reg anyway.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/58184] Pointer to overloaded function is non-deduced context
  2013-08-17 18:51 [Bug c++/58184] New: Pointer to overloaded function is non-deduced context aschepler at gmail dot com
  2013-08-18 14:26 ` [Bug c++/58184] " daniel.kruegler at googlemail dot com
@ 2021-07-23  1:07 ` pinskia at gcc dot gnu.org
  2021-12-04 12:15 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-07-23  1:07 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Still accepted on the trunk.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/58184] Pointer to overloaded function is non-deduced context
  2013-08-17 18:51 [Bug c++/58184] New: Pointer to overloaded function is non-deduced context aschepler at gmail dot com
  2013-08-18 14:26 ` [Bug c++/58184] " daniel.kruegler at googlemail dot com
  2021-07-23  1:07 ` pinskia at gcc dot gnu.org
@ 2021-12-04 12:15 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-04 12:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note both ICC and MSVC accept the attached example.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-12-04 12:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-17 18:51 [Bug c++/58184] New: Pointer to overloaded function is non-deduced context aschepler at gmail dot com
2013-08-18 14:26 ` [Bug c++/58184] " daniel.kruegler at googlemail dot com
2021-07-23  1:07 ` pinskia at gcc dot gnu.org
2021-12-04 12:15 ` pinskia at gcc dot gnu.org

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).