[cfe-dev] static initialization of global namespace scope constexpr objects

Suman Kar skarpio at gmail.com
Mon Jun 11 18:27:20 PDT 2012


Hello,

I am perusing through N2235 (Generalized Constant Expressions) and was trying
out the example on page 8, namely:

struct complex {
	constexpr complex(double r, double i) : re(r), im(i) { }
	constexpr double real() { return re; }
	constexpr double imag() { return im; }
private:
	double re;
	double im;
};
constexpr complex I(0, 1); // OK -- literal complex

constexpr double d = I.real(); // added by me

I generated the assembler output with my clang++ build:

$ /d/llvm_workspace/build/Debug+Asserts/bin/clang++ -v
clang version 3.2 (trunk 157115) (llvm/trunk 157155)
Target: i686-pc-mingw32
Thread model: posix

and it churned out the following:

	.data
	.align	8
__ZL1I:
	.quad	0
	.quad	4607182418800017408

	.align	8
__ZL1d:
	.quad	0

However, I was hoping that in the regular mode, static initialization would help
put this in a readonly data section as the gcc 4.6.2 does (with the same file):

	.file	"constexpr.cpp"
	.data
	.align 8
__ZL1I:
	.long	0
	.long	0
	.long	0
	.long	1072693248
	.section .rdata,"dr"
	.align 8
__ZL1d:
	.space 8
	
GCC is not perfect as it puts only the double in read-only memory. I am not sure
why this is so. However, I am unable to fathom clang's behavior here. Is my
understanding of constexpr at fault here? In the ideal case, shouldn't both I
and d be move to ro-section?

Also, does 3.6.2/3 mandate that static initialization will not occur for objects
with extern linkage? IOW, the following:

extern constexpr complex I(0, 1); // OK -- literal complex

will always require dynamic initialization and can thus never be in a
ro-section?


Regards,
Suman



More information about the cfe-dev mailing list