<div dir="ltr">On Fri, Jan 30, 2015 at 10:20 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 30, 2015 at 9:58 AM, Saleem Abdulrasool<br>
<<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br>
> Author: compnerd<br>
> Date: Fri Jan 30 11:58:25 2015<br>
> New Revision: 227584<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=227584&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=227584&view=rev</a><br>
> Log:<br>
> ARM: correct handling of .fpu directive<br>
><br>
> The FPU directive permits the user to switch the target FPU, enabling<br>
> instructions that would be otherwise unavailable.  However, when configuring the<br>
> new subtarget features, we would not enable the implied functions for newer<br>
> FPUs.  This would result in invalid rejection of valid input.  Ensure that we<br>
> inherit the implied FPU functionality when enabling newer versions of the FPU.<br>
> Fortunately, these are mostly hierarchical, unlike the CPUs.<br>
><br>
> Addresses PR22395.<br>
<br>
</span>Should we merge this to 3.6?<br>
</blockquote></div><br>Good call, I think that is a good idea.<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>