[Bug c++/60367] Default argument object is not getting constructed
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.
I have confirmed that member data set in the default constructor seems to be
correct in the temporary despite it being at an 'unconstructed' address. The
address of the 'unconstructed' temporary is consistently the size of the
nearest whole word to sizeof(foo) below the actually-constructed address, so it
seems the address isn't just random but possibly correct in itself.
It seems that the copy/move constructor has been replaced by a memcpy(), thus
losing the side-effects. I didn't state earlier but should confirm: this occurs
with -O0 turning off optimizations.
Behaviour with clang (3.3 final) is as expected.
[Bug c++/60367] Default argument object is not getting constructed
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 initialized in default, move, and
copy ctors.
incorrect version | correct version
---|---
push %rbp push %rbp
mov%rsp,%rbp mov%rsp,%rbp
push %rbx push %rbx
sub$0x28,%rsp | sub$0x18,%rsp
lea-0x11(%rbp),%rax lea-0x11(%rbp),%rax
mov%rax,%rdi mov%rax,%rdi
callq 0x400bbe _ZN3fooC2Ev | callq 0x400bb8 _ZN3fooC2Ev
movzbl -0x11(%rbp),%eax| lea-0x11(%rbp),%rax
mov%al,-0x30(%rbp)
lea-0x30(%rbp),%rax
mov%rax,%rdi mov%rax,%rdi
callq 0x4009f0 _Z6test_a3foo| callq 0x400a50 _Z6test_b3foo
lea-0x11(%rbp),%rax lea-0x11(%rbp),%rax
mov%rax,%rdi mov%rax,%rdi
callq 0x400bfe _ZN3fooD2Ev | callq 0x400bf8 _ZN3fooD2Ev
mov$0x0,%eax mov$0x0,%eax
jmp0x400b65 main+85 | jmp0x400b5e main+78
mov%rax,%rbx mov%rax,%rbx
lea-0x11(%rbp),%rax lea-0x11(%rbp),%rax
mov%rax,%rdi mov%rax,%rdi
callq 0x400bfe _ZN3fooD2Ev | callq 0x400bf8 _ZN3fooD2Ev
mov%rbx,%rax mov%rbx,%rax
mov%rax,%rdi mov%rax,%rdi
callq 0x4008b0 _Unwind_Resume@plt callq 0x4008b0
_Unwind_Resume@plt
add$0x28,%rsp | add$0x18,%rsp
pop%rbx pop%rbx
pop%rbp pop%rbp
retq retq
It does look like the incorrect version on the left could be bitwise-copying
the default-constructed object.
As an aside - both versions have a single constructor call but TWO destructor
calls...
[Bug c++/60367] Default argument object is not getting constructed
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 the test still gives the same result, i.e. the address of the function argument is not the address of a constructed object: constructed foo @ 0x7fff80e0f25f default argument is at 0x7fff80e0f240 (I can attach the enhanced test on request)
[Bug c++/60367] Default argument object is not getting constructed
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 0x7fffa012e5d0 destructed foo @ 0x7fffa012e5ef For what it's worth I tried putting a size_t member into the object being constructed, and using a member-initializer to set it to an identifiable bit pattern - even though the temporary was at an 'unconstructed' address, the size_t was repeatedly correct. The gremlins are messing with my head...
[Bug c++/60367] New: Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
Bug ID: 60367
Summary: Default argument object is not getting constructed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=32234action=edit
Preprocessed, minimal testcase triggering unexpected behaviour
The attached minimal testcase has the following function with
default-constructed default argument:
void do_something( foo f = {} )
{
std::cout default argument is at f std::endl;
}
The constructor for foo outputs its address; I got the following output from a
single run:
constructed foo @ 0x710bdb7f
default argument is at 0x710bdb60
It shows that only 1 foo was constructed, and not at the same address as that
of the default argument. It's been a lng week, but I can't see anything
wrong with the code. In the real code on which this was based, a segfault was
occurring when running the destructor of a foo that was move-constructed from
the default argument, because the underlying memory was seemingly
uninitialised.
build command output
--
[rob@localhost tests]$ g++ -v -save-temps -Wall -Wextra --std=c++0x
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
default-args-fail.cpp -o ./default-args-fail
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-o'
'./default-args-fail' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE
default-args-fail.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fpch-preprocess -o default-args-fail.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-o'
'./default-args-fail' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -fpreprocessed
default-args-fail.ii -quiet -dumpbase default-args-fail.cpp -mtune=generic
-march=x86-64 -auxbase default-args-fail -Wall -Wextra -std=c++11 -version
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
default-args-fail.s
GNU C++ (GCC) version 4.8.2 20131212 (Red Hat 4.8.2-7) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 20131212 (Red Hat 4.8.2-7) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36de953cba87bab1ad58280401e36d59
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std
[Bug c++/51629] Default Destructor and template extern Instantiation cause the Destructor to be missing
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 com --- Comment #2 from rob.desbois at gmail dot com --- I believe I have incurred this same bug on gcc 4.7.2 with copy constructor, and both move copy assignment operators. A workaround for my case is to have only the function declaration inline, and to move the defaulted declaration out of line. Keeping everything else the same - extern template declaration, explicit template instantiation, and file layout - this yields the required results.
[Bug c++/56836] New: Template delegating constructor not calling target constructor
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: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rob.desb...@gmail.com Created attachment 29799 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29799 Preprocessed source to reproduce failure Source attached with template delegating constructor; no call to the desired target is performed. [rob@robdes tests]$ g++ -v -save-temps --std=c++11 bug-constructor-delegation.cpp Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1plus -E -quiet -v -D_GNU_SOURCE bug-constructor-delegation.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o bug-constructor-delegation.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1plus -fpreprocessed bug-constructor-delegation.ii -quiet -dumpbase bug-constructor-delegation.cpp -mtune=generic -march=x86-64 -auxbase bug-constructor-delegation -std=c++11 -version -o bug-constructor-delegation.s GNU C++ (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux) compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux) compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c80d6366117d4cf1da5e1787031f4a46 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o bug-constructor-delegation.o bug-constructor-delegation.s GNU assembler version 2.22.52.0.1 (x86_64-redhat-linux) using BFD version version 2.22.52.0.1-10.fc17 20120131 COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/collect2 --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
[Bug c++/56836] Template delegating constructor not calling target constructor
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.
