<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - PowerPC: Invalid code generation causing SEGV"
href="https://bugs.llvm.org/show_bug.cgi?id=33073">33073</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>PowerPC: Invalid code generation causing SEGV
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>4.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andyg1001@hotmail.co.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18457" name="attach_18457" title="Output generated by clang 4.0">attachment 18457</a> <a href="attachment.cgi?id=18457&action=edit" title="Output generated by clang 4.0">[details]</a></span>
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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>