Bug 824406 - clang++ chokes on <complex>
clang++ chokes on <complex>
Status: CLOSED DUPLICATE of bug 845713
Product: Fedora
Classification: Fedora
Component: llvm (Show other bugs)
17
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michel Alexandre Salim
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-23 08:12 EDT by Neal Becker
Modified: 2013-01-23 19:33 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-23 19:33:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neal Becker 2012-05-23 08:12:26 EDT
Description of problem:

Just trying out clang++.  Doesn't seem to be useful on f17.  Just include <complex> gives:

In file included from .sconf_temp/conftest_0.cpp:2:
In file included from /usr/include/eigen3/Eigen/Core:149:
In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/complex:46:
In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/sstream:38:
In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/istream:39:
In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from /bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45: error: use of undeclared identifier '__ATOMIC_ACQ_REL'
  { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
                                            ^
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38: error: use of undeclared identifier '__ATOMIC_ACQ_REL'
  { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
                                     ^
In file included from .sconf_temp/conftest_0.cpp:2:
In file included from /usr/include/eigen3/Eigen/Core:155:
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27: error: use of undeclared identifier '__int128'; did you mean '__int128_t'?
    struct numeric_limits<__int128>
                          ^
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:36: error: expected '>'
    struct numeric_limits<unsigned __int128>
                                   ^
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:5: error: cannot combine with previous '(error)' declaration specifier
    struct numeric_limits<unsigned __int128>
    ^
/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:44: error: expected unqualified-id
    struct numeric_limits<unsigned __int128>
                                           ^
6 errors generated.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Michel Alexandre Salim 2012-05-24 11:39:54 EDT
Hi Neil,

This is a known problem -- upstream fixed it rather late in the 3.1 development series, so it's not straightforward to backport the fix to the 3.0 we ship in Fedora 17.

I'm working on packaging LLVM/Clang 3.1 for Rawhide -- will try and sort out some of the directory layout issues at the same time. I'll ask around on the mailing list if we can push this to the stable branches too, if the key packages depending on LLVM (e.g. mesa) builds fine with 3.1.
Comment 2 Andrea 2012-06-21 04:50:14 EDT
I get the same issue.
Seems that every C++ program using the STL cannot compile.

This makes clang for C++ totally useless.

can a user decide to move to clang 3.1, even if Fedora does not want to upgrade clang during a release?

On my machine llvm & clang do not trigger any extra dependency, so it should be pretty riskless.
Comment 3 Andrea 2012-06-21 05:08:53 EDT
OK, I should have checked more.

Here,
llvm-libs-3.0 is only required by

mesa-dri-drivers.

Would it make sense to take them both from Rawhide? Or I go in an endless loop?
Comment 4 Kevin Kofler 2012-07-11 11:57:59 EDT
I think this really needs to be fixed, either by backporting the fix(es) or by just upgrading LLVM.
Comment 5 Yury V. Zaytsev 2013-01-23 11:10:53 EST
This bug is a duplicate of this one:

https://bugzilla.redhat.com/show_bug.cgi?id=845713

Please resolve it, I don't have sufficient privileges.
Comment 6 Kevin Kofler 2013-01-23 19:33:22 EST

*** This bug has been marked as a duplicate of bug 845713 ***

Note You need to log in before you can comment on or make changes to this bug.