https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #30 from Michi Henning ---
(In reply to Jonathan Wakely from comment #29)
> > make_shared(args) doesn't always do the same thing as shared_ptr(new
> > T(args))
>
> It does do effectively the same thing. The difference in behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #27 from Michi Henning ---
My apologies for my incredibly late reply. (I just stumbled across this issue
again.) And my thanks to you for taking the time to analyse this!
I think your analysis is right. 3.8.5/3:
"- the pointer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70493
--- Comment #1 from Michi Henning ---
Ah, on reading http://pubs.opengroup.org/onlinepubs/9699919799/ section 8.2, it
appears that it's OK to throw in this case.
It would be nice to have a better diagnostic in the exception though. It could
t: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: michi at triodia dot com
Target Milestone: ---
#include
int main(int, char**)
{
std::locale("");
}
Compile with --std=c++11 and run with
$ LC_ALL= LC_MONETARY=bad ./a.out
This aborts with a std::r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #25 from Michi Henning michi at triodia dot com ---
(In reply to Jonathan Wakely from comment #24)
(In reply to Michi Henning from comment #20)
I'm pretty sure that I'm not using anything in shared_ptr that's outside the
standard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #15 from Michi Henning michi at triodia dot com ---
OK, glad you are seeing it too. I initially opened this as a library issue
because I thought make_shared is to blame. But maybe not. Should I reassign to
C++?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #18 from Michi Henning michi at triodia dot com ---
Hmmm... That might be difficult because, as soon as I don't use make_shared,
the problem goes away. (With the virtual inheritance in place but a call to
shared_ptrT(args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #20 from Michi Henning michi at triodia dot com ---
(In reply to Paolo Carlini from comment #19)
I'm pretty sure it isn't. It's easy to see why: in the testcase are you
using *all* the facilities provided by std::shared_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #4 from Michi Henning michi at triodia dot com ---
Hmmm... Trying this on a different machine, it works perfectly. It looks like
there is something screwed up with the gcc installation on the machine where
I'm seeing this.
So, please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #6 from Michi Henning michi at triodia dot com ---
My apologies, I'm a newbie in the gcc bug world. Will try to mend my ways!
Cheers,
Michi.
PS: I'll work on this more tomorrow, but I'm pretty sure that gcc is not to
blame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning michi at triodia dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning michi at triodia dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #10 from Michi Henning michi at triodia dot com ---
Created attachment 31078
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31078action=edit
main.ii illustrating the segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning michi at triodia dot com changed:
What|Removed |Added
Attachment #31066|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #12 from Michi Henning michi at triodia dot com ---
Output from gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #13 from Michi Henning michi at triodia dot com ---
Just had a collegue of mine reproduce the problem with the attached archive on
a machine that was installed from the Saucy .iso image, so I think this bug is
real. It's not just
++
Assignee: unassigned at gcc dot gnu.org
Reporter: michi at triodia dot com
I have a constructor calling make_shared to pass a shared_ptr to a base class.
InvalidArgumentException::InvalidArgumentException(string const reason)
//: Exception(shared_ptrExceptionImplBase(new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #2 from Michi Henning michi at triodia dot com ---
Created attachment 31066
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31066action=edit
Stand-alone test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #3 from Michi Henning michi at triodia dot com ---
To build and run the code in the tarball:
cd exception-fix/build
cmake ..
make
make test
The problem is caused by the call to make_shared on line 33 of
UnityExceptions.h.
If you
++
Assignee: unassigned at gcc dot gnu.org
Reporter: michi at triodia dot com
The following code works as expected when compiling with
c++ -g --std=c++11 test.cpp
The program hangs until it is interrupted.
When I compile the same code with
c++ -g --std=c++11 test.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975
Michi Henning michi at triodia dot com changed:
What|Removed |Added
Version|unknown |4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975
--- Comment #6 from Michi Henning michi at triodia dot com ---
How embarrassing. The joys of default constructors :-( Stupid mistake of mine.
22 matches
Mail list logo
