Address space qualifiers in compound literal type names

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

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).

That's a missing diagnostic; it's definitely not supposed to be legal.
Patch welcome.

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.

Well spotted; it turns out to be just a simple oversight in the code
generation. I have a patch in hand which I'll commit as soon as I'm
finished rebuilding my tree.

Are either of these bug-worthy?

Yes, both bug-worthy, but don't bother filing a bug for the code
generation issue, since I already have the fix.

-Eli

> Are either of these bug-worthy?

Yes, both bug-worthy, but don't bother filing a bug for the
code generation issue, since I already have the fix.

Okay. Reported as bug 4790:
  http://llvm.org/bugs/show_bug.cgi?id=4790

-Ken