[LLVMbugs] [Bug 14608] New: clang-3.1 breaks a piece of code that clang-3.0 compiles correctly

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=14608

             Bug #: 14608
           Summary: clang-3.1 breaks a piece of code that clang-3.0
                    compiles correctly
           Product: new-bugs
           Version: 3.1
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: steve.linton at st-andrews.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Compiling GAP (www.gap-system.org) version 4.5.6. with clang-3.1 at
optimisation level 1 or higher breaks. In GAP the symptom is:

 ┌───────┐   GAP, Version 4.dev of today (free software, GPL)
 │  GAP  │   http://www.gap-system.org
 └───────┘   Architecture: x86_64-apple-darwin12.2.1-clang-mp-3.1-default32
 Libs used:  gmp
 Loading the library and packages ...
Components: trans 1.0, prim 2.1, small* 1.0, id* 1.0
 Packages:   AClib 1.2, Alnuth 3.0.0, AutPGrp 1.5, CRISP 1.3.5, Cryst 4.1.10, 
             CrystCat 1.1.6, CTblLib 1.2.1, FactInt 1.5.3, FGA 1.1.1, GAPDoc
1.5.1, 
             IRREDSOL 1.2.1, LAGUNA 3.6.1, Polenta 1.3.1, Polycyclic 2.10.1, 
             RadiRoot 2.6, ResClasses 3.2.0, Sophus 1.23, TomLib 1.2.2
 Try '?help' for help. See also  '?copyright' and  '?authors'
gap> v := [Z(3)];
[ Z(3) ]
gap> ConvertToVectorRep(v);
3
gap> v;
[ 0*Z(3) ] 


The last line should be [ Z(3) ] as it is in clang-3.0 (or any known version of
gcc). 

I have traced the bug, I think to the compilation of lines 478-482 of
src/vec8bit.c. I can't understand the compiled code, but in execution, that
section corrupts memory at adresses a few dozen bytes away from the ones it
should be writing to. The source lines are:

  for (i = 0; i < q; i++)
    for (j = 0; j < e; j++)
      for (k = 0; k < 256; k++)
  SETELT_FIELDINFO_8BIT(info)[(i*e + j)*256 + k] = (UInt1)
    ((k/pows[j+1])*pows[j+1] + i*pows[j] + (k % pows[j]));


i,j, k and e are 32 but unsigned integers, pows an array of the same. SETELT...
is a macro (which should be side-effect free) which returns a pointer to an
unsigned char.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.