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

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

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.

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!

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

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.

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

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

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

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.

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.