<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 4:53 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, thanks for the update Daniel!<br>
<br>
I recently saw someone on newlib mailing list say that the newlib can<br>
be compiled by clang for the ARM processor now.<br></blockquote><div><br></div><div>llvm/clang's disadvantage vs gcc is its support for as many architectures</div><div>and older CPU variants. Given it a try for the arm but I would be surprised</div><div>if it supports all of the CPU models we have BSPs for.</div><div><br></div><div>Any idea on PowerPC status? I haven't checked that in a few years but</div><div>they had a lack of maintainer issue then.</div><div><br></div><div>I am really curious to find out how this works out. It would be nice to</div><div>have RSB entries for the targets that work so we can at least try it</div><div>for analysis and make it easier for us all to bang on it. Otherwise,</div><div>it won't get used.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Gedare<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Sep 15, 2017 at 10:33 AM, Daniel Hellstrom <<a href="mailto:daniel@gaisler.com">daniel@gaisler.com</a>> wrote:<br>
> Hi,<br>
><br>
> We did submit some SPARC patches to make RTEMS compile with LLVM during May.<br>
> One of the patches which was not accepted I believe Sebastian updated and<br>
> pushed during end of July. We have not made any attempts rebuilding since.<br>
> At the time we ran the tests we were able to run most of the RTEMS<br>
> test-suite with 20-25 failures or so if I recall correctly. However most of<br>
> them was not dependent on LLVM and fixed since in the RTEMS repository, the<br>
> others were fixed in the LLVM SPARC/LEON-REX backend. I recall that there<br>
> were some potential problems with SPARC inline assembly in some cases when<br>
> building for LEON-REX (no surprise since it is not the same ISA..). Also, we<br>
> built newlib using LLVM. I'm not sure which kernel configurations we<br>
> compiled for though.<br>
><br>
> Since May we distribute a LLVM-4.0 toolchain with our bare-metal<br>
> environment. During the coming months we plan to release a LLVM toolchain<br>
> together with RCC-1.3.x. However we have some work to do on the front-end<br>
> for RTEMS first and testing of course. We will have some LLVM specific<br>
> documentation once released.<br>
><br>
> Regards,<br>
> Daniel<br>
><br>
><br>
> On 2017-09-14 02:10, Joel Sherrill wrote:<br>
><br>
> Daniel Hellstrom should ready speak up. They have it working for SPARC. I<br>
> don't know if anything special is needed for other targets so it should just<br>
> be a matter of attempting it and seeing<br>
><br>
> On Sep 13, 2017 6:46 PM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>><br>
>> I've seen some discussion about using clang to compile a few targets.<br>
>> Is there any documentation about what is known to work/not work, and<br>
>> any additional directions needed to be successful?<br>
>><br>
>> -Gedare<br>
>> ______________________________<wbr>_________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>