<html><head></head><body>Thanks Tom, <br>
<br>
That sounds great. Good luck with the release<br>
<br>
Alp.<br>
<br><br><div class="gmail_quote">On 6 May 2014 16:21:19 BST, Tom Stellard <tom@stellard.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> <br /> On 05/05/2014 20:51, Richard Smith wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <br /> <chandlerc@google.com <mailto:chandlerc@google.com>> wrote:<br /><br /> On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp@nuanti.com<br /> <mailto:alp@nuanti.com>> wrote:<br /><br /> I suspect that pulling in clang header fixes r201729, r202911<br /> and r207606 to 3.4.1 will resolve libstdc++ / glibc<br /> compatibility issues people have been having with 3.4:<br /><br /> r201729: Teach Clang to provide ::max_align_t in C11 and<br /> C++11 modes)<br /> r202911: Headers:!
Provide
an ABI compatible max_align_t when<br /> _MSC_VER is defined)<br /> r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL,<br /> ptrdiff_t, wint_t}.<br /><br /> The changes look safe to merge but I'd like to hear a second<br /> opinion from Chandler or Nico.<br /><br /><br /> I believe all of these are very safe, but I respect Tom's position<br /> here. As he is managing the release, he gets to say "not in this<br /> one". If you want someone to approve merging these three patches<br /> into any release, Richard Smith is the person to ask IMO.<br /><br /><br /> The first two are approved for the branch if Tom wants to take them <br /> (and they seem like good fixes to have).<br /><br /> Tom: if you take r201729, you will need to also take the corresponding <br /> libc++ change, r201843.<br /><br /> r207606 hasn't had much time to bake, and fixes a problem that is not <br /> a regression, so I'd be hesitant to ap!
prove it
for 3.4.1.<br /></blockquote> <br /> Thanks for pointing that out Richard. r201729 + r201843 sounds good.<br /> <br /> I'm concerned that advice has already appeared online instructing users <br /> to patch their libstdc++ system headers in order to install clang 3.4 on <br /> Linux. If we don't get the right fix out, distributors will find their <br /> own way to ship 3.4.1 to the detriment of our users and against our own <br /> interests.</blockquote><br /><br />We can work with distros to make sure they apply the correct fix until<br />we can get them into a release.<br /><br />It's just too late for these to go into 3.4.1. The code has already<br />been validated and is ready to be released. However, I have no problem with<br />doing a 3.4.2 release with these patches. Pushing these off to the next<br />release will also give us a chance to fully test LLVM 3.4 with gcc 4.9,<br />so we will be able to include other fixes as necessary.<br /><br />-Tom<br /><br /><block!
quote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792</a> - clang-3.4: <br /> unusable with libstdc++ from gcc 4.9<br /> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872</a> - once <br /> gcc-4.9 and g++-4.9 are installed, clang stops properly building <br /> existing projects<br /> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1092622">https://bugzilla.redhat.com/show_bug.cgi?id=1092622</a> - clang-3.4: <br /> unusable with libstdc++ from gcc 4.9<br /> <br /> Alp.<br /> <br /> -- <br /> <a href="http://www.nuanti.com">http://www.nuanti.com</a><br /> the browser experts<br /> <br /></blockquote></pre></blockquote></div></body></html>