[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #23 from Jonathan Wakely --- This was fixed for GCC 7 so I'm closing it. If you need it backported to GCC 6 please say so, as I won't bother otherwise.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #22 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #17) > Not all cases work though, nullptr cannot be caught as a pointer to member > function, and fixing that is difficult, so I'm keeping this open. That was fixed in r238532
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #21 from Jonathan Wakely --- I think this can be backported safely, maybe to gcc-5-branch too.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Andrew Pinski changed: What|Removed |Added Target Milestone|6.5 |---
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Richard Biener changed: What|Removed |Added Target Milestone|6.4 |6.5 --- Comment #20 from Richard Biener --- GCC 6.4 is being released, adjusting target milestone.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.3 |6.4 --- Comment #19 from Jakub Jelinek --- GCC 6.3 is being released, adjusting target milestone.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Richard Biener changed: What|Removed |Added Target Milestone|6.2 |6.3 Known to fail||6.2.0 --- Comment #18 from Richard Biener --- GCC 6.2 is being released, adjusting target milestone
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #17 from Jonathan Wakely --- With GCC 7 from svn trunk the original test case now prints: About to 'throw nullptr' (first case) Caught 'throw nullptr' as type 'int A::*PointerToMember' About to 'throw nullptr' (second case) Caught 'throw nullptr' as type 'void *' About to 'throw nullptr' (last case) Caught 'throw nullptr' as type 'int A::*PointerToMember' And all the caught pointers are null. Not all cases work though, nullptr cannot be caught as a pointer to member function, and fixing that is difficult, so I'm keeping this open.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Fri Jul 15 18:51:51 2016 New Revision: 238396 URL: https://gcc.gnu.org/viewcvs?rev=238396=gcc=rev Log: c++/58796 Make nullptr match exception handlers of pointer type libstdc++-v3: PR c++/58796 * libsupc++/pbase_type_info.cc (__pbase_type_info::__do_catch): Make nullptr match handlers of pointer type. gcc/testsuite: PR c++/58796 * g++.dg/cpp0x/nullptr21.C: Remove void* handlers. * g++.dg/cpp0x/nullptr35.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr35.C Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/nullptr21.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/pbase_type_info.cc
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #15 from Jason Merrill --- (In reply to Jason Merrill from comment #12) > For a pointer to member function that's still problematic because the > exception object for 'throw nullptr' is currently one word, and a pointer to > member function is two. So I suppose we will need to allocate two words for > 'throw nullptr'. But clang doesn't do that; do they actually handle > catching nullptr as a pointer to member function? But then again, testing whether a PMF is null only checks the first word on non-ARM targets, so we can probably get away with still only allocating the one word and setting it to NULL. ARM will probably need to allocate two words.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
--- Comment #14 from Jason Merrill ---
Also note that a null pointer to data member is represented as -1, not 0, so
you'll want
*(ptrdiff_t*)thrown_ptr = -1;
for that case.
A null pointer to member function is { nullptr, 0 }.
You might also handle this in __pbase_type_info::__do_catch rather than
get_adjusted_ptr.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #13 from Jonathan Wakely --- (In reply to Jason Merrill from comment #12) > (In reply to Jonathan Wakely from comment #4) > > However with that patch the caught pointer is not null, so it's not right. > > For a pointer, you just need to set thrown_ptr to null. Oh, well that's easier than I thought! > For a pointer to member it's trickier, since they are thrown by reference, > and we end up returning a pointer to the exception object. I suppose that > since nullptr has no actual value we can feel free to clobber the "value" of > the exception object before returning. > > For a pointer to member function that's still problematic because the > exception object for 'throw nullptr' is currently one word, and a pointer to > member function is two. So I suppose we will need to allocate two words for > 'throw nullptr'. But clang doesn't do that; do they actually handle > catching nullptr as a pointer to member function? I don't know, when I test with clang it uses libstdc++.so, so the nullptr doesn't get caught.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #12 from Jason Merrill --- (In reply to Jonathan Wakely from comment #4) > However with that patch the caught pointer is not null, so it's not right. For a pointer, you just need to set thrown_ptr to null. For a pointer to member it's trickier, since they are thrown by reference, and we end up returning a pointer to the exception object. I suppose that since nullptr has no actual value we can feel free to clobber the "value" of the exception object before returning. For a pointer to member function that's still problematic because the exception object for 'throw nullptr' is currently one word, and a pointer to member function is two. So I suppose we will need to allocate two words for 'throw nullptr'. But clang doesn't do that; do they actually handle catching nullptr as a pointer to member function?
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.0 |6.2 --- Comment #11 from Jakub Jelinek --- GCC 6.1 has been released.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #9 from Jonathan Wakely --- Yes, it's on my list. That's why I changed the target milestone to 6.0 a week ago.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #10 from Bill Schmidt --- Apologies, Jonathan, I didn't see that. I was led here from some internal tracking and wasn't previously CC'd on the bug. Sorry for the noise.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #8 from Bill Schmidt --- Ping. I just checked current trunk and it appears this is still broken. Would it be possible to fix this in time for GCC 6? (I'm not saying this is a crucial item, but my guess is this one just slipped through the cracks.)
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Richard Biener changed: What|Removed |Added Target Milestone|5.3 |5.4 --- Comment #7 from Richard Biener --- GCC 5.3 is being released, adjusting target milestone.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jonathan Wakely changed: What|Removed |Added Target Milestone|5.4 |6.0
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.2 |5.3 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- GCC 5.2 is being released, adjusting target milestone to 5.3.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- However with that patch the caught pointer is not null, so it's not right.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Looks like this is (also) a runtime issue: normally works on clang, but does *not* if -stdlib=libstdc++ is added to the command line. Futher evidence: does not work with icc, which uses the system runtime, but works with eccp.
[Bug c++/58796] throw nullptr not caught by catch(type*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |5.0
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
--- a/libstdc++-v3/libsupc++/eh_personality.cc
+++ b/libstdc++-v3/libsupc++/eh_personality.cc
@@ -230,6 +230,13 @@ get_adjusted_ptr (const std::type_info *catch_type,
*thrown_ptr_p = thrown_ptr;
return true;
}
+ if (throw_type == typeid(nullptr))
+{
+ if (catch_type-__is_pointer_p())
+ return true;
+ if (dynamic_castconst __pointer_to_member_type_info*(catch_type))
+ return true;
+}
return false;
}
With that patch (which requires building eh_personality.cc with -std=gnu++11) I
get:
About to 'throw nullptr' (first case)
Caught 'throw nullptr' as type 'int A::*PointerToMember'
About to 'throw nullptr' (second case)
Caught 'throw nullptr' as type 'void *'
About to 'throw nullptr' (last case)
Caught 'throw nullptr' as type 'int A::*PointerToMember'
[Bug c++/58796] throw nullptr not caught by catch(type*)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-10-30
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I agree this looks like a bug. Reduced:
struct A {};
typedef int A::*PointerToMember;
int main() {
try {
throw nullptr;
} catch (PointerToMember) { // This *should* catch throw nullptr...
}
try {
throw nullptr;
} catch(void *) { // This *should* catch throw nullptr...
}
}
