This change broke the build of msan on FreeBSD. dladdr1 seems to be a glibc-ism and is not present in FreeBSD or musl. All this functionality needs to be gated by a CMake check.

This change is broken on FreeBSD current (https://github.com/llvm/llvm-project/issues/63485) and was at the time it was committed.

• Rebase
• Add powerpc64le

@arichardson please commit. I do not have commit access. Thanks

Add a test as requested by @arichardson

I'm looking into getting __float128 support enabled on FreeBSD (it's a trivial patch, but I'm not an expert in the area so am not sure if we're missing something in the runtime we need to fix before switching). It will be at least a year before all supported FreeBSD version include the change though so adjusting this guard makes sense. I did verify that both clang and GCC of appropriate vintage define __SIZEOF_FLOAT128__ on Linux so maybe we should just use that instead of version checks unless there are know-bad versions.

This is clang 13.0.0.

FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: x86_64-unknown-freebsd13.1
Thread model: posix
InstalledDir: /usr/bin

I'm beginning to suspect this issue is a lack of runtime support for __float128, but I'm far from certain.

This was on FreeBSD 13.1 amd64. The cmake command for the bisect was:

cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lld;flang" ../llvm

I've got things building again with:

--- flang/include/flang/Runtime/float128.h.orig
+++ flang/include/flang/Runtime/float128.h
@@ -22,7 +22,7 @@

This breaks the build on at least x86_64-unknown-freebsd13.1 with:

Seems fine to me. There will likely be some bumps the FreeBSD port, but should be manageable, especially if it's coming in 16.

Should no longer be needed

D126710 was committed

• Hopefully use arc correctly

• Add an explanatory comment

I've added D126710 as an alternative that just doesn't create the libcall functions.

The other alternative I considered was to not generate __atomic_fetch_nand_* symbols at all if __c11_atomic_fetch_nand isn't available. It sounds like this might be the more correct approach. It has the downside that the symbols in FreeBSD's libraries can variety depending on which compiler we're using, but doesn't emit incorrect libcalls.

In D126395#3539727, @lkail wrote:

I'm not sure if it's appropriate to use clang and compiler-rt in different versions. Added more reviewers for discussion.

This pops up trying to build FreeBSD with LLVM 14 integrated using clang from LLVM 13 and not building a bootstrap toolchain.

I can verify this fixes the build on FreeBSD 13.

In rG0d8cb8b399adcd17e8bf17be7814d030308c8b82#1085375, @dim wrote:

In rG0d8cb8b399adcd17e8bf17be7814d030308c8b82#1084447, @dblaikie wrote:

In rG0d8cb8b399adcd17e8bf17be7814d030308c8b82#1084182, @kparzysz wrote:

This fails to compile:

$ /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/w/bld/org/lib/DebugInfo/DWARF -I/w/src/llvm.org/llvm/lib/DebugInfo/DWARF -I/w/bld/org/include -I/w/src/llvm.org/llvm/include -I/usr/local/include -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -Wmisleading-indentation -ffunction-sections -fdata-sections -O3 -DNDEBUG  -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -c /w/src/llvm.org/llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
In file included from /w/src/llvm.org/llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp:8:
In file included from /w/src/llvm.org/llvm/include/llvm/DebugInfo/DWARF/DWARFVerifier.h:12:
In file included from /w/src/llvm.org/llvm/include/llvm/ADT/Optional.h:19:
In file included from /w/src/llvm.org/llvm/include/llvm/ADT/Hashing.h:51:
In file included from /usr/include/c++/v1/algorithm:653:
In file included from /usr/include/c++/v1/functional:500:
In file included from /usr/include/c++/v1/__functional/function.h:20:
In file included from /usr/include/c++/v1/__memory/shared_ptr.h:22:
/usr/include/c++/v1/__memory/allocator.h:154:28: error: call to implicitly-deleted copy constructor of 'llvm::IntervalMap<unsigned int, unsigned long, 12>'
        ::new ((void*)__p) _Up(_VSTD::forward<_Args>(__args)...);
                           ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__memory/allocator_traits.h:290:13: note: in instantiation of function template specialization 'std::allocator<llvm::IntervalMap<unsigned int, unsigned long, 12>>::construct<llvm::IntervalMap<unsigned int, unsigned long, 12>, const llvm::IntervalMap<unsigned int, unsigned long, 12> &>' requested here
        __a.construct(__p, _VSTD::forward<_Args>(__args)...);
            ^
/usr/include/c++/v1/vector:1085:25: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<llvm::IntervalMap<unsigned int, unsigned long, 12>>>::construct<llvm::IntervalMap<unsigned int, unsigned long, 12>, const llvm::IntervalMap<unsigned int, unsigned long, 12> &, void>' requested here
        __alloc_traits::construct(this->__alloc(), _VSTD::__to_address(__pos), __x);
                        ^
/usr/include/c++/v1/vector:1178:9: note: in instantiation of member function 'std::vector<llvm::IntervalMap<unsigned int, unsigned long, 12>>::__construct_at_end' requested here
        __construct_at_end(__n, __x);
        ^
/w/src/llvm.org/llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp:410:48: note: in instantiation of member function 'std::vector<llvm::IntervalMap<unsigned int, unsigned long, 12>>::vector' requested here
  std::vector<IntervalMap<uint32_t, uint64_t>> Sections(
                                               ^
/w/src/llvm.org/llvm/include/llvm/ADT/IntervalMap.h:970:14: note: copy constructor of 'IntervalMap<unsigned int, unsigned long, 12>' is implicitly deleted because variant field 'leaf' has a non-trivial copy constructor
    RootLeaf leaf;
             ^
1 error generated.

What standard library is in use here? I believe it's non-conformant (& since lots of other buildbots haven't failed on this, that seems likely), possibly outdated.

LLVM requires C++14 and C++14 provides a std::vector constructor that takes a count (& not a default value) and default constructs the elements in-place without copying a singular default value.

The error is a bit misleading, as it is ultimately caused by FreeBSD defaulting to _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR in libc++, as we have done historically, to preserve ABI. This unfortunate historical accident bites us every now and then, when some code uses a non-trivial std::pair constructor.

Unfortunately the way libc++ has implemented _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR it is not easy to turn off by an end-user:

https://github.com/llvm/llvm-project/blob/main/libcxx/include/__config#L130

I think some FreeBSD ports simply bump the libc++ ABI define to 2 to 'work around' this. However, this makes your C++ binaries/libraries incompatible with the base libc++ library.

In rG0d8cb8b399adcd17e8bf17be7814d030308c8b82#1085010, @dblaikie wrote:

In rG0d8cb8b399adcd17e8bf17be7814d030308c8b82#1084994, @kparzysz wrote:

Here's more info:

$ c++ --version
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

Most files in /usr/include/c++/v1 match those from release/13.x:libcxx/include. Maybe there is something different in __config, but I didn't look in detail.

https://godbolt.org/z/WMrcEeW8o - it looks like these small examples do work all the way back to Clang 5... so I'm not sure what's going on with your situation.

It would be somewhat helpful as a transition aid if -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang remained as a no-op producing a warning (a generic unused argument warning would be fine).

This commit is breaking the ability to configure openmp as a project alongside llvm on FreeBSD. I'm getting:

$ cmake ../llvm -DLLVM_ENABLE_PROJECTS='llvm;clang;lld;openmp'
...
-- Configuring done
CMake Error at /home/bed22/git/llvm-project/openmp/libomptarget/plugins/amdgpu/CMakeLists.txt:74 (add_dependencies):
  The dependency target "omptarget.devicertl.amdgpu" of target
  "omptarget.rtl.amdgpu" does not exist.

This fails to configure in cmake when enabled as a project.

Thanks, this will kill off one of the patches in our ports.

This patch is sufficient to let things build, but doesn't address the tests. If there's a plan to MFC PT_COREDUMP that's probably an ok state of affairs. https://cgit.freebsd.org/ports/tree/devel/llvm-devel/files/patch-lldb-PT_COREDUMP.diff?id=7e2f156ce907e7785863d49cbd33d36f07df7eae

This needs to be guarded by the presence of PT_COREDUMP since it's a new feature. As it stands this breaks the lldb build on all supported FreeBSD releases.

This results in a manpage with the filename tblgen Family.1 which quite odd.

This seems to replace D77333

• clang-format patched lines.

Doing a bit of naive digging suggests to me that putting this section inside an

if (NOT CMAKE_CFG_INTDIR STREQUAL  ".")

might do the trick.

The generator is Ninja. @emaste may know of a buildbot. Note that this is an install failure so I'm not sure if buildbots will catch it.

This is broken in a FreeBSD install.

In D7104#1596416, @emaste wrote:

@brooks, @arichardson do we still want to pursue this?

See also: D51859

Also broke the FreeBSD build:

I do think we should make this change, but don't have a strong opinion on the timing. If we do it for 12 and not 13 then we should probably try to get it into a 6.0.2.

• Correct whitespace.

I've received multiple reports of this issue from FreeBSD ports users, but have never encountered it myself. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227460

Adding Alex as he made some related changes to CHERI Clang recently https://github.com/CTSRD-CHERI/clang/commit/3a648766deabb4ff7f95862213c3c99e7223363c.

I may just not understand how render() works, but I tried it and it didn't seem to work to replace

Remove a spurious -mcpu from the test case.

In D9114#181178, @dim wrote:

In D9114#181174, @brooks wrote:

Even if this patch is incomplete with regards to the assembler, it is both necessary and sufficient to build and link programs with the current FreeBSD build system. It follows gcc's long established behavior as a linker and is harmless to other consumers so why not commit it?

Sure, but maybe -G for the linker is not completely useful, if the assembler also doesn't use it?

Even if this patch is incomplete with regards to the assembler, it is both necessary and sufficient to build and link programs with the current FreeBSD build system. It follows gcc's long established behavior as a linker and is harmless to other consumers so why not commit it?

Add cfe-commits per message

Add a test for not passing -G0 when it isn't an argument.