clang rejects derived reference argument (just fine with g++) - c++

Why does the following not compile in clang, but compiles just as expected in g++?
#include <valarray>
class Array : public std::valarray<double> {
public:
Array(unsigned i=0) : std::valarray<double>(i) {}
};
int main()
{
Array a(3);
for(int j=0; j<3; ++j) a[j]=j + 1;
std::valarray<double> b = std::exp(a);
}
This example was distilled to bare bones from a much more complicated situation, but the usual experiments show no issues:
After changing:
Array a(3)
to
std::valarray<double> a(3)
the code compiles just fine.
Using
static_cast< std::valarray >(a)
also works fine.
As requested by M.M. in the comments, the clang version is:
> clang++ --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Indeed as pointed out by "Baum mit Augen" if I add
-stdlib=libstdc++
to the compilation arguments it compiles just fine.

Related

Apple's clang can't use <=> with std::tuple

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

Identifying uninitialized pointer

Considering:
my class.h
class MyClass
{
Var* var;
public:
MyClass();
};
my class.cpp
MyClass::MyClass()
{
if(var) {};
}
Is there any compiler, or compiler flag, that will tell me I forgot to initialize var, Var* var = nullptr;?
I tried Microsoft (Visual Studio 2019) and MinGW compilers on Qt Creator (Qt 5.15.2), passing -Wall flag to the compiler and seen nothing telling me about that.
So the above was on Windows. And the following I tried on macOS:
class MyClass
{
int* var;
public:
MyClass();
};
MyClass::MyClass()
{
if(var) {}
}
int main()
{
MyClass a;
return 0;
}
While compiling with
g++ -Wuninitialized main.cpp -o main
and
clang++ -Wuninitialized main.cpp -o main
I see no warning, even with -Wall. Why?
g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang++ --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
With Visual Studio and the Microsoft C++ compiler, I suggest compiling your code at warning level 4 (/W4).
If you are using the IDE, in Solution Explorer right click on your project and select Properties.
Then select C/C++ | General, and choose Warning Level 4, as shown below:
However, testing your case with VS2019, I got this warning message even at warning level 3:
Warning C26495 Variable 'MyClass::var' is uninitialized. Always
initialize a member variable (type.6).

alignof(T) with T=__m512 is not equal to alignof(__m512)

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; }

GCC and Clang differ in static_assert related to __builtin_constant_p

I happen to find that GCC and Clang differ in the compilation of the following code:
struct Foo
{
int mem = 42;
};
int main()
{
constexpr Foo foo;
static_assert(__builtin_constant_p(foo));
return 0;
}
I compile with g++ -std=c++17 and clang++ -std=c++17.
In particular,
g++ g++-9 (Homebrew GCC 9.3.0_1) 9.3.0 compiles, whereas
clang++ Apple clang version 11.0.3 (clang-1103.0.32.62) fails to compile, complaining that
error: static_assert failed due to requirement '__builtin_constant_p(foo)'
static_assert(__builtin_constant_p(foo));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
I didn't find any hint that there should be any difference regarding __builtin_constant_p.
For __builtin_constant_p
GCC says
You can use the built-in function __builtin_constant_p to determine if a value is known to be constant at compile time ...
Clang
says
Clang supports a number of builtin library functions with the same syntax as GCC, including things like __builtin_nan, __builtin_constant_p, __builtin_choose_expr, __builtin_types_compatible_p, __builtin_assume_aligned, __sync_fetch_and_add, etc.
Question: While I know __builtin_constant_p is a compiler extension, which one should be the correct one?
Both are poorly documented so I doubt there is a proper answer to your question.
If you need a workaround: it seems that clang gives up if the argument is not an int.
So this works:
struct Foo
{
int mem = 42;
};
int main()
{
constexpr Foo foo;
static_assert(__builtin_constant_p(foo.mem));
return 0;
}

clang++ crash with template wrapping aligned class

I am seeing a weird crash trying to use a wrapper template class around aligned struct/class. The following program is crashing when compiled with clang, while working properly with both gcc and visual studio.
struct __attribute__( ( aligned( 16 ) ) ) AlignedStruct
{
AlignedStruct( ) { }
float x,y,z,w;
};
template <typename P1> class Wrapper
{
public:
P1 Inner;
};
int main( )
{
Wrapper<AlignedStruct> * t1 = new Wrapper<AlignedStruct>( );
return 1;
}
The crash seems to be while calling AlignedStruct constructor (if I remove it, clang compiled code runs as well).
Can anyone explain what is going on here?
Thanks!
Edit:
The crash occurs with clang 3.4.2 under cygwin32 and cygwin64
and clang 3.4.1 under Ubuntu 14.04 (x32) and Ubuntu 14.10 (x32)
It does not, however, occur when testing with clang 3.4.1 under FreeBSD 10.1 (x32) and OS X Yosemite.
I've tried playing around with compilation flags but I can't seem to be able to make any difference with those, so I am just running clang++ file.cpp