[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #6 from Andrew Pinski  ---
Dup of bug 52099.

*** This bug has been marked as a duplicate of bug 52099 ***

[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
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().

[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
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?

[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|libstdc++   |c++

--- Comment #3 from Jonathan Wakely  ---
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 , thrown_type=0x401d10 ,
thr_obj=0x7fffd220, 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 ,
thr_type=0x401cf8 ) at
../../../../libstdc++-v3/libsupc++/tinfo.cc:71
(gdb) p *this
$3 = {_vptr.type_info = 0x6030b0 , __name = 0x401c89  "KFvvE"}
(gdb) p *thr_type
$4 = {_vptr.type_info = 0x6030b0 , __name = 0x401cf0  "FvvE"}
(gdb) 


But using GCC the two pointee types are the same:

(gdb) p *this
$1 = {_vptr.type_info = 0x6030e8 , __name = 0x401c50  "FvvE"}
(gdb) p *thr_type
$2 = {_vptr.type_info = 0x6030e8 , __name = 0x401c50  "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.

[Bug c++/69375] GCC allows PMF type "void (T::*)()" to be caught as "void (T::*)() const"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-13
 Ever confirmed|0   |1