On 04/05/2014 02:30, Tom Stellard wrote:> On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: >> On 02/05/2014 20:45, Tuncer Ayaz wrote: >>> Bump. >>> >>> Is it really unsupported to build llvm from scratch with gcc 4.9 and >>> libstdc++ 4.9? Should I file a bugzilla ticket instead? >> Obviously LLVM/clang should compile out of the box using the current >> stable GCC version, and failure to do so would be a potential release >> blocker. Please file a PR >> >> Tom, do you know about this issue? >> > Yes, but this would only be considered a release blocker if > the 3.4 release builds successfully with gcc 4.9 and the current 3.4 > branch does not.Ensuring the stable branch works with 4.9 is a good idea because it will be a standard configuration in coming months.> > Has anyone tried the 3.4 release with gcc 4.9? I doubt this was tested > much since LLVM 3.4 was released several months before gcc 4.9.I suspect that pulling in clang header fixes r201729, r202911 and r207606 to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have been having with 3.4: r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER is defined) r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, wint_t}. The changes look safe to merge but I'd like to hear a second opinion from Chandler or Nico. Alp. -- http://www.nuanti.com the browser experts
On Mon, May 05, 2014 at 04:11:12PM +0100, Alp Toker wrote:> > On 04/05/2014 02:30, Tom Stellard wrote: > >On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: > >>On 02/05/2014 20:45, Tuncer Ayaz wrote: > >>>Bump. > >>> > >>>Is it really unsupported to build llvm from scratch with gcc 4.9 and > >>>libstdc++ 4.9? Should I file a bugzilla ticket instead? > >>Obviously LLVM/clang should compile out of the box using the current > >>stable GCC version, and failure to do so would be a potential release > >>blocker. Please file a PR > >> > >>Tom, do you know about this issue? > >> > >Yes, but this would only be considered a release blocker if > >the 3.4 release builds successfully with gcc 4.9 and the current 3.4 > >branch does not. > > Ensuring the stable branch works with 4.9 is a good idea because it > will be a standard configuration in coming months. >I agree, but we are too late in the process to add this for 3.4.1. We have finished testing, and I'm am getting ready to finalize the release. I have no problem doing a 3.4.2 release with these changes, but I would really like to get 3.4.1 out the door. -Tom> > > >Has anyone tried the 3.4 release with gcc 4.9? I doubt this was tested > >much since LLVM 3.4 was released several months before gcc 4.9. > > I suspect that pulling in clang header fixes r201729, r202911 and > r207606 to 3.4.1 will resolve libstdc++ / glibc compatibility issues > people have been having with 3.4: > > r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) > r202911: Headers: Provide an ABI compatible max_align_t when > _MSC_VER is defined) > r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, > ptrdiff_t, wint_t}. > > The changes look safe to merge but I'd like to hear a second opinion > from Chandler or Nico. > > Alp. > > -- > http://www.nuanti.com > the browser experts >
On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com> wrote:> I suspect that pulling in clang header fixes r201729, r202911 and r207606 > to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have > been having with 3.4: > > r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) > r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER is > defined) > r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, > wint_t}. > > The changes look safe to merge but I'd like to hear a second opinion from > Chandler or Nico. >I believe all of these are very safe, but I respect Tom's position here. As he is managing the release, he gets to say "not in this one". If you want someone to approve merging these three patches into any release, Richard Smith is the person to ask IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140505/95815c56/attachment.html>
On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <chandlerc at google.com>wrote:> On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com> wrote: > >> I suspect that pulling in clang header fixes r201729, r202911 and r207606 >> to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have >> been having with 3.4: >> >> r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) >> r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER >> is defined) >> r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, >> wint_t}. >> >> The changes look safe to merge but I'd like to hear a second opinion from >> Chandler or Nico. >> > > I believe all of these are very safe, but I respect Tom's position here. > As he is managing the release, he gets to say "not in this one". If you > want someone to approve merging these three patches into any release, > Richard Smith is the person to ask IMO. >The first two are approved for the branch if Tom wants to take them (and they seem like good fixes to have). Tom: if you take r201729, you will need to also take the corresponding libc++ change, r201843. r207606 hasn't had much time to bake, and fixes a problem that is not a regression, so I'd be hesitant to approve it for 3.4.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140505/7e456011/attachment.html>