The GCC DejaGNU testsuite has discovered some regressions. Here's one; this was reduced from testsuite/gcc.apple/4656532.c: typedef long long __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); static __inline __m64 __attribute__((__always_inline__, __nodebug__)) _mm_slli_si64 (__m64 __m, int __count) { } __m64 x, y; void t1(int n) { y = _mm_slli_si64(x, n); } Compiled with LLVM-GCC (v76963) on Darwin/x86, this generates an ICE in the GCC/LLVM conversion layer. Here's another test that want's to provoke lots of null pointer diagnostics; several such diagnostics are no longer happening, on lines 69, 71, 72, 75, 77, and 78: -------------- next part -------------- A non-text attachment was scrubbed... Name: nonnull-3.c Type: application/octet-stream Size: 5404 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090724/6b1e5042/attachment.obj> -------------- next part -------------- Here's another test that aborts at runtime (it's gcc.dg/pr26719.c): /* { dg-do compile } */ /* { dg-do run } */ /* { dg-options "-O2" } */ void abort (void); int table[32][256]; int main(void) { int i, j; for (i = 0; i < 32; i++) for (j = 0; j < 256; j++) table[i][j] = ((signed char)j) * i; if (table[9][132] != -1116) abort (); return 0; } I've only scratched the surface here; my low-priority testing rig thinks it has found 400+ regressions. (It's wrong; it didn't locate libstdc++ this time, so most of the C++ tests failed.) Do any of these "ring a bell" with anyone? The morbidly curious can see the awfulness here. Warning: there's a lot of noise here; the C++ results are mostly useless. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: regressions.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090724/6b1e5042/attachment.txt> -------------- next part -------------- Note that this test rig does not record "failures." Instead, when a test fails, it records that some previous revision of LLVM-GCC passed that given test (i.e. it records regressions). Ergo, a line like this: 74228.prev/gcc.sum:PASS: gcc.dg/i386-bitfield4.c scan-assembler-not movb says "The r74228 checkout of LLVM-GCC passed the gcc.dg/i386- bitfield4.c scan-assembler-not movb test, but the most recent LLVM-GCC (r76963) failed." stuart
On Jul 24, 2009, at 5:01 PM, Stuart Hastings wrote:> The GCC DejaGNU testsuite has discovered some regressions. Here's > one; this was reduced from testsuite/gcc.apple/4656532.c: > > typedef long long __m64 __attribute__ ((__vector_size__ (8), > __may_alias__)); > static __inline __m64 __attribute__((__always_inline__, > __nodebug__)) _mm_slli_si64 (__m64 __m, int __count) { > } > __m64 x, y; > void t1(int n) { > y = _mm_slli_si64(x, n); > } > > Compiled with LLVM-GCC (v76963) on Darwin/x86, this generates an ICE > in the GCC/LLVM conversion layer. > > Here's another test that want's to provoke lots of null pointer > diagnostics; several such diagnostics are no longer happening, on > lines 69, 71, 72, 75, 77, and 78: > > <nonnull-3.c> > > > Here's another test that aborts at runtime (it's gcc.dg/pr26719.c): > > /* { dg-do compile } */ > /* { dg-do run } */ > /* { dg-options "-O2" } */ > > void abort (void); > > int table[32][256]; > > int main(void) > { > int i, j; > > for (i = 0; i < 32; i++) > for (j = 0; j < 256; j++) > table[i][j] = ((signed char)j) * i; > > if (table[9][132] != -1116) > abort (); > > return 0; > } > > I've only scratched the surface here; my low-priority testing rig > thinks it has found 400+ regressions. (It's wrong; it didn't locate > libstdc++ this time, so most of the C++ tests failed.) > > Do any of these "ring a bell" with anyone? >It doesn't sound familiar. Go ahead and file PRs for them. Thanks! -bw> The morbidly curious can see the awfulness here. Warning: there's a > lot of noise here; the C++ results are mostly useless. > > <regressions.txt> > > > Note that this test rig does not record "failures." Instead, when > a test fails, it records that some previous revision of LLVM-GCC > passed that given test (i.e. it records regressions). Ergo, a line > like this: > > 74228.prev/gcc.sum:PASS: gcc.dg/i386-bitfield4.c scan-assembler-not > movb > > says "The r74228 checkout of LLVM-GCC passed the gcc.dg/i386- > bitfield4.c scan-assembler-not movb test, but the most recent LLVM- > GCC (r76963) failed." > > stuart_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Jul 24, 2009, at 5:01 PM, Stuart Hastings wrote:> Here's another test that aborts at runtime (it's gcc.dg/pr26719.c): > > /* { dg-do compile } */ > /* { dg-do run } */ > /* { dg-options "-O2" } */ > > void abort (void); > > int table[32][256]; > > int main(void) > { > int i, j; > > for (i = 0; i < 32; i++) > for (j = 0; j < 256; j++) > table[i][j] = ((signed char)j) * i; > > if (table[9][132] != -1116) > abort (); > > return 0; > }This one is fixed in r77078. Dan
Seemingly Similar Threads
- [LLVMdev] "Value has wrong type!" on Bool:4 bitfield
- [LLVMdev] Making GEP into vector illegal?
- [LLVMdev] Making GEP into vector illegal?
- [LLVMdev] [clang] SSE2 intrinsics (emmintrin.h): _mm_movpi64_pi64 should be _mm_movpi64_epi64?
- [LLVMdev] Making GEP into vector illegal?