Comment 1:

Looking at that _cgo_.o file with llvm-dwarfdump-3.5, it looks like this field:
        char y[3][0][1][2];
is generating this DW_TAG_array_type entry:
0x00000193:   DW_TAG_array_type [4] *
                DW_AT_sibling [DW_FORM_ref4]    (cu + 0x01b5 => {0x000001b5})
                DW_AT_type [DW_FORM_ref4]       (cu + 0x00c0 => {0x000000c0})
0x0000019c:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x02)
0x000001a2:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000001a8:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000001ae:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x01)
Whereas GCC 4.8.2 and Clang 3.5 generate this:
0x000000aa:   DW_TAG_array_type [4] *
                DW_AT_type [DW_FORM_ref4]       (cu + 0x0082 => {0x00000082})
                DW_AT_sibling [DW_FORM_ref4]    (cu + 0x00cb => {0x000000cb})
0x000000b3:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x02)
0x000000b9:     DW_TAG_subrange_type [6]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
0x000000be:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x00)
0x000000c4:     DW_TAG_subrange_type [5]  
                  DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b})
                  DW_AT_upper_bound [DW_FORM_data1]     (0x01)
I.e., for the [0] sized entry, they omit the DW_AT_upper_bound entry.
Looking quickly through LLVM commit history, it seems like this commit on Dec 2012 was
probably when they fixed this behavior:
http://llvm.org/viewvc/llvm-project?view=revision&revision=169312
It looks like Clang 3.3 was the first release to include that fix.  So presumably this
test will be broken on any version of OS X that uses an older (i.e., buggy) version of
Clang, such as Lion.

Comment 2:

I don't think there's anything we can do to truly solve this problem when the compiler
generates bad DWARF type information.  E.g., from the Clang 3.0 _cgo_.o, we can't
distinguish whether the field should have type "[3][0][1][2]C.char" or
"[3][1][0][2]C.char".  Arguably either would be better than "[0][1][1][2]C.char", but I
don't think it makes sense to further complicate debug/dwarf if we can't guarantee a
correct answer.
I suspect the best solution unfortunately is to simply disable
misc/cgo/test/issue8428.go on older OS X with buggy versions of Clang.  According to
http://stackoverflow.com/questions/8674546/how-to-update-llvm-clang-on-mac-osx, that
seems to be OS X Lion (Clang 3.0) and OS X Mountain Lion (Clang 3.2).
Is it possible to use +build rules to skip particular versions of a platform?  Or should
I just skip all of darwin for issue8428.go?

Comment 3:

CL https://golang.org/cl/135990043 mentions this issue.

Comment 4:

This issue was closed by revision f2e7fa9.

Status changed to Fixed.