clang-3.5 fails to compile C++11 files after installing gcc-4.9

[RJVB]

After installing gcc-4.9 from http://ppa.launchpad.net/ubuntu-toolchain-r, clang-3.5 (from local/universe) fails to compile certain C++11 files because of a header-file confusion and missing symbol:

In file included from /home/bertin/work/src/Scratch/KDE/kdevelop/kdevplatform-git/plugins/classbrowser/classmodel.cpp:25:
In file included from /home/bertin/work/src/Scratch/KDE/kdevelop/kdevplatform-git/plugins/classbrowser/allclassesfolder.h:25:
In file included from /home/bertin/work/src/Scratch/KDE/kdevelop/kdevplatform-git/plugins/classbrowser/documentclassesfolder.h:26:
In file included from /usr/include/boost/multi_index_container.hpp:18:
In file included from /usr/include/boost/config.hpp:40:
In file included from /usr/include/boost/config/select_stdlib_config.hpp:18:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/cstddef:51:11: error: no member named
      'max_align_t' in the global namespace
  using ::max_align_t;
        ~~^
1 error generated.

This is in fact a known issue in clang: cf. https://bbs.archlinux.org/viewtopic.php?pid=1412567 and https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/llvm&id=4e73667cd27e34f8268fc29e4e524b51687333ca

It was addressed in clang/llvm revision rL201729 : http://reviews.llvm.org/rL201729 .

Please update the clang-3.5 package to at least that revision.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: clang-3.5 1:3.5~svn201651-1ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-39.66-ConKolivas-AMDFam10 3.13.11.8
Uname: Linux 3.13.11.8-ck1-kubuntu-amdf10-rjvb x86_64
NonfreeKernelModules: ufsd zfs zunicode zavl zcommon znvpair
ApportVersion: 2.14.2-0ubuntu3
Architecture: amd64
Date: Wed Dec 10 18:53:38 2014
InstallationDate: Installed on 2014-05-03 (221 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1)
SourcePackage: llvm-toolchain-snapshot
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[DaanS (daanschulpen)]

Is this a regression introduced in Ubuntu?

The SVN sources for clang 3.5.0 and 3.5.1 both contain the fix introduced in rL201729.

This bug seriously limits the usefulness of clang 3.5 on Ubuntu, as it also suffers from a serious bug in libstdc++-4.8 (see, for example, http://lists.cs.uiuc.edu/pipermail/llvmbugs/2014-January/032040.html). At this point, the following appear to be impossible on Ubuntu 14.04:
 - Using clang++ in c++11 mode to compile (anything including) cstdio from gcc-4.8.
 - Using clang++ in c++11 mode to compile (anything including) cstddef from gcc-4.9.
 - Using clang++ in c++11 mode to compile (anything including) both cstdio and cstddef from *any* gcc.

A good example of a project in the last category is clang itself: it requires c++11 mode, cstdio and cstddef.

[Sylvestre Ledru (sylvestre)]

I think it is a caused by a change of path in gcc.
I had several issues like that in the past.

Patches are welcome!

[RJVB (rjvbertin)]

Not a regression in Ubuntu, unless if you consider "standstill = regression".

As noted by Daan above, all is needed is to update llvm to a more recent version, like Debian have done in Jessie/Sid.

Backported to 14.04: ppa:rjvbertin/llvm

[DaanS (daanschulpen)]

I'm not sure how a change of path in gcc could cause this issue. clang++ *should* provide ::max_align_t itself in c++11 mode.

http://reviews.llvm.org/file/data/sw37fgtbupwhetydgazl/PHID-FILE-wprxzvc5yn4ylp7xwt6t/201729.diff:
+#if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L
+typedef struct {
+ long long __clang_max_align_nonce1
+ __attribute__((__aligned__(__alignof__(long long))));
+ long double __clang_max_align_nonce2
+ __attribute__((__aligned__(__alignof__(long double))));
+} max_align_t;
+#define __CLANG_MAX_ALIGN_T_DEFINED
+#endif
+

I've personally verified that this fix is included in the upstream tag RELEASE_350/final.

[DaanS (daanschulpen)]

Minor update:
Somewhere between rL201729 and RELEASE_350/final, the fix was changed to:
#if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L
#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) || __has_feature(modules)
#ifndef _MSC_VER
typedef struct {
  long long __clang_max_align_nonce1
      __attribute__((__aligned__(__alignof__(long long))));
  long double __clang_max_align_nonce2
      __attribute__((__aligned__(__alignof__(long double))));
} max_align_t;
#else
typedef double max_align_t;
#endif
#define __CLANG_MAX_ALIGN_T_DEFINED ...

[RJVB (rjvbertin)]

On Thursday January 15 2015 16:10:18 DaanS wrote:
> Minor update:
> Somewhere between rL201729 and RELEASE_350/final, the fix was changed to:
> #if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L
> #if !defined(__CLANG_MAX_ALIGN_T_DEFINED) || __has_feature(modules)
> #ifndef _MSC_VER
> typedef struct {
> long long __clang_max_align_nonce1
> __attribute__((__aligned__(__alignof__(long long))));
> long double __clang_max_align_nonce2
> __attribute__((__aligned__(__alignof__(long double))));
> } max_align_t;
> #else
> typedef double max_align_t;
> #endif
> #define __CLANG_MAX_ALIGN_T_DEFINED ...

[Sylvestre Ledru (sylvestre)]

On 15/01/2015 17:23, RJVB wrote:
> On Thursday January 15 2015 16:10:18 DaanS wrote:
>> Minor update:
>> Somewhere between rL201729 and RELEASE_350/final, the fix was changed to:
>> #if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L
>> #if !defined(__CLANG_MAX_ALIGN_T_DEFINED) || __has_feature(modules)
>> #ifndef _MSC_VER
>> typedef struct {
>> long long __clang_max_align_nonce1
>> __attribute__((__aligned__(__alignof__(long long))));
>> long double __clang_max_align_nonce2
>> __attribute__((__aligned__(__alignof__(long double))));
>> } max_align_t;
>> #else
>> typedef double max_align_t;
>> #endif
>> #define __CLANG_MAX_ALIGN_T_DEFINED ...

[DaanS (daanschulpen)]

I've verified that the upstream binary distribution (http://llvm.org/releases/3.5.0/clang+llvm-3.5.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz) is *not* affected by this bug.

@RJVB: all I know is that rL201729 was considered for inclusion in clang-3.4.1, which I believe predates 3.5.0. But I'm not intimately familiar with the branching/merging process of clang, so I cannot be sure about this.

[RJVB (rjvbertin)]

On Thursday January 15 2015 16:45:56 DaanS wrote:
> I've verified that the upstream binary distribution
> (http://llvm.org/releases/3.5.0/clang+llvm-3.5.0-x86_64-linux-gnu-
> ubuntu-14.04.tar.xz) is *not* affected by this bug.

That would make sense, presuming it's based on 3.5.0 final, and not on a pre-release as the official Ubuntu appears to be.

R.