In D48806#1149655, @dim wrote:

In D48806#1149211, @devnexen wrote:

In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

This is on FreeBSD 12-CURRENT, but it could also show the same issue on 11.x.

In D48806#1149211, @devnexen wrote:

In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

FWIW, after this commit, on FreeBSD 12.0-CURRENT, most (if not all) ASan tests hang in 'urdlck' state. I'm still investigating.

Do we still leave the defaults for particular OSes here? I'm asking because for example in FreeBSD, we use libcxxrt, but you *won't* find it in linker output, since our libc++.so is a linker script:

$ clang++ /usr/local/share/cmake/Modules/DummyCXXFile.cxx -###
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/clang++" "-cc1" "-triple" "x86_64-unknown-freebsd11.2" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "DummyCXXFile.cxx" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/clang/6.0.0" "-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro" "-fdebug-compilation-dir" "/home/dim/src/llvm/trunk" "-ferror-limit" "19" "-fmessage-length" "160" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/DummyCXXFile-5ffab3.o" "-x" "c++" "/usr/local/share/cmake/Modules/DummyCXXFile.cxx"
 "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/DummyCXXFile-5ffab3.o" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"

E.g., you see -lc++, and our /usr/lib/libc++.so contains:

$ cat /usr/lib/libc++.so
/* $FreeBSD: stable/11/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */
GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )

So what would check_link_libraries find in this case?

Use DeleteContainerSeconds instead of rolling our own.

Ping.

Sorry for reacting rather late to this, but I'm getting:

I'm fine with this, and also with committing it into FreeBSD's copy of lld, but I'd like to see the opinion of @ruiu and/or @grimar too. (I take it @espindola is no longer being monitored...)

Brooks, I can commit this if you prefer. Maybe it can go into 6.0.2 still...

In D45652#1078277, @emaste wrote:

Do we know why pthread_{get,set}specific fails now? And would it make sense to use tls more broadly (not just on FreeBSD)?

Ping

So, does this look good enough to commit?

Attempt to put the standard values in to definition lists. In the HTML
output, this looks fairly nice, but as a man page, it seems a bit
strange, for example:

In D45406#1060914, @mgorny wrote:

Well, my idea was to list the standards one per line (like on GCC manpage), and then the '(deprecated)' comments would probably stand out enough to apply to a single line. Also, FWICS the gcc manpage simply lists which aliases are deprecated in the description text. But skipping them entirely also works for me.

• Use "values" instead of "options"
• Remove deprecated standard values

In D45406#1060768, @mgorny wrote:

To be honest, I find those '(deprecated)' confusing — the user may mistakenly assume that it's about all values rather than the alias.

Interestingly, adding some debug prints to ConstantFoldFP seems to indicate the the NativeFP call *does* give the correct result:

Ping. Open to sugggestions here :)

LGTM

LGTM.

@rsmith, any objections?

I'm fine with either this approach, or with the approach in stdint.h, e.g. using __has_include_next(), and in that case first including the system-provided header before this one.

In D44536#1039420, @rjmccall wrote:

I'm not sure it's supposed to be a valid state to get into IRGen with a non-trivial destructor that isn't yet declared. Richard?

Update using @bdrewery's suggestion, with one small fix for Linux, where
Backtrace_LIBRARIES is usually an empty string.

Remove the __LAHFSAHF__ predefined macro.

LGTM.

Added the sahf feature for knm, knl and amdfam10 too.

In D43168#1005380, @dim wrote:

Apparently there is a halide_spawn_thread function in the bitcode. I am unsure if there is any source for that bitcode?

In D43168#1005331, @MatzeB wrote:

@asbirlea: Why is -dl and -pthread needed at all? Glancing at the code I don't see any reference to pthreads or dlopen/dlsym...

In D43159#1004625, @EricWF wrote:

So my main concern with this patch is that nullptr is actually #defined'ed in C++03 mode. That definition comes from the __nullptr header, and therefore we would need to add that header to each include which uses it. Which kind of sucks.

LGTM minus a few nits, though it would be nice if you can verify that all the changed headers still compile in -std=c++98 and/or -std=gnu++98 mode.

Update to use a for loop for iterating over CMAKE_DL_LIBS, and while we are here, also use CMake's FindThreads module and CMAKE_THREAD_LIBS_INIT (this will contain -lpthread, if it is necessary for the target system).

It looks like test-suite has some sort of special handling for test executables, where it uses LDFLAGS instead of target_link_libraries():

In D43168#1004536, @krytarowski wrote:

CMAKE_DL_LIBS allows us to fix it once for everybody and forever.

CMAKE_DL_LIBS is already used in llvm, e.g.

if( HAVE_LIBDL )
  set(system_libs ${system_libs} ${CMAKE_DL_LIBS})
endif()

in llvm/lib/Support/CMakeLists.txt

I don't want to repeat this process for AIX, SmartOS (they are now migrating to Clang at least for pkgsrc) etc.

One other problem is that CMAKE_DL_LIBS is meant for adding to cmake targets, e.g. it only contains the string "dl" on Linux. This means that you would have to add some sort of transformation to change it into "-ldl"... Way too complicated, if you ask me. :)

In D43168#1004532, @krytarowski wrote:

Can we use CMAKE_DL_LIBS?

FWIW, this allows me to build wine again for x86_64, without any crashes or assertions. So that looks good, in any case.

LGTM, though a test case would be nice (could be added to tools/clang/test/Driver/freebsd.c)

Hmm, apparently CMake *always* returns a full path for find_library(), but we seem to ignore those, by doing (for example in libclang's CMakeLists.txt):

In D42702#995109, @krytarowski wrote:

In D42702#995106, @dim wrote:

In D42702#994985, @krytarowski wrote:

-l/usr/lib/libexecinfo.so this should be replaced with -lexecinfo.

As I said, this is something detected by CMake, not LLVM's scripts. We could attempt to submit a fix to CMake, but that will take quite some time to arrive, and some vendor versions (such as Red Hat's or Debian's) will not be fixed for years, if ever.

This means that we need to implement check manually, in worst case hardcode it under the FreeBSD|NetBSD OS.

In D42702#994985, @krytarowski wrote:

-l/usr/lib/libexecinfo.so this should be replaced with -lexecinfo.