http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
--- Comment #5 from rob.desbois at gmail dot com ---
The following is a side-by-side diff of the disassembly of the incorrect
version vs. a correct version (defaulting the parameter with = foo{}). The
object foo has a single member of type char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
--- Comment #4 from rob.desbois at gmail dot com ---
The problem only seems to occur when using the pattern "= {}" to default the
parameter; "= foo{}" and "= foo()" don't seem to provoke the differing
addresses.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
--- Comment #3 from rob.desbois at gmail dot com ---
Adding a destructor didn't fix it for me - though it was destroyed for the same
address as the constructed object.
constructed foo @ 0x7fffa012e5ef
default argument is at 0x7fffa01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
--- Comment #1 from rob.desbois at gmail dot com ---
...having realised that this might look like I just don't grok move
construction I expanded my test - adding copy & move constructors & assignment
operators to foo and re-running t
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rob.desbois at gmail dot com
Created attachment 32234
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32234&action=edit
Preprocessed, minimal testcase triggering unexpected behaviour
The attached minimal testc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51629
rob.desbois at gmail dot com changed:
What|Removed |Added
CC||rob.desbois at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56836
--- Comment #3 from rob.desbois at gmail dot com 2013-04-03 21:30:31 UTC ---
Agh you're right Andrew. Not the first time that rule has caught me out.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56836
Bug #: 56836
Summary: Template delegating constructor not calling target
constructor
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONF
