[LLVMdev] 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
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[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

[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.

[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?

[Tuncer Ayaz]

On 4/29/14, Markus Trippelsdorf wrote:

> 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?

[Tuncer Ayaz]

On 4/29/14, Markus Trippelsdorf wrote:

> 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.

[Tuncer Ayaz]

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?

[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

[Tom Stellard]

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

[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

[Tom Stellard]

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

[Chandler Carruth]

On Mon, May 5, 2014 at 8:11 AM, Alp Toker <a...@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.

[Richard Smith]

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.

[Alp Toker]

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

[Tom Stellard]

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

[Alp Toker]

Thanks Tom,

That sounds great. Good luck with the release

Alp.

On 6 May 2014 16:21:19 BST, Tom Stellard <t...@stellard.net> 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 
 <chan...@google.com <mailto:chan...@google.com>> wrote:

     On Mon, May 5, 2014 at 8:11 AM, Alp Toker <a...@nuanti.com
     <mailto:a...@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 ap!
 prove it
for 3.4.1.

[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?

[Renato Golin]

On 10 May 2014 22:48, Tuncer Ayaz <tunce...@gmail.com> 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

[Tom Stellard]

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

[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?

[Tom Stellard]

On Thu, May 15, 2014 at 01:38:32PM +0200, Tuncer Ayaz wrote:
> 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.
>

Is this trunk or the 3.4 branch?

> 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?

So clang/llvm will only fail to build with gcc 4.9 if the --enable-cxx11 flag is used?

-Tom

[Tuncer Ayaz]

On 5/15/14, Tom Stellard wrote:
> On Thu, May 15, 2014 at 01:38:32PM +0200, Tuncer Ayaz wrote:
> > 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.
> >
>
> Is this trunk or the 3.4 branch?

release_34

> > 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?
>
> So clang/llvm will only fail to build with gcc 4.9 if the --enable-cxx11
> flag is used?

Yes.

[Tuncer Ayaz]

On 5/15/14, Tuncer Ayaz wrote:

> release_34

To be precise:
http://llvm.org/svn/llvm-project/llvm/branches/release_34

[Alp Toker]

The underlying problem was that, without the fix, clang's C++11 mode
didn't work *at all* with system headers shipped by GCC 4.9.

So the failure to self-host with --enable-cxx11 mentioned by Tuncer is
really only a secondary symptom of the wider problem reported by
distributions.

Alp.

>
> -Tom
> _______________________________________________
> LLVM Developers mailing list
> LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

[Tom Stellard]

So does this mean there is an additional fix that is required for the 3.4 branch?

-Tom

[Alp Toker]

Nope, the two proposed patches should resolve the underlying issue just
fine as well as the self-host problem.

Just writing to characterise the problem, which is slightly different to
the OP's description.

Alp.

[Tuncer Ayaz]

On 5/15/14, Alp Toker wrote:

> Nope, the two proposed patches should resolve the underlying issue
> just fine as well as the self-host problem.
>
> Just writing to characterise the problem, which is slightly
> different to the OP's description.

Is --enable-cxx11 only meant to be used for building llvm with clang?

[Alp Toker]

On 15/05/2014 23:02, Tuncer Ayaz wrote:
> On 5/15/14, Alp Toker wrote:
>
>> Nope, the two proposed patches should resolve the underlying issue
>> just fine as well as the self-host problem.
>>
>> Just writing to characterise the problem, which is slightly
>> different to the OP's description.
> Is --enable-cxx11 only meant to be used for building llvm with clang?

In the 3.4 series it was supported when building llvm using any of GCC,
clang or MSVC, but was optional unless building lld, in which case it
was mandatory IIRC.

Alp.

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