I am comparing passing pointers versus references into a function. I encountered unexpected variations when taking the address of passed in references. Perhaps most notably, if f is declared as: int* const & f h is declared as: const int* const & h then & f is not equal to & h Below is: 1) test code that reproduces the issue 2) output when compiled with g++ 4.8.2 on Ubuntu 14.04 on x68_64 3) output when compiled with g++ 4.7.3 on Ubuntu 13.04 on i686 I in the output, I expect "e" through "l" to be identical. In 2, e f g and l are identical. h to k are identical to each other, but different from e f g and l. In 3, e f g and l are identical. h to k are each unique. Here is code to reproduce the issue: #include <stdio.h> void foo_ab ( int* a, int & b ) { printf ( "a %p\n", a ); printf ( "b %p\n", & b ); } void foo_cd ( void** c, void* & d ) { printf ( "c %p\n", c ); printf ( "d %p\n", & d ); } void foo_ef ( int** e, int* const & f ) { printf ( "e %p\n", e ); printf ( "f %p\n", & f ); } void foo_gh ( int** g, const int* const & h ) { printf ( "g %p\n", g ); printf ( "h %p\n", & h ); } void foo_i ( const void* const & i ) { printf ( "i %p\n", & i ); } void foo_j ( const int* const & j ) { printf ( "j %p\n", & j ); } void foo_k ( void* const & k ) { printf ( "k %p\n", & k ); } void foo_l ( int* const & l ) { printf ( "l %p\n", & l ); } int main () { int n = 5; int* p = & n; printf ( "\n" ); foo_ab ( & n, n ); // foo_cd ( & p, p ); // causes compile time error printf ( "\n" ); foo_ef ( & p, p ); printf ( "\n" ); foo_gh ( & p, p ); printf ( "\n" ); foo_i ( p ); foo_i ( p ); printf ( "\n" ); foo_j ( p ); foo_j ( p ); printf ( "\n" ); foo_k ( p ); foo_k ( p ); printf ( "\n" ); foo_l ( p ); foo_l ( p ); return 0; } ---- $ ./a.out a 0x7fff3a1e669c b 0x7fff3a1e669c e 0x7fff3a1e66a0 f 0x7fff3a1e66a0 g 0x7fff3a1e66a0 h 0x7fff3a1e66a8 i 0x7fff3a1e66a8 i 0x7fff3a1e66a8 j 0x7fff3a1e66a8 j 0x7fff3a1e66a8 k 0x7fff3a1e66a8 k 0x7fff3a1e66a8 l 0x7fff3a1e66a0 l 0x7fff3a1e66a0 $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) $ ./a.out a 0xbfc74a3c b 0xbfc74a3c e 0xbfc74a40 f 0xbfc74a40 g 0xbfc74a40 h 0xbfc74a44 i 0xbfc74a48 i 0xbfc74a4c j 0xbfc74a50 j 0xbfc74a54 k 0xbfc74a58 k 0xbfc74a5c l 0xbfc74a40 l 0xbfc74a40 $ g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.7.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
I don't see why this is a bug, g and h should be different. Here is the reason, const int* const & cannot lvalue bind to int *, it can lvalue bind to const int* or int* const. So there is a lvalue to rvalue and then a conversion from int * to const int* and then a rvalue to const lvalue reference binding to const int* const &. This is true for i, j, and k. For l, int* const& can be lvalue bind to int*.
(In reply to Parke from comment #0) > I in the output, I expect "e" through "l" to be identical. Your expectation is wrong. The functions that produce a different values from what you expect are binding a reference of some type X to an object that is not reference-compatible with X, which requires the creation of a temporary of type X. The temporary has a different address from the original object. Any conforming C++ compiler will produce similar results.
Thanks, I thought it might be something like the creation of temporaries, but could not find it discussed anywhere, and was surprised that I got different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only one temporary).
(In reply to Parke from comment #3) > Thanks, I thought it might be something like the creation of temporaries, > but could not find it discussed anywhere, and was surprised that I got > different behavior from 4.7.3 (many temporaries) and 4.8.2 (apparently only > one temporary). Well 4.8 is better at coalescing the temporaries as there was a fix to the front-end to produce a CLOBBER after the statement has ended.