caa1bf434d
than GCC 4.2 here when building 32-bit (where GCC will allow allocation of an array for which we can't get a valid past-the-end pointer), and emulate its odd behavior in 64-bit where it only allows 63 bits worth of storage in the array. The former is a correctness issue; the latter is harmless in practice (you wouldn't be able to use such an array anyway) and helps us pass a GCC DejaGNU test. Fixes <rdar://problem/8212293>. llvm-svn: 111338
8 lines
233 B
C
8 lines
233 B
C
// RUN: %clang_cc1 -triple x86_64-apple-darwin -verify %s
|
|
|
|
void f() {
|
|
int a[2147483647U][2147483647U]; // expected-error{{array is too large}}
|
|
int b[1073741825U - 1U][2147483647U];
|
|
int c[18446744073709551615U/sizeof(int)/2];
|
|
}
|