The most trivial example of the behaviour is this: #include <stdint.h> static inline uint64_t foo() { return 42; } uint64_t f = foo(); G++ generates the following: .file "test.cc" .section .text.startup,"ax",@progbits .p2align 4,,15 .type _GLOBAL__sub_I_f, @function _GLOBAL__sub_I_f: .LFB2: .cfi_startproc movq $42, f(%rip) ret .cfi_endproc .LFE2: .size _GLOBAL__sub_I_f, .-_GLOBAL__sub_I_f .section .init_array,"aw" .align 8 .quad _GLOBAL__sub_I_f .globl f .bss .align 8 .type f, @object .size f, 8 f: .zero 8 .ident "GCC: (Debian 4.7.1-2) 4.7.1" .section .note.GNU-stack,"",@progbits For reference, clang++ generates the following: .file "test.cc" .type f,@object # @f .data .globl f .align 8 f: .quad 42 # 0x2a .size f, 8 .section ".note.GNU-stack","",@progbits There are cases where g++ is able to generate code like clang++, but I can't find one just now.
With -std=c++11 and constexpr on the static inline it is already compiled into the expected form. For -O0 it shouldn't be optimized into that without constexpr, but as an optimization it would be nice if non-constexpr marked trivial functions could be as an optimization handled like constexpr ones in some cases (in particular when deciding if an initializer can be output as simple constant). Jason?
This is basically the same as PR 4131. *** This bug has been marked as a duplicate of bug 4131 ***
I guess we'd need to do some discovery of potential constexpr functions (that aren't marked that way though), use some bit other than DECL_DECLARED_CONSTEXPR_P for those, pass some flag from maybe_constant_value down to potential_constant_expression and cxx_eval_outermost_constant_expr (in addition to allow_non_constant or perhaps as enum instead of bool of allow_non_constant) and with optimize treat also !DECL_DECLARED_CONSTEXPR_P && DECL_CONSTEXPR_LIKE_P calls. Or is maybe_constant_value ever used to decide if a C++ program is valid or not?