On Dec 11, 2007, at 10:45 PM, Chris Lattner wrote:
@foo = internal global i32 0 addrspace(1)
@foo = weak global i32 0 addrspace(1)
@foo = linkonce global i32 0 addrspace(1)
@foo = appending global i32 0 addrspace(1)
@foo = dllexport global i32 0 addrspace(1)
I prefer that too, but I don't see how you're going to get bison to
accept "external global i32 addrspace(1)".
The problem is placing the 'addrspace()' betwen the type name and
the value of a 'ConstVal'. The pattern for external linkage global
variables refers to 'Types' rather than 'ConstVal', so it works just
fine.
Please verify that the number of shift/reduce and reduce/reduce
conflicts doesn't go up.
They don't.
Ok. It would still be nicer to get to:
@foo = dllexport global i32 addrspace(1) 0
:)
Yes. Bison ate its own head when I tried to do this though. Also
there are nasty side affects of allowing addrspace() on types in
ConstVals in the parser as it allows addrspace() then on types used
in constant expressions. I think the current way really is best right
now.
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
