This might have another issue with Verilog -

This still misses contexts when string literal is required, for example https://github.com/search?q=repo%3Agoogle%2Fclosure-compiler%20%22%20must%20be%20a%20string%20literal%22&type=code

This introduces an invalid TS transformation, from

type x = 'ab';

to

type x = ('a'+'b');

Is it a known issue, that clang doesn't compile void foo(char *argv[] [[maybe_unused]]) {} ? The error is error: 'maybe_unused' attribute cannot be applied to types.

Heads up - we are seeing test failures that root cause to this revision.

Heads-up - this caused multiple segmentation faults in our code base. We are working on a reproducer.

Here is another interesting bit - from all the failures that I'm seeing, ~70% are not in our internal code but in the open source code we are using (including the LLVM project itself). Fixing those problems in corresponding upstream repositories looks like a significant effort (here is the reason for my rough estimation of 3 weeks).

Okay, we have a significant amount of failures from this, will likely require 2-3 weeks of cleanups.

Saw a number of failures on Google's codebase sample, running more tests to understand the scale better.

Hi Louis,

It looks like std::deque elements do not need to be copy assignable since C++11 (https://en.cppreference.com/w/cpp/container/deque).

This was relanded and caused crashes when compiling numpy for aarch64.

Need a reproducer, unable to investigate the crash without actual repro.

Failing assertion is

assert.h assertion failed at ...llvm/include/llvm/ADT/SmallVector.h:298 in const_reference llvm::SmallVectorTemplateCommon<llvm::Value *>::operator[](size_type) const [T = llvm::Value *]: idx < size()

Heads up: this commits crashes one of our tests, the stack trace is:

...
 #2 0x000055c65640bbd6 CrashRecoverySignalHandler(int) (clang+0x800bbd6)
 #3 0x00007fda88e7b1c0 __restore_rt (/usr/grte/v5/lib64/libpthread.so.0+0x151c0)
 #4 0x000055c655b71964 llvm::slpvectorizer::BoUpSLP::isGatherShuffledEntry(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef<llvm::Value*>, llvm::SmallVectorImpl<int>&, llvm::SmallVectorImpl<llvm::slpvectorizer::BoUpSLP::TreeEntry const*>&) (clang+0x7771964)
 #5 0x000055c655b6c47c llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef<llvm::Value*>) (clang+0x776c47c)
 #6 0x000055c655b74903 llvm::slpvectorizer::BoUpSLP::getTreeCost(llvm::ArrayRef<llvm::Value*>) (clang+0x7774903)
 #7 0x000055c655b8d3a5 llvm::SLPVectorizerPass::tryToVectorizeList(llvm::ArrayRef<llvm::Value*>, llvm::slpvectorizer::BoUpSLP&, bool) (clang+0x778d3a5)
 #8 0x000055c655b92a0a bool tryToVectorizeSequence<llvm::Value>(llvm::SmallVectorImpl<llvm::Value*>&, llvm::function_ref<unsigned int (llvm::Value*)>, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>, llvm::function_ref<bool (llvm::Value*, llvm::Value*)>, llvm::function_ref<bool (llvm::ArrayRef<llvm::Value*>, bool)>, bool) (clang+0x7792a0a)
 #9 0x000055c655b89681 llvm::SLPVectorizerPass::vectorizeChainsInBlock(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (clang+0x7789681)
#10 0x000055c655b87eb5 llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) (clang+0x7787eb5)
#11 0x000055c655b877e6 llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (clang+0x77877e6)
#12 0x000055c654ce1e32 llvm::detail::PassModel<llvm::Function, llvm::SLPVectorizerPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (clang+0x68e1e32)
#13 0x000055c6562b07cb llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (clang+0x7eb07cb)
#14 0x000055c651f02472 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (clang+0x3b02472)
#15 0x000055c6562b2b27 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (clang+0x7eb2b27)
#16 0x000055c651f04512 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (clang+0x3b04512)
#17 0x000055c6562afcab llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (clang+0x7eafcab)
#18 0x000055c651efa03d (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream>>&, std::__u::unique_ptr<llvm::ToolOutputFile, std::__u::default_delete<llvm::ToolOutputFile>>&) (clang+0x3afa03d)
#19 0x000055c651ef2d47 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__u::unique_ptr<llvm::raw_pwrite_stream, std::__u::default_delete<llvm::raw_pwrite_stream>>) (clang+0x3af2d47)
#20 0x000055c651eef4ca clang::CodeGenAction::ExecuteAction() (clang+0x3aef4ca)
#21 0x000055c6529aad5a clang::FrontendAction::Execute() (clang+0x45aad5a)
#22 0x000055c652919a04 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (clang+0x4519a04)
#23 0x000055c651b958ce clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (clang+0x37958ce)
#24 0x000055c651b8a4af cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (clang+0x378a4af)
...

The warning now fires even if overflow is prevented with if constexpr:

Looks like we fail to enter the appropriate context somewhere (my guess is that it might be specific to the attribute but it's hard to say without picking around), definitely a bug

I'll be away the next 2 weeks, I'll look at it when I get back. Maybe we should track it in an issue though.

Looks like our tests fail because ReadFileID doesn't translate file ID as ReadSourceLocation/TranslateSourceLocation do. Please see the prototype fix inline.

Here is the reproducer - https://godbolt.org/z/7bcjzfYK4

Heads-up - I'm seeing the compilation failure that reduces to this commit. I didn't get a reproducer of the reasonable size yet :(

This commit crashes compilation of the following test t.cc:

using float32 = float;
struct Simd;
using float32x1 = Simd;
template <typename, typename In> void BitCast(In);
struct TypeInfo {
  using VectorType = float32 __attribute__((ext_vector_type(1)));
};
struct Simd {
  using MaskType = int;
  using VectorType = TypeInfo::VectorType;
  VectorType v;
  Simd(int) : v() {}
  friend MaskType operator==(Simd x, Simd y) { BitCast<MaskType>(x.v == y.v); }
  Simd operator++(int);
};
template <typename T> void TestSimdType() { T k0(T(0)++ == k0); }
void TypesTest_Typefloat32x1_TestTestBody() { TestSimdType<float32x1>(); }

In D128146#3703292, @var-const wrote:

In D128146#3703008, @ldionne wrote:

In D128146#3699909, @vitalybuka wrote:

@vitalybuka This isn't unexpected. -fno-inline disables inlining, which is essential for a lot of other optimizations. Using -fno-inline pretty much defeats the optimizer: https://godbolt.org/z/zrE5o1WK1.

I am more concerned about sanitizers

https://godbolt.org/z/1x9qjGG19 Near LBB11_5 we have now __asan_memcpy per every "P", before it was for entire vector.
I assume some additional improvement in instrumentation are possible, maybe replacing fixed short asan_memcpy with check/load/store. Or even optimizing asan_memcpy itself.

But still maybe some ideas if it's solvable on libc++ level so we rely less on optimizations?

I suspect this might go away if we manually lowered std::uninitialized_foo to memcpy like we do for std::copy and std::move.

(Just in case, I had a patch to do that a while ago: https://reviews.llvm.org/D118329)

The code is from libzim - https://github.com/openzim/libzim/blob/966f7b217e9bc36dc30be6d9e46d51a2bfb7091c/src/zim_types.h#L36 . It doesn't look nice to me, and there definitely are multiple ways to make it work.

Here is a sample that was compiling Ok before the change and is now broken: https://godbolt.org/z/djPG94f69

Thanks a lot, @huixie90!

In D128146#3672212, @philnik wrote:

In D128146#3672050, @bgraur wrote:

Hi folks,

We have some code which compiles fine with the version previous to this patch and fails after.
The code compiles fine with godbolt: https://gcc.godbolt.org/z/ToPGG5cMb

But fails when built with clang containing this revision.
Repro compilation command:

clang -stdlib=libc++ -std=gnu++17 \
  -c /tmp/test.cc \
  -o /tmp/test.o

Compiler output:

/tmp/test.cc:5:17: error: assigning to 'float' from incompatible type 'Vx<float, 2>'
  data[Index] = std::forward<LastArg>(last_arg);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/test.cc:22:5: note: in instantiation of function template specialization 'SetData<0, 2, float, Vx<float, 2> &>' requested here
    SetData<0, Length, Element>(data_, std::forward<Args>(args)...);
    ^
[redacted]/include/c++/v1/__memory/allocator.h:165:28: note: in instantiation of function template specialization 'Vx<float, 2>::Vx<Vx<float, 2> &>' requested here
        ::new ((void*)__p) _Up(_VSTD::forward<_Args>(__args)...);
                           ^
[redacted]/include/c++/v1/__memory/allocator_traits.h:290:13: note: in instantiation of function template specialization 'std::allocator<Vx<float, 2>>::construct<Vx<float, 2>, Vx<float, 2> &>' requested here
        __a.construct(__p, _VSTD::forward<_Args>(__args)...);
            ^
[redacted]/include/c++/v1/__memory/uninitialized_algorithms.h:536:31: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<Vx<float, 2>>>::construct<Vx<float, 2>, Vx<float, 2> &, void>' requested here
    allocator_traits<_Alloc>::construct(__alloc, std::__to_address(__first2), *__first1);
                              ^
[redacted]/include/c++/v1/vector:1012:22: note: in instantiation of function template specialization 'std::__uninitialized_allocator_copy<std::allocator<Vx<float, 2>>, Vx<float, 2> *, Vx<float, 2> *, Vx<float, 2> *>' requested here
  __tx.__pos_ = std::__uninitialized_allocator_copy(__alloc(), __first, __last, __tx.__pos_);
                     ^
[redacted]/include/c++/v1/vector:1162:9: note: in instantiation of function template specialization 'std::vector<Vx<float, 2>>::__construct_at_end<Vx<float, 2> *>' requested here
        __construct_at_end(__x.__begin_, __x.__end_, __n);
        ^
/tmp/test.cc:35:16: note: in instantiation of member function 'std::vector<Vx<float, 2>>::vector' requested here
  do_something(vertices);
               ^
1 error generated.

I think this is a bug in your code. https://godbolt.org/z/sv8YehKhY fails the same way, but without std::vector. BTW the simplest fix would be to add Vx(Vx& v) : Vx(std::as_const(v)) {}.

Thanks Konstantin, now it works!

Unfortunately not, this doesn't fix the issue I'm seeing.

Thanks Sanjay, this fixes the issues we are seeing so far.

BTW, this is not about -Ofast - the problem reproduces with -O1 - https://gcc.godbolt.org/z/6barovn81

Hi David,

This patch introduces the difference between new inlined and library versions of std::pow, at least on x86_64. For large exponents, the difference is large. Also, when the difference accumulates, it makes a lot of existing tests that compare against golden values to go far beyond the meaningful margin.