I've noticed a couple of peculiarities with address space qualifiers (
i.e. __attribute__((address_space(x))) ) in the type names of compound
literals and I'm wondering whether either are worth reporting in
Bugzilla.
The first is when a compound literal appears in a function. Since the
object allocated by the compound literal has automatic storage duration,
I would expect that address specifiers in the type name would be
prohibited, just as they are for automatic variables. Clang does not
report this as an error. (FWIW, the Embedded C spec, ISO TR 18037,
prohibits address space qualifiers from appearing in the type names of
compound literals within functions).
The second is where the storage for the literal-generated object is
allocated. It appears that the code generator always allocates the
object in the generic address space even if an address space qualifier
is given in the type name.
The following code illustrates both of these peculiarities:
#define mem1 __attribute__((address_space(1)))
int mem1 * gp = (int mem1 ) {1, 2};
void func(void)
{
int mem1 * p = (int mem1 ) {3, 4};
}
Clang emits the following LLVM code (for the i386-pc-linux-gnu target):
@.compoundliteral = internal global [2 x i32] [i32 1, i32 2]
@gp = global i32 addrspace(1)* bitcast ([2 x i32]* @.compoundliteral
to i32 addrspace(1)*), align 4
define void @func() nounwind {
entry:
%p = alloca i32 addrspace(1)*, align 4
%.compoundliteral = alloca [2 x i32]
%.array = getelementptr [2 x i32]* %.compoundliteral, i32 0, i32
0
store i32 3, i32* %.array
%.array1 = getelementptr [2 x i32]* %.compoundliteral, i32 0,
i32 1
store i32 4, i32* %.array1
%arraydecay = getelementptr [2 x i32]* %.compoundliteral, i32 0,
i32 0
%ptrconv = bitcast i32* %arraydecay to i32 addrspace(1)*
store i32 addrspace(1)* %ptrconv, i32 addrspace(1)** %p
ret void
}
Are either of these bug-worthy?
-Ken