The following compiles fine with GCC and clang on on godbolt, but on my MacBook, in Xcode 14 it dies:
#include <iostream>
#include <compare>
#include <tuple>
using std::cout; using std::tuple; using std::endl;
int main() {
tuple<float, float> tuplee = {1.0,2.0};
tuple<float, float> tuploo = {3.0,4.0};
cout << (tuplee < tuploo) << endl;
auto res = (tuplee <=> tuploo);
cout << (res < 0) << endl;
return 0;
}
The error is:
invalid operands to binary expression ('std::tuple<float, float>' and 'std::tuple<float, float>')
It points to the <=> on the tuples. Do you think it's a bug in Apple's clang, or am I missing something?
Command line on my MacBook:
% clang++ --version
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% clang++ -std=c++2b main.cpp
main.cpp:11:21: error: invalid operands to binary expression ('tuple<float, float>' and 'tuple<float, float>')
cout << (tuplee <=> tuploo) << endl;
~~~~~~ ^ ~~~~~~
1 error generated.
I think it is a bug. The bug was fixed in llvm (relevant change). But by checking the tuple header in Macos SDK, one can find apple do not implement <=> for tuple.
The bug also affects arm64 variants of Macos. Clang version on my mac:
➜ test clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
PS. Homebrew llvm#14 compiles fine. Just do not use apple clang
Related
I ran into a strange situation that alignof(__m512) is not equal to std::alignment_of<__m512>::value compiled by Apple's clang. After some testing I found that when alignof(T) is evaluated inside a template with T=__m512, the result is different with direct alignof(__m512).
I also ran several test compiled by g++ and non-Apple's clang on ubuntu(WSL) and got correct(I thought) behavior.
Is this a bug of Apple's clang or an issue about implemented behavior?
#include <immintrin.h> //avx headers
#include <cstdio>
#include <typeinfo>
#include <type_traits>
void test_directly() {
printf("directly: typeid %s alignof %zu\n", typeid(__m512).name(), alignof(__m512));
}
template<typename T>
void test_as_template_argument() {
static_assert(std::is_same<T, __m512>::value, "assert");
printf("template: typeid %s alignof %zu\n", typeid(T).name(), alignof(T));
}
int main() {
test_directly();
test_as_template_argument<__m512>();
return 0;
}
output(compiled with clang++ -std=c++17 -march=native):
directly: typeid Dv16_f alignof 64
template: typeid Dv16_f alignof 32
clang's version:
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
macOS's version: macOS Catalina 10.15.4 (19E2269) Darwin 19.4.0
This appears to be a bug. You can get the desired behavior by wrapping __m512 in a struct like this:
struct X { __m512 m; }
The following code
#include <iostream>
#include <tuple>
int main()
{
auto [i, c, d] = std::make_tuple(1, 'a', 2.3);
std::cout << "i=" << i << " c=" << c << " d=" << d << '\n';
return 0;
}
doesn't get compiled on my computer. I get these error messages:
error: use of undeclared identifier 'i'
error: expected unqualified-id
and some more of the same type.
I'm using: Mac OS X 10.11.6 El Capitan, CLion. I did choose the C++ 17 option when I created the project and my CMakeList.txt has this line:set(CMAKE_CXX_STANDARD 17).
clang --version - Apple LLVM version 8.0.0 (clang-800.0.42.1)
What do I need to do to compile this code?
As #Eljay said in the comments, older versions of clang did (do) not have complete C++17 support.
I have reproduced this issue w/o CLion.
On a 10.11.6 machine, using "Apple LLVM version 8.0.0 (clang-800.0.42.1)"
clang++ -std=c++1z junk.cpp
gives the errors that the OP reported. (Note that -std=c++17 is not a valid option here - that came later)
On a 10.14.2 machine, using "Apple LLVM version 10.0.0 (clang-1000.10.44.4)"
clang++ -std=c++17 junk.cpp
compiles w/o error.
I assume C++ Compound type alterations support should be enabled in clang++ by -std=c++11 switch. But I'm unable to compile this code using clang:
#include <iostream>
#include <type_traits>
enum class A {a,b,c};
enum B : short {x,y,z};
int main() {
typedef std::underlying_type<A>::type A_under; // int
typedef std::underlying_type<B>::type B_under; // short
std::cout << std::boolalpha;
std::cout << "typedefs of int:" << std::endl;
std::cout << "A_under: " << std::is_same<int,A_under>::value << std::endl;
std::cout << "B_under: " << std::is_same<int,B_under>::value << std::endl;
return 0;
}
I get this error:
$ clang++ underlyingtype.cpp -std=c++11
underlyingtype.cpp:10:16: error: no type named 'underlying_type' in namespace 'std'
typedef std::underlying_type<A>::type A_under; // int
Any idea why this is happening?
Further information:
lashgar#fengdu:~/code$ clang++ --version
clang version 3.8.0 (http://llvm.org/git/clang.git 1ad799453a2e54cfded555a03fd58dbd102c5f62) (http://llvm.org/git/llvm.git af5ff60200812e518c72a022fb4c66b9a5f0116a)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/lashgar/opt/llvm/bin
Here's a link to an online compiler with libstdc++ 4.6.4 that reproduces this error.
Just make sure to get the version of your Standard Library. libstdc++ 4.7 and higher or libc++ 3.0 and higher should work correctly.
When compiling the following code:
#include <iostream>
#include <thread>
using namespace std;
void hello()
{
cout << "Hello World!" << endl;
}
int main()
{
cout << "starting" << endl;
thread t(hello);
t.join();
cout << "ending" << endl;
return 0;
}
using:
$ g++-4.6.1 -std=c++0x -pthread threading.cpp
I get the following error:
threading.cc: In function ‘int main()’:
threading.cc:13:2: error: ‘thread’ was not declared in this scope
threading.cc:13:9: error: expected ‘;’ before ‘t’
threading.cc:14:2: error: ‘t’ was not declared in this scope
This is on MacOSX Lion with a custom built gcc 4.6.1. All the other c++0x features that are valid for gcc 4.6 works like a charm. Is this a MacOSX specific error?
std::thread (and the rest of the C++11 thread library) is only available for some of the platforms supported by gcc 4.6.1. Unfortunately for you, MacOSX is not one of those platforms.
My commercial Just::Thread library provides the C++11 thread facilities for 32-bit MacOSX with gcc 4.5, but gcc 4.6 is not supported yet.
See http://gcc.gnu.org/PR50196 - Mac OS X doesn't support some parts of pthreads that we rely on. Building the latest version won't help, but it might be fixed for GCC 4.7
I've reduced my code to the following to illustrate my problem:
#include <iostream>
#include <stack>
#include <utility>
std::pair<double,double> test(double a, double b)
{
std::stack<int> my_stack;
return std::make_pair<double,double>(a,b);
}
int main()
{
std::pair<double,double> p = test(1.1,2.2);
std::cout << p.first << " " << p.second << "\n";
return 0;
}
The return value from the test() function gets corrupted when I use the gcc -O1 flag. Here is some sample output:
$ gcc -O2 a.cxx -lstdc++
$ ./a.out
1.1 2.2
$ gcc -O1 a.cxx -lstdc++
$ ./a.out
2.60831e-317 2.60657e-317
$ gcc -v
Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local- prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix
gcc version 3.3.3 (SuSE Linux)
This code works with all gcc optimazation flags except "-O1". It also works if I remove the declaration of my_stack. Would you classify this as a compiler bug, or am I missing something about std::stack and returning std::pair values?
Definitely a compiler bug.
BTW it is not reproduced with my GCC version (4.4.5).
The version of GCC 3.3.3 shipped with SuSE 9.1 is known to be broken (see here).
It's a bug. Check if the bug has been reported, if not, report it.