<html>
<head>
<base href="https://llvm.org/bugs/" />
</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 --- - Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the ABI involved"
href="https://llvm.org/bugs/show_bug.cgi?id=26519">26519</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the ABI involved
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.8
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>FreeBSD
</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>-New Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>markmi@dsl-only.net
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Comparing clang 3.8.0 (via FreeBSD's projects/clang380-import svn) generated
code for TARGET_ARCH=powerpc (32-bit) to gcc 4.2.1 generated code. . .
clang 3.8.0 based Str_Match preamble (from make):
0x181a4a8 <Str_Match>: mflr r0
0x181a4ac <Str_Match+4>: stw r31,-4(r1) # Clang's frame pointer (r31)
# saved before stack pointer
changed.
0x181a4b0 <Str_Match+8>: stw r0,4(r1) # lr saved before stack pointer
changed.
0x181a4b4 <Str_Match+12>: stwu r1,-32(r1) # Stack pointer finally saved
and
# changed.
0x181a4b8 <Str_Match+16>: mr r31,r1 # r31 is the frame pointer
under clang.
0x181a4bc <Str_Match+20>: stw r30,24(r31)
gcc 4.2.1 based Str_Match preamble:
0x1819cb8 <Str_Match>: mflr r0
0x1819cbc <Str_Match+4>: stwu r1,-32(r1) # Stack pointer saved and
changed first.
0x1819cc0 <Str_Match+8>: stw r31,28(r1) # r31 saved after stack pointer
changed.
0x1819cc4 <Str_Match+12>: mr r31,r3 # gcc 4.2.1 does not reserve
# r31 for use as a frame
pointer.
0x1819cc8 <Str_Match+16>: stw r30,24(r1)
0x1819ccc <Str_Match+20>: stw r0,36(r1) # lr saved after stack pointer
changed.
Picking a different example for postamble code, showing just clang 3.8.0's
code:
0x1801b8c <Buf_AddBytes+104>: lwz r30,24(r31)
0x1801b90 <Buf_AddBytes+108>: lwz r29,20(r31)
0x1801b94 <Buf_AddBytes+112>: lwz r28,16(r31)
0x1801b98 <Buf_AddBytes+116>: lwz r27,12(r31)
0x1801b9c <Buf_AddBytes+120>: lwz r26,8(r31)
0x1801ba0 <Buf_AddBytes+124>: addi r1,r1,32 # Stack pointer adjusted
first
0x1801ba4 <Buf_AddBytes+128>: lwz r0,4(r1)
0x1801ba8 <Buf_AddBytes+132>: lwz r31,-4(r1) # Then Frame Pointer load
happens
# "outside" the new stack
range.
0x1801bac <Buf_AddBytes+136>: mtlr r0
0x1801bb0 <Buf_AddBytes+140>: blr
In other words: clang 3.8.0's generated 32-bit powerpc code is based on there
being a safe scratch area below the stack ("below" by memory address). So
similar to the 224 byte "red zone" area that 32-bit AIX powerpc and 32-bit
Darwin powerpc use.
I'm told by Nathan Whithorn that "the 32-bit ELF ABI does not require any such
red zone" and so that clang 3.8.0 is violating the ABI that is supposed to be
involved.
I do not have specific document or section references (or web links) to list
for the ABI details at this time. I'm just reporting what I'm told by FreeBSD
folks.
I used "make" code as the example above because something like "make -j 6
buildworld" uses signal delivery extensively (SIGCHLD) and such a build its
gets a SEGV in a make process within the 1st few minutes (on a "Quad core G5
PowerMac" using a FreeBSD powerpc 32-bit installation). The signal delivery is
sometimes replacing the value at "-4(r1)" in the above code before it is loaded
back into r31 (the clang 3.8.0 framepointer register for powerpc as it is
currently generating code). The FreeBSD signal delivery for 32-bit powerpc does
not have/use a "red zone" on the smaller-address side of the stack.</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>