Is there any point doing this now when the switch to git is imminent?

This patch also breaks the Solaris builds:

[1097/4181] Building CXX object projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan_standalone.i386.dir/ubsan_signals_standalone.cpp.o
FAILED: projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan_standalone.i386.dir/ubsan_signals_standalone.cpp.o 
/usr/gcc/7/bin/c++  -D_DEBUG -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/ubsan -I/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan -Iinclude -I/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/include -I/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/include/llvm/Support/Solaris -I/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++14 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O3    -UNDEBUG  -m32 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -DUBSAN_CAN_USE_CXXABI -MD -MT projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan_standalone.i386.dir/ubsan_signals_standalone.cpp.o -MF projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan_standalone.i386.dir/ubsan_signals_standalone.cpp.o.d -o projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan_standalone.i386.dir/ubsan_signals_standalone.cpp.o -c /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/ubsan_signals_standalone.cpp
In file included from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/../sanitizer_common/sanitizer_platform_interceptors.h:16:0,
                 from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/../sanitizer_common/sanitizer_signal_interceptors.inc:16,
                 from /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/ubsan_signals_standalone.cpp:38:
/opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/lib/ubsan/../sanitizer_common/sanitizer_glibc_version.h:19:10: fatal error: features.h: No such file or directory
 #include <features.h>
          ^~~~~~~~~~~~
compilation terminated.

I've now submitted the lldb patch to reflect the LangStandard.h move.

• Restrict enum class Languge to uint8_t to save space.
• Filter patch through clang-format-diff.py

In D64793#1613063, @rnk wrote:

lgtm

If I interpret @jyknight correctly, having failed to dissuade you, he doesn't feel strongly enough about this to block it, he just wants to reduce legacy when feasible.

Rebased after .cc -> .cpp mass renamings.

Account for enum class Language change in D65562.

Change Language to enum class.

In D64483#1609776, @hans wrote:

In D64483#1606208, @ro wrote:

Updated patch to make use of the move to
Basic.

In D64793#1604877, @jyknight wrote:

I fear it is necessary: at least it matches documented behaviour of both the Sun/Oracle Studio compilers and gcc.

I will defer to your opinion here. But -- one last attempt at dissuading you. :)

Is this really doing something _important_, or is it just legacy cruft which can be safely ignored by now? With your "logb" example, it seems to me that it is probably preferable to always use the new correct "xpg6" implementation, and just ignore the legacy/incorrect version. Similarly, the example given in https://gcc.gnu.org/PR40411 of freopen -- again, seems like it'd be better to just use the new xpg6 behavior, always.

Test i386--solaris instead of x86_64--solaris twice.

In D64488#1606716, @krytarowski wrote:

Something is broken between reviews. and my mailbox as I am not receiving any e-mails so pinging does not make any effect... no LLVM admin replied to my questions on this to validate whether my mail was blacklisted or similar. I have decided to change server of my mailbox and workaround it.

In D64483#1605989, @ro wrote:

In D64483#1605895, @hans wrote:

Thanks. Would this and its companion D64482 be appropriate for the 9.x branch, too? If so, what's the procedure to get it there?

Probably. They need to land on trunk first, then let me know and I'll merge them.

Both patches are in now. However, there's a buildbot failure
that claims to be related, though I cannot see yet how this can possibly happen.

In D64483#1605895, @hans wrote:

Thanks. Would this and its companion D64482 be appropriate for the 9.x branch, too? If so, what's the procedure to get it there?

Probably. They need to land on trunk first, then let me know and I'll merge them.

In D64483#1605840, @hans wrote:

Seems fine I guess, since this matches what's already there for AIX.

In D64796#1605207, @jyknight wrote:

Given the reference to the bug, seems fine to me to commit an xfail here since nobody is actively working to fix this right now.

In D65056#1604957, @vitalybuka wrote:

In D65056#1603902, @ro wrote:

Ping? It's been a week now. Is there some policy not to xfail the test which as documented in the bug cannot pass on Solaris?

If the test fails consistently on the platform and there is a chance to make it pass some day, I would prefer to have XFAIL.

Ping^2? Is it ok to xfail those tests given a fix is far from trivial for me?

Ping^2? It's been two weeks now. Who can decide if the LangStandards code can be used from lib/Frontend as is or needs to be moved
elsewhere (lib/Basic?) for use by driver code?

Ping^3? Three weeks and counting...

Ping^2? It's been two weeks now and I'd like to know how to proceed with this patch.

Ping? It's been a week and the behaviour of Solaris pthread_key_create is allowed by the spec.

In D64793#1597550, @jyknight wrote:

Is this really necessary? Users don't typically pass -std= to the driver for linking anyways (what do you even pass if you've compiled both C and C++ code?) so this seems a rather odd way to control behavior.

In D64496#1597361, @jyknight wrote:

The code you reference in GCC is only for trampolines, while this function is used to implement builtin_clear_cache. AFAICT GCC is just wrong to implement this as a no-op.

In D64796#1597196, @MaskRay wrote:

Is rL189780 related? If you can simply fix the issue, you probably don't have to XFAIL the tests...

Ping? It's been a week now. I don't really know abouth LLVM's testcase xfail policy. Someone to enlighten me?

Ping? It's been a week now and this is a correctness issue on Solaris, not just a single failing test.

Ping^2? Two weeks now; anyone else who could review this?

Ping^2? Two weeks now.

Ping^2? Two weeks now for a pretty obvious patch.

Ping^2? It's been two weeks now.

How should we procede here, given the proposed alternative doesn't work? It would be good to get this and the already approved
companion patch into trunk and, if possible, into the 9.x branch.

In D64483#1590120, @rnk wrote:

I would place this macro setting with the other code that sets this macro, in cmake/modules/HandleLLVMOptions.cmake.

In D64482#1589174, @MaskRay wrote:

In D64482#1588154, @rnk wrote:

To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64
(e.g. clang < 9, gcc < 9), this needs a compantion patch to be submitted shortly.

I'm curious, what's the plan for that? I suppose the user can always take things into their own hands with -D and -U.