<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 - [ARM][AACPS] Volatile bitfield does not follow the aacps"
href="https://bugs.llvm.org/show_bug.cgi?id=43264">43264</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[ARM][AACPS] Volatile bitfield does not follow the aacps
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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>diogo.sampaio@arm.com
</td>
</tr>
<tr>
<th>CC</th>
<td>lebedev.ri@gmail.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>From the Procedure Call Standard for the Arm Architecture, Release 2019Q1.1 (
<a href="https://static.docs.arm.com/ihi0042/g/aapcs32.pdf?_ga=2.183887654.1224563356.1568044683-65427396.1558599897">https://static.docs.arm.com/ihi0042/g/aapcs32.pdf?_ga=2.183887654.1224563356.1568044683-65427396.1558599897</a>
) section 8.1 at Volatile bit-fields – preserving number and width of container
accesses:
When a volatile bit-field is read, and its container does not overlap with any
non-bit-field member, its container must be read exactly once using the access
width appropriate to the type of the container.
When a volatile bit-field is written, and its container does not overlap with
any non-bit-field member, its container must be read exactly once and written
exactly once using the access width appropriate to the type of the container.
The two accesses are not atomic.
Note: This ABI does not place any restrictions on the access widths of
bit-fields where the container overlaps with a non-bit-field member. This is
because the C/C++ memory model defines these as being separate memory
locations, which can be accessed by two threads simultaneously. For this
reason, compilers must be permitted to use a narrower memory access width
(including splitting the access into multiple instructions) to avoid writing to
a different memory location. For example, in struct S { int 8 a:24; char b; };
a write to a must not also write to the location occupied by b, this requires
at least
two memory accesses in all current Arm architectures.
-----
Now clang fails in two ways to follow these rules.
e.g.
struct S {
int x : 16;
};
void bla(volatile struct S* S){
S->x = 1;
}
-----
compiled with
clang -cc1 -internal-isystem
/work/bf/LLVM/monorepo/build/lib/clang/10.0.0/include -nostdsysteminc -triple
armv8-none-linux-eabi -S -o - -O3 -std=c11 test7.c -emit-llvm
--
produces:
--
define void @bla(%struct.S* %S) local_unnamed_addr #0 {
entry:
%0 = getelementptr inbounds %struct.S, %struct.S* %S, i32 0, i32 0
store volatile i16 1, i16* %0, align 4
ret void
}
---
we would expect
define void @bla(%struct.S* %S) local_unnamed_addr #0 {
entry:
%0 = getelementptr inbounds %struct.S, %struct.S* %S, i32 0, i32 0
%bf.load = load volatile i32, i32* %0, align 4 ; <<== a volatile write
requires at least one read. Width = 32bits == sizeof(int), not 16
store volatile i32 1, i32* %0, align 4 ; Width = 32bits == sizeof(int), not
16
ret void
}
--------</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>