<html>
<head>
<base href="http://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 --- - Restrict ARM assembly header flags to the header"
href="http://llvm.org/bugs/show_bug.cgi?id=20757">20757</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Restrict ARM assembly header flags to the header
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</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>Backend: ARM
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>renato.golin@linaro.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>As extensively discussed in this thread:
<a href="https://sourceware.org/ml/binutils/2014-08/msg00119.html">https://sourceware.org/ml/binutils/2014-08/msg00119.html</a>
Some architecture flags (fpu/cpu/arch/arch_extension/eabi_attribute) do not
belong in the middle of assembly files. This includes hand-coded, inline and
included assembly blocks which should not change the behaviour of the compile
unit mid-way through the compilation process.
GNU folks are (understandably) reluctant to restrict this unintentional, and
possibly destructive, functionality, even though they agree that this is not
how it should be.
The technical consensus seems to be that those flags should be either
restricted to the header (ie. before any code/text), or on a first come, first
served basis, though the latter creates problems if the original file didn't
have any flags and some include/inline asm added the wrong one. Current
behaviour is last come, last served, which is plain wrong, if in text, but ok
if in the header.
We can start by adding a warning that could be turned into an error (via
-Werror), and see how it goes from there. If at least we warn, the user can't
complain that further steps (linking, execution) fail without warning.
My proposal is the following:
1. Header directives shall warn when used in text and *only* change the
behaviour for instruction selection purposes, not for module-wide properties
(like build attributes).
2. If header directives are not present in the header, module-wide properties
will be inferred from the command line, architectural descriptions, etc. even
if they are present in the text.
3. The semantics of directives in text will be that they will change only the
specific behaviour they're related to and they will be valid until another
similar directive is issues or the end of file (compile unit) is reached.
4. Related flags shall compliment each other. So, .cpu cortex-a8 shall set VFP3
and NEON, while .fpu vfp2 shall only unset VFP3, not NEON and not move the CPU
back to where VFP2 was the default.
5. Duplicate header directives in the header generates a *different* warning,
but are accepted on a last come, last served basis.
6. Both warnings should become errors when in -Werror mode.
cheers,
--renato</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>