public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members
@ 2012-02-02 22:23 jens.maurer at gmx dot net
2015-03-25 16:55 ` [Bug c++/52099] " paolo.carlini at oracle dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: jens.maurer at gmx dot net @ 2012-02-02 22:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Bug #: 52099
Summary: Incorrectly applying conversion when catching
pointer-to-members
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: jens.maurer@gmx.net
The follwing program shows that gcc erroneously matches an exception object of
a pointer-to-member type to a handler of (slightly) different type. There is
no allowance in 15.3 [except handle] to do that. In particular, adding a
cv-qualifier on top of the pointer-to-member type (which would be allowed)
cannot morph a pointer-to-nonconst-member function into a
pointer-to-const-member function.
#include <cassert>
struct A
{
void foo() {}
};
int main()
{
try
{
throw &A::foo;
}
catch (void (A::*)() const)
{
assert(false); // g++ currently takes this route
}
catch (...)
{
}
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
@ 2015-03-25 16:55 ` paolo.carlini at oracle dot com
2021-07-23 20:38 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: paolo.carlini at oracle dot com @ 2015-03-25 16:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-03-25
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
2015-03-25 16:55 ` [Bug c++/52099] " paolo.carlini at oracle dot com
@ 2021-07-23 20:38 ` pinskia at gcc dot gnu.org
2021-07-25 20:17 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-07-23 20:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eric at efcs dot ca
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 69375 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
2015-03-25 16:55 ` [Bug c++/52099] " paolo.carlini at oracle dot com
2021-07-23 20:38 ` pinskia at gcc dot gnu.org
@ 2021-07-25 20:17 ` redi at gcc dot gnu.org
2021-08-09 21:02 ` pinskia at gcc dot gnu.org
2021-08-09 23:20 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2021-07-25 20:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
>From the dup:
Eric Fiselier 2016-01-20 03:50:56 UTC
Created attachment 37399 [details]
reproducer
I don't see where [except.handle] allows such a conversion.
Comment 1 Jonathan Wakely 2017-01-13 20:36:35 UTC
We're missing a check for cv-qualifiers in
__pointer_to_member_type_info::__pointer_catch that needs to be done before we
compare the pointees. Both pointees have type void() so we need to compare the
cv-quals before that info is lost.
Comment 2 Jonathan Wakely 2017-01-13 20:49:13 UTC
Hmm, we don't seem to have the cv-quals in __flags. That's a problem.
Comment 3 Jonathan Wakely 2017-01-13 21:08:10 UTC
When compiled with clang the pointees are different, so the match fails when
comparing them.
Using Clang:
(gdb) step
__cxxabiv1::__pbase_type_info::__pointer_catch (this=0x401cc0 <typeinfo for
void (A::*)() const>, thrown_type=0x401d10 <typeinfo for void (A::*)()>,
thr_obj=0x7fffffffd220, outer=0)
at
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/cxxabi.h:309
(gdb) step
std::type_info::__do_catch (this=0x401c90 <typeinfo for void () const>,
thr_type=0x401cf8 <typeinfo for void ()>) at
../../../../libstdc++-v3/libsupc++/tinfo.cc:71
(gdb) p *this
$3 = {_vptr.type_info = 0x6030b0 <vtable for
__cxxabiv1::__function_type_info@@CXXABI_1.3+16>, __name = 0x401c89 <typeinfo
name for void () const> "KFvvE"}
(gdb) p *thr_type
$4 = {_vptr.type_info = 0x6030b0 <vtable for
__cxxabiv1::__function_type_info@@CXXABI_1.3+16>, __name = 0x401cf0 <typeinfo
name for void ()> "FvvE"}
(gdb)
But using GCC the two pointee types are the same:
(gdb) p *this
$1 = {_vptr.type_info = 0x6030e8 <vtable for
__cxxabiv1::__function_type_info@@CXXABI_1.3+16>, __name = 0x401c50 <typeinfo
name for void ()> "FvvE"}
(gdb) p *thr_type
$2 = {_vptr.type_info = 0x6030e8 <vtable for
__cxxabiv1::__function_type_info@@CXXABI_1.3+16>, __name = 0x401c50 <typeinfo
name for void ()> "FvvE"}
So it looks like the problem is in the front-end where the typeinfo object for
a pointer to cv-qualified member function has the wrong pointee type.
Comment 4 Jonathan Wakely 2017-01-13 23:05:34 UTC
My front-end debugging skills are pitiful, but I've found something suspicious.
ptm_initializer uses TYPE_PTRMEM_POINTED_TO_TYPE to get that pointee type. For
this case that expands to TYPE_PTRMEMFUNC_FN_TYPE which is a call to
cp_build_qualified_type with the qualifiers from cp_type_quals.
But cp_type_quals tries pretty hard to ensure we never get cv-quals for a
function type. For the purposes of RTTI, where we really do care about the
difference between void() and void()const, do we want the memfn quals instead?
Comment 5 Jonathan Wakely 2017-01-13 23:20:33 UTC
For the attached reproducer this condition is never true in
cp_build_qualified_type_real
/* But preserve any function-cv-quals on a FUNCTION_TYPE. */
if (TREE_CODE (type) == FUNCTION_TYPE)
type_quals |= type_memfn_quals (type);
As far as I can tell this is what's supposed to put the cv-quals back onto the
function type, so we'd have a pointee of type void() const not void().
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
` (2 preceding siblings ...)
2021-07-25 20:17 ` redi at gcc dot gnu.org
@ 2021-08-09 21:02 ` pinskia at gcc dot gnu.org
2021-08-09 23:20 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-09 21:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |richard-gccbugzilla@metafoo
| |.co.uk
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 67772 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
` (3 preceding siblings ...)
2021-08-09 21:02 ` pinskia at gcc dot gnu.org
@ 2021-08-09 23:20 ` redi at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-09 23:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Further discussion from PR 67772:
Consider:
namespace std { struct type_info {}; }
struct A {};
auto x = typeid(void(A::*)() const);
Clang emits the type info as:
_ZTIM1AKFvvE:
.quad _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad _ZTSM1AKFvvE
.long 0 # 0x0
.zero 4
.quad _ZTIKFvvE
.quad _ZTI1A
GCC emits it as:
_ZTIM1AKFvvE:
.quad _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad _ZTSM1AKFvvE
.long 0
.zero 4
.quad _ZTIFvvE
.quad _ZTI1A
It appears that Clang is correct here; the 'const' in this case is not a
qualifier, so should not be removed when forming the pointee type_info. If GCC
really did think this was a const qualifier applied to a function type, it
would be emitting the wrong flags (should be .long 1, not .long 0 in that
case).
This translates into a wrong-code bug in a case like this:
struct A;
extern "C" void puts(const char*);
int main() {
try {
throw (void(A::*)())0;
} catch (void (A::*)() const) {
puts("bad catch");
}
}
... where GCC erroneously catches a pointer to non-const member function as a
pointer to const member function.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-09 23:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-02 22:23 [Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members jens.maurer at gmx dot net
2015-03-25 16:55 ` [Bug c++/52099] " paolo.carlini at oracle dot com
2021-07-23 20:38 ` pinskia at gcc dot gnu.org
2021-07-25 20:17 ` redi at gcc dot gnu.org
2021-08-09 21:02 ` pinskia at gcc dot gnu.org
2021-08-09 23:20 ` redi 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).