[LLVMdev] GCC DejaGNU regressions

Stuart Hastings stuart at apple.com
Fri Jul 24 17:01:17 PDT 2009

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

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


More information about the llvm-dev mailing list