3.4 branch gcc 4.9 build error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

3.4 branch gcc 4.9 build error

Tuncer Ayaz
Using gcc 4.9 to build the llvm 3.4 branch fails with the following error:

llvm[1]: Compiling APFloat.cpp for Release build
[...]
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/cstddef:51:11:
error: no member named 'max_align_t' in the global namespace
  using ::max_align_t;
        ~~^

gcc 4.8.2's caused no such issue, so it must be a change in 4.9.0/cstddef.

To be clear, I have no idea who's at fault (gcc 4.9.0 header or llvm sources),
assuming any code is to be blamed (at all).
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Holger Hoffstätte
On Sun, 27 Apr 2014 16:18:52 +0200, Tuncer Ayaz wrote:

> Using gcc 4.9 to build the llvm 3.4 branch fails with the following error:
>
> llvm[1]: Compiling APFloat.cpp for Release build
> [...]
> /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/cstddef:51:11:
> error: no member named 'max_align_t' in the global namespace
>   using ::max_align_t;
>         ~~^
>
> gcc 4.8.2's caused no such issue, so it must be a change in 4.9.0/cstddef.
>
> To be clear, I have no idea who's at fault (gcc 4.9.0 header or llvm sources),
> assuming any code is to be blamed (at all).

Explained under "Header <cstddef> changes" in:
http://gcc.gnu.org/gcc-4.9/porting_to.html

-h

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
On 4/27/14, Holger Hoffstätte wrote:

> On Sun, 27 Apr 2014 16:18:52 +0200, Tuncer Ayaz wrote:
>
> > Using gcc 4.9 to build the llvm 3.4 branch fails with the
> > following error:
> >
> > llvm[1]: Compiling APFloat.cpp for Release build
> > [...]
> > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > error: no member named 'max_align_t' in the global namespace
> >   using ::max_align_t;
> >         ~~^
> >
> > gcc 4.8.2's caused no such issue, so it must be a change in
> > 4.9.0/cstddef.
> >
> > To be clear, I have no idea who's at fault (gcc 4.9.0 header or
> > llvm sources), assuming any code is to be blamed (at all).
>
> Explained under "Header <cstddef> changes" in:
> http://gcc.gnu.org/gcc-4.9/porting_to.html

Thanks for the pointer.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
In reply to this post by Tuncer Ayaz
On 4/27/14, Markus Trippelsdorf wrote:

> On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote:
> > Using gcc 4.9 to build the llvm 3.4 branch fails with the
> > following error:
> >
> > llvm[1]: Compiling APFloat.cpp for Release build
> > [...]
> > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > error: no member named 'max_align_t' in the global namespace
> >   using ::max_align_t;
> >         ~~^
> >
> > gcc 4.8.2's caused no such issue, so it must be a change in
> > 4.9.0/cstddef.
> >
> > To be clear, I have no idea who's at fault (gcc 4.9.0 header or
> > llvm sources), assuming any code is to be blamed (at all).
>
> You can simply wrap it with #ifndef:
>
>  namespace std
>  {
>    // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
> #ifndef __clang__
>    using ::max_align_t;
> #endif
>  }
>  #endif

Yeah, but are you sure the bug is in libstdc++ and has to be fixed in
gcc upstream? I mean, would it be the wrong choice to include a fix in
the next llvm 3.4 release?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
On 4/29/14, Markus Trippelsdorf wrote:

> On 2014.04.29 at 11:04 +0200, Tuncer Ayaz wrote:
> > On 4/27/14, Markus Trippelsdorf wrote:
> > > On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote:
> > > > Using gcc 4.9 to build the llvm 3.4 branch fails with the
> > > > following error:
> > > >
> > > > llvm[1]: Compiling APFloat.cpp for Release build
> > > > [...]
> > > > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > > > error: no member named 'max_align_t' in the global namespace
> > > >   using ::max_align_t;
> > > >         ~~^
> > > >
> > > > gcc 4.8.2's caused no such issue, so it must be a change in
> > > > 4.9.0/cstddef.
> > > >
> > > > To be clear, I have no idea who's at fault (gcc 4.9.0 header
> > > > or llvm sources), assuming any code is to be blamed (at all).
> > >
> > > You can simply wrap it with #ifndef:
> > >
> > >  namespace std
> > >  {
> > >    // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
> > > #ifndef __clang__
> > >    using ::max_align_t;
> > > #endif
> > >  }
> > >  #endif
> >
> > Yeah, but are you sure the bug is in libstdc++ and has to be fixed
> > in gcc upstream? I mean, would it be the wrong choice to include a
> > fix in the next llvm 3.4 release?
>
> One could argue that nothing needs to fixed. The libstdc++
> developers don't care very much about clang interoperability. The
> clang developers don't care about libstdc++ issues.
> Just use libc++ with clang and you're set.

Maybe I wasn't clear, but the issue is building (bootstrapping) llvm
on a system with gcc-4.9 as the host compiler. Are you suggesting that
to build llvm with libstdc++-4.9 I should first build libc++ with
gcc-4.9, and use that lib (instead) when building llvm? Is that even
possible?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
On 4/29/14, Markus Trippelsdorf wrote:

> On 2014.04.29 at 12:16 +0200, Tuncer Ayaz wrote:
> > On 4/29/14, Markus Trippelsdorf wrote:
> > > On 2014.04.29 at 11:04 +0200, Tuncer Ayaz wrote:
> > > > On 4/27/14, Markus Trippelsdorf wrote:
> > > > > On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote:
> > > > > > Using gcc 4.9 to build the llvm 3.4 branch fails with the
> > > > > > following error:
> > > > > >
> > > > > > llvm[1]: Compiling APFloat.cpp for Release build
> > > > > > [...]
> > > > > > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > > > > > error: no member named 'max_align_t' in the global namespace
> > > > > >   using ::max_align_t;
> > > > > >         ~~^
> > > > > >
> > > > > > gcc 4.8.2's caused no such issue, so it must be a change
> > > > > > in 4.9.0/cstddef.
> > > > > >
> > > > > > To be clear, I have no idea who's at fault (gcc 4.9.0
> > > > > > header or llvm sources), assuming any code is to be blamed
> > > > > > (at all).
> > > > >
> > > > > You can simply wrap it with #ifndef:
> > > > >
> > > > >  namespace std
> > > > >  {
> > > > >    // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
> > > > > #ifndef __clang__
> > > > >    using ::max_align_t;
> > > > > #endif
> > > > >  }
> > > > >  #endif
> > > >
> > > > Yeah, but are you sure the bug is in libstdc++ and has to be
> > > > fixed in gcc upstream? I mean, would it be the wrong choice to
> > > > include a fix in the next llvm 3.4 release?
> > >
> > > One could argue that nothing needs to fixed. The libstdc++
> > > developers don't care very much about clang interoperability.
> > > The clang developers don't care about libstdc++ issues. Just use
> > > libc++ with clang and you're set.
> >
> > Maybe I wasn't clear, but the issue is building (bootstrapping)
> > llvm on a system with gcc-4.9 as the host compiler. Are you
> > suggesting that to build llvm with libstdc++-4.9 I should first
> > build libc++ with gcc-4.9, and use that lib (instead) when
> > building llvm? Is that even possible?
>
> No. During bootstrap you'll have to patch libstdc++. You can build
> and use libc++ after that.

Okay, but isn't that impractical for repeated builds?

If this is the official way to build llvm on a system with gcc-4.9 as
the host CXX, it's probably best to document it.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
On 4/29/14, Tuncer Ayaz wrote:

> On 4/29/14, Markus Trippelsdorf wrote:
> > On 2014.04.29 at 12:16 +0200, Tuncer Ayaz wrote:
> > > On 4/29/14, Markus Trippelsdorf wrote:
> > > > On 2014.04.29 at 11:04 +0200, Tuncer Ayaz wrote:
> > > > > On 4/27/14, Markus Trippelsdorf wrote:
> > > > > > On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote:
> > > > > > > Using gcc 4.9 to build the llvm 3.4 branch fails with
> > > > > > > the following error:
> > > > > > >
> > > > > > > llvm[1]: Compiling APFloat.cpp for Release build
> > > > > > > [...]
> > > > > > > /usr/[...]/include/c++/4.9.0/cstddef:51:11:
> > > > > > > error: no member named 'max_align_t' in the global namespace
> > > > > > >   using ::max_align_t;
> > > > > > >         ~~^
> > > > > > >
> > > > > > > gcc 4.8.2's caused no such issue, so it must be a change
> > > > > > > in 4.9.0/cstddef.
> > > > > > >
> > > > > > > To be clear, I have no idea who's at fault (gcc 4.9.0
> > > > > > > header or llvm sources), assuming any code is to be
> > > > > > > blamed (at all).
> > > > > >
> > > > > > You can simply wrap it with #ifndef:
> > > > > >
> > > > > >  namespace std
> > > > > >  {
> > > > > >    // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
> > > > > > #ifndef __clang__
> > > > > >    using ::max_align_t;
> > > > > > #endif
> > > > > >  }
> > > > > >  #endif
> > > > >
> > > > > Yeah, but are you sure the bug is in libstdc++ and has to be
> > > > > fixed in gcc upstream? I mean, would it be the wrong choice
> > > > > to include a fix in the next llvm 3.4 release?
> > > >
> > > > One could argue that nothing needs to fixed. The libstdc++
> > > > developers don't care very much about clang interoperability.
> > > > The clang developers don't care about libstdc++ issues. Just
> > > > use libc++ with clang and you're set.
> > >
> > > Maybe I wasn't clear, but the issue is building (bootstrapping)
> > > llvm on a system with gcc-4.9 as the host compiler. Are you
> > > suggesting that to build llvm with libstdc++-4.9 I should first
> > > build libc++ with gcc-4.9, and use that lib (instead) when
> > > building llvm? Is that even possible?
> >
> > No. During bootstrap you'll have to patch libstdc++. You can build
> > and use libc++ after that.
>
> Okay, but isn't that impractical for repeated builds?
>
> If this is the official way to build llvm on a system with gcc-4.9
> as the host CXX, it's probably best to document it.

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?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Alp Toker

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?

Alp.

--
http://www.nuanti.com
the browser experts

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tom Stellard-3
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.

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.

-Tom
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Alp Toker

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tom Stellard-3
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
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Chandler Carruth-2
In reply to this post by Alp Toker

On Mon, May 5, 2014 at 8:11 AM, Alp Toker <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Richard Smith-33
On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <[hidden email]> wrote:
On Mon, May 5, 2014 at 8:11 AM, Alp Toker <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Alp Toker

On 05/05/2014 20:51, Richard Smith wrote:

> On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On Mon, May 5, 2014 at 8:11 AM, Alp Toker <[hidden email]
>     <mailto:[hidden email]>> 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.

Thanks for pointing that out Richard. r201729 + r201843 sounds good.

I'm concerned that advice has already appeared online instructing users
to patch their libstdc++ system headers in order to install clang 3.4 on
Linux. If we don't get the right fix out, distributors will find their
own way to ship 3.4.1 to the detriment of our users and against our own
interests.

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792 - clang-3.4:
unusable with libstdc++ from gcc 4.9
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872 - once
gcc-4.9 and g++-4.9 are installed, clang stops properly building
existing projects
   https://bugzilla.redhat.com/show_bug.cgi?id=1092622 - clang-3.4:
unusable with libstdc++ from gcc 4.9

Alp.

--
http://www.nuanti.com
the browser experts

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tom Stellard-3
On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote:

>
> On 05/05/2014 20:51, Richard Smith wrote:
> > On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth
> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> >     On Mon, May 5, 2014 at 8:11 AM, Alp Toker <[hidden email]
> >     <mailto:[hidden email]>> 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.
>
> Thanks for pointing that out Richard. r201729 + r201843 sounds good.
>
> I'm concerned that advice has already appeared online instructing users
> to patch their libstdc++ system headers in order to install clang 3.4 on
> Linux. If we don't get the right fix out, distributors will find their
> own way to ship 3.4.1 to the detriment of our users and against our own
> interests.
>

We can work with distros to make sure they apply the correct fix until
we can get them into a release.

It's just too late for these to go into 3.4.1.  The code has already
been validated and is ready to be released.  However, I have no problem with
doing a 3.4.2 release with these patches.  Pushing these off to the next
release will also give us a chance to fully test LLVM 3.4 with gcc 4.9,
so we will be able to include other fixes as necessary.

-Tom

>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792 - clang-3.4:
> unusable with libstdc++ from gcc 4.9
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872 - once
> gcc-4.9 and g++-4.9 are installed, clang stops properly building
> existing projects
>    https://bugzilla.redhat.com/show_bug.cgi?id=1092622 - clang-3.4:
> unusable with libstdc++ from gcc 4.9
>
> Alp.
>
> --
> http://www.nuanti.com
> the browser experts
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Alp Toker
Thanks Tom,

That sounds great. Good luck with the release

Alp.


On 6 May 2014 16:21:19 BST, Tom Stellard <[hidden email]> wrote:
On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote:

On 05/05/2014 20:51, Richard Smith wrote:
On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth
<[hidden email] <mailto:[hidden email]>> wrote:

On Mon, May 5, 2014 at 8:11 AM, Alp Toker <[hidden email]
<mailto:[hidden email]>> 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 ap! prove it for 3.4.1.

Thanks for pointing that out Richard. r201729 + r201843 sounds good.

I'm concerned that advice has already appeared online instructing users
to patch their libstdc++ system headers in order to install clang 3.4 on
Linux. If we don't get the right fix out, distributors will find their
own way to ship 3.4.1 to the detriment of our users and against our own
interests.


We can work with distros to make sure they apply the correct fix until
we can get them into a release.

It's just too late for these to go into 3.4.1. The code has already
been validated and is ready to be released. However, I have no problem with
doing a 3.4.2 release with these patches. Pushing these off to the next
release will also give us a chance to fully test LLVM 3.4 with gcc 4.9,
so we will be able to include other fixes as necessary.

-Tom

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792 - clang-3.4:
unusable with libstdc++ from gcc 4.9
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872 - once
gcc-4.9 and g++-4.9 are installed, clang stops properly building
existing projects
https://bugzilla.redhat.com/show_bug.cgi?id=1092622 - clang-3.4:
unusable with libstdc++ from gcc 4.9

Alp.

--
http://www.nuanti.com
the browser experts


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
Tom,

now that 3.4.1 is out, any chance of a 3.4.2 with just the
three fixes or at least merging them to the 3.4 branch?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Renato Golin-2
On 10 May 2014 22:48, Tuncer Ayaz <[hidden email]> wrote:
> now that 3.4.1 is out, any chance of a 3.4.2 with just the
> three fixes or at least merging them to the 3.4 branch?

Will we need to make sure we test it with 4.9 too as well as 4.8/4.7?
Or is this just a high-level bug that, if it's fixed in one arch, it's
fixed in all?

--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tom Stellard-3
In reply to this post by Tuncer Ayaz
On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote:
> Tom,
>
> now that 3.4.1 is out, any chance of a 3.4.2 with just the
> three fixes or at least merging them to the 3.4 branch?

I've pushed the two approved patches to the 3.4 branch, can you verify
that they work with gcc 4.9.

Thanks,
Tom
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 branch gcc 4.9 build error

Tuncer Ayaz
On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote:

> On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote:
> > Tom,
> >
> > now that 3.4.1 is out, any chance of a 3.4.2 with just the three
> > fixes or at least merging them to the 3.4 branch?
>
> I've pushed the two approved patches to the 3.4 branch, can you
> verify that they work with gcc 4.9.

Thanks, Tom.

Fresh (svn rev 208853) checkout of llvm, clang, etc:

llvm[1]: Compiling APFloat.cpp for Release build
In file included from APFloat.cpp:15:
In file included from /tmp/llvm/include/llvm/ADT/APFloat.h:20:
In file included from /tmp/llvm/include/llvm/ADT/APInt.h:19:
In file included from /tmp/llvm/include/llvm/ADT/ArrayRef.h:14:
In file included from /tmp/llvm/include/llvm/ADT/SmallVector.h:17:
In file included from /tmp/llvm/include/llvm/Support/AlignOf.h:19:
/usr/lib64/[...]/c++/4.9.0/cstddef:51:11: error:
      no member named 'max_align_t' in the global namespace
  using ::max_align_t;
        ~~^
1 error generated.

As the fixes got merged to the release_34 branch, I went to check the
local configure options and noticed I was passing --enable-cxx11. If I
omit that, there's no max_align_t error. I don't remember when I added
that, but it used to build prior to gcc 4.9. Just so I understand, is
that flag meant to be enabled (and known to work) when llvm is built
by clang, or is that also in need of fixing for gcc 4.9?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12