When using the conditional operator (?:), it takes the address of its operands when they are constant values.
Compilation Output: -- Start -- [r...@casper ~]# g++ -v -save-temps bug.cpp Using built-in specs. Target: i586-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-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --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=i586 --build=i586-redhat-linux Thread model: posix gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/libexec/gcc/i586-redhat-linux/4.4.1/cc1plus -E -quiet -v -D_GNU_SOURCE bug.cpp -mtune=generic -march=i586 -fpch-preprocess -o bug.ii ignoring nonexistent directory "/usr/lib/gcc/i586-redhat-linux/4.4.1/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../i586-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/i586-redhat-linux /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/backward /usr/local/include /usr/lib/gcc/i586-redhat-linux/4.4.1/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/libexec/gcc/i586-redhat-linux/4.4.1/cc1plus -fpreprocessed bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=i586 -auxbase bug -version -o bug.s GNU C++ (GCC) version 4.4.1 20090725 (Red Hat 4.4.1-2) (i586-redhat-linux) compiled by GNU C version 4.4.1 20090725 (Red Hat 4.4.1-2), GMP version 4.2.4, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=61 --param ggc-min-heapsize=59733 Compiler executable checksum: e983968af33489f00d517096be08dea1 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=i586' as -V -Qy -o bug.o bug.s GNU assembler version 2.19.51.0.14 (i586-redhat-linux) using BFD version version 2.19.51.0.14-1.fc11 20090722 COMPILER_PATH=/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/:/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=i586' /usr/libexec/gcc/i586-redhat-linux/4.4.1/collect2 --eh-frame-hdr --build-id -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crti.o /usr/lib/gcc/i586-redhat-linux/4.4.1/crtbegin.o -L/usr/lib/gcc/i586-redhat-linux/4.4.1 -L/usr/lib/gcc/i586-redhat-linux/4.4.1 -L/usr/lib/gcc/i586-redhat-linux/4.4.1/../../.. bug.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i586-redhat-linux/4.4.1/crtend.o /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crtn.o bug.o: In function `Test::Func(bool)': bug.cpp:(.text+0x13): undefined reference to `Test::A' bug.cpp:(.text+0x1a): undefined reference to `Test::B' collect2: ld returned 1 exit status -- End -- Contents of bug.ii: -- Start -- [r...@casper ~]# cat bug.ii # 1 "bug.cpp" # 1 "<built-in>" # 1 "<command-line>" # 1 "bug.cpp" class Test { public: static const unsigned A = 0; static const unsigned B = 1; unsigned Func(bool arg); }; unsigned Test::Func(bool arg) { return arg ? Test::A : Test::B; } int main(int argc, char **argv) { return 0; } -- End -- Disassembly of bug.o shows: [crop] 00000000 <_ZN4Test4FuncEb>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 04 sub $0x4,%esp 6: 8b 45 0c mov 0xc(%ebp),%eax 9: 88 45 fc mov %al,-0x4(%ebp) c: 80 7d fc 00 cmpb $0x0,-0x4(%ebp) 10: 74 07 je 19 <_ZN4Test4FuncEb+0x19> 12: a1 00 00 00 00 mov 0x0,%eax 17: eb 05 jmp 1e <_ZN4Test4FuncEb+0x1e> 19: a1 00 00 00 00 mov 0x0,%eax 1e: c9 leave 1f: c3 ret [crop] So at address 12 and 19 you can see that the MOV instruction inserted is an A1 type, i.e. move the contents of an address, rather than a move immediate value variant of MOV, e.g. C7 or B8. Casting either or both operands such as: return arg ? (unsigned) Test::A : (unsigned) Test::B; or using an if-else construct causes different (correct?) code to be emitted: -- Start -- 00000000 <_ZN4Test4FuncEb>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 04 sub $0x4,%esp 6: 8b 45 0c mov 0xc(%ebp),%eax 9: 88 45 fc mov %al,-0x4(%ebp) c: 80 7d fc 00 cmpb $0x0,-0x4(%ebp) 10: 74 07 je 19 <_ZN4Test4FuncEb+0x19> 12: b8 00 00 00 00 mov $0x0,%eax 17: eb 05 jmp 1e <_ZN4Test4FuncEb+0x1e> 19: b8 01 00 00 00 mov $0x1,%eax 1e: c9 leave 1f: c3 ret -- End -- Some discussions of this online indicate that, per the standard, this is possibly allowable behaviour, but some other discussion about proposed standard fixes (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#696), seem to be relevant here. Regardless of these discussions, this appears to be remarkably unfriendly interpretation/implementation for programmer usage. -- Summary: Conditional operator takes address of constant operands Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot mcgougan at braintree dot com dot au GCC build triplet: i586-redhat-linux GCC host triplet: i586-redhat-linux GCC target triplet: i586-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41541