[llvm-bugs] [Bug 33073] New: PowerPC: Invalid code generation causing SEGV

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33073

            Bug ID: 33073
           Summary: PowerPC: Invalid code generation causing SEGV
           Product: clang
           Version: 4.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: andyg1001 at hotmail.co.uk
                CC: llvm-bugs at lists.llvm.org

Created attachment 18457
  --> https://bugs.llvm.org/attachment.cgi?id=18457&action=edit
Output generated by clang 4.0

I have recently upgraded from clang 3.8 to 4.0, and I am now getting
segmentation fault crashes in compiled code for PowerPC 603e.

I have narrowed the crash to a particular function in the sqlite3 library that
I am using.  The following code is where the segmentation fault occurs, and the
line marked "uncomment this line" eradicates the problem.  The complete
software application built around this then works seemingly perfectly (albeit
producing a lot of unwanted console output!), although I may simply not be
triggering the problem if it exists elsewhere.  The code generation of this
function, however, seems reliably broken.

This is the code fragment from sqlite3:

  __attribute__ ((noinline))
  /*SQLITE_PRIVATE*/ i64 sqlite3VdbeIntValue(Mem *pMem){
    int flags;
    assert( pMem->db==0 || sqlite3_mutex_held(pMem->db->mutex) );
    assert( EIGHT_BYTE_ALIGNMENT(pMem) );
    flags = pMem->flags;
    if( flags & MEM_Int ){
      // puts("xyz"); // <- uncomment this line "fixes" the compile
      return pMem->u.i;
    }else if( flags & MEM_Real ){
      return doubleToInt64(pMem->r);
    }else if( flags & (MEM_Str|MEM_Blob) ){
      i64 value = 0;
      assert( pMem->z || pMem->n==0 );
      testcase( pMem->z==0 );
      sqlite3Atoi64(pMem->z, &value, pMem->n, pMem->enc);
      return value;
    }else{
      return 0;
    }
  }

I changed the function to non-inlined so that its presence in the compiler
output was easy to find.  It makes no difference to the validity of the
generated executable.

I have attached four fragments of the compiler output, both for the "working"
version (with the puts line) and the broken version (without), and then both
for llvm output and ppc assembly output.  I have trimmed out the majority of
these files since the files are tens of kilobytes, but I have left in the parts
where the differences in output exist.

In case it is helpful, I am compiling with -O2 and -fPIC.

I will attempt to rebuild the 3.8 compiler and check the output generated by
this for differences.  If I succeed, I will upload this too.

Cheers,
Andy

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170517/c3b90753/attachment.html>