<div dir="ltr"><div><div>Hi Gabor,<br><br></div><div>  I found that .eabi_attribute will always overwrite the value defined by the .fpu directive regardless the order of the directives.  For example,<br></div><div><br></div>

<div>(1)<br>.eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3<br>.fpu neon<br><br></div><div>(2)<br>.fpu neon<br>.eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3<br><br></div><div>The result binaries of (1) and (2) are identical.  To workaround the first case, I have to check whether the Tag has been defined or not.  If it is defined, then we should ignore the value defined by .fpu directive.<br>

<br></div><div>>> The GNU assembler does owerwrite it in this case.<br><br></div><div>  What do you mean by GNU assembler does overwrite this?  May you give an example?  Thanks.<br>
<br>  Last, but not the least, I am sorry for the duplicated work.  I should have uploaded my WIP changes to BugZilla earlier.  Thanks for your interest and efforts to this bug.<br><br></div><div>Best regards,<br>Logan<br>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 1:00 AM, Gabor Ballabas <span dir="ltr"><<a href="mailto:gaborb@inf.u-szeged.hu" target="_blank">gaborb@inf.u-szeged.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rafael,<br>
<br>
Thanks for the review, but it seems that Logan's solution is more<br>
advanced than mine<br>
(and it works as you suggested using the streamer instead of the parser).<br>
Thanks anyway!<br>
<br>
Best regards,<br>
Gabor Ballabas<br>
<div class="HOEnZb"><div class="h5"><br>
On 10/18/13 21:08, Rafael Espíndola wrote:<br>
> Thank you so much for working on this!<br>
><br>
> Can AttributeEmitter be merged into the target asm streamer? I.E. just<br>
> add the MaybeSwitchVendor, EmitAttribute, EmitTextAttribute and Finish<br>
> to the target streamer.<br>
><br>
> +  // Maps for ARM build attributes.<br>
> +  std::map<unsigned, unsigned> AttributeMap;<br>
><br>
> What is the range of these integers? There is almost certainly a<br>
> better data structure for doing this. Why is this on the parser? Can't<br>
> the parser just call EmitAttribute for very .eabi_attribute and let<br>
> the streamer handle it?<br>
><br>
><br>
><br>
> On 18 October 2013 09:21, Gabor Ballabas <<a href="mailto:gaborb@inf.u-szeged.hu">gaborb@inf.u-szeged.hu</a>> wrote:<br>
>> This is a work-in-progress patch for this bug:<br>
>> <a href="http://llvm.org/bugs/show_bug.cgi?id=15172" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=15172</a><br>
>> This patch only handles the .eabi_attribute directive but I can make the<br>
>> .cpu, .fpu and .arch<br>
>> directives work as well with a similar approach.<br>
>><br>
>> Best regards,<br>
>> Gabor Ballabas<br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>