In D14242#298980, @emaste wrote:

In D14242#298846, @dim wrote:

Maybe a general remark, will this MK_RETPOLINE option be separate from a similar option for userland? Also, does this take care of adding the required link flags when linking the kernel?

Would you suggest we rename this one MK_KERNEL_RETPOLINE and introduce a separate MK_USERLAND_RETPOLINE?
Linker flags are required only when linking dynamic executables, to generate a retpoline-style PLT.

Feb 17 2018, 7:41 PM

Feb 16 2018

dim committed rS329410: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to

Feb 16 2018, 8:45 PM

dim committed rS329395: Tag llvm release_60 branch r325330..

Tag llvm release_60 branch r325330.

Feb 16 2018, 7:40 PM

dim committed rS329397: Tag clang release_60 branch r325330..

Tag clang release_60 branch r325330.

Feb 16 2018, 7:31 PM

dim committed rS329401: Tag libc++ release_60 branch r325330..

Tag libc++ release_60 branch r325330.

Feb 16 2018, 7:22 PM

dim committed rS329405: Tag lldb release_60 branch r325330..

Tag lldb release_60 branch r325330.

Feb 16 2018, 7:22 PM

dim committed rS329399: Tag compiler-rt release_60 branch r325330..

Tag compiler-rt release_60 branch r325330.

Feb 16 2018, 7:16 PM

dim committed rS329403: Tag lld release_60 branch r325330..

Tag lld release_60 branch r325330.

Feb 16 2018, 7:15 PM

dim committed rS329404: Vendor import of lldb release_60 branch r325330:.

Vendor import of lldb release_60 branch r325330:

Feb 16 2018, 7:11 PM

dim committed rS329402: Vendor import of lld release_60 branch r325330:.

Vendor import of lld release_60 branch r325330:

Feb 16 2018, 7:11 PM

dim committed rS329400: Vendor import of libc++ release_60 branch r325330:.

Vendor import of libc++ release_60 branch r325330:

Feb 16 2018, 7:11 PM

dim committed rS329396: Vendor import of clang release_60 branch r325330:.

Vendor import of clang release_60 branch r325330:

Feb 16 2018, 7:10 PM

dim committed rS329398: Vendor import of compiler-rt release_60 branch r325330:.

Vendor import of compiler-rt release_60 branch r325330:

Feb 16 2018, 7:10 PM

dim committed rS329394: Vendor import of llvm release_60 branch r325330:.

Vendor import of llvm release_60 branch r325330:

Feb 16 2018, 7:10 PM

Feb 13 2018

dim committed rS329223: Pull in r323998 from upstream clang trunk (by Richard Smith):.

Pull in r323998 from upstream clang trunk (by Richard Smith):

Feb 13 2018, 5:06 PM

Feb 8 2018

dim committed rD51410: Document __FreeBSD_version 1200057..

Document __FreeBSD_version 1200057.

Feb 8 2018, 9:14 PM

dim committed rS329033: Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):.

Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):

Feb 8 2018, 9:12 PM

dim accepted D14265: Promote llvm-cov to a standalone option.

Feb 8 2018, 7:12 PM

Feb 7 2018

dim added a comment to D14242: Enable kernel retpoline support.

Maybe a general remark, will this MK_RETPOLINE option be separate from a similar option for userland? Also, does this take care of adding the required link flags when linking the kernel?

Feb 7 2018, 10:06 PM

dim added inline comments to D14242: Enable kernel retpoline support.

Feb 7 2018, 4:13 PM

Feb 6 2018

dim added a comment to D14228: bsd.linker.mk: add retpolineplt linker feature.

This looks good to me, though at some version gcc and BFD ld will also support retpoline, right? We can add that later...

Feb 6 2018, 10:41 PM

Feb 4 2018

dim committed rS328863: Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed.

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed

Feb 4 2018, 8:34 PM

Feb 2 2018

dim committed rS328817: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to

Feb 2 2018, 10:28 PM

dim added a comment to D12912: Don't fail the build due to clang integer constant range warnings.

Yeah, upstream also dropped it from the default -Wextra flags, due to too many false positives, here: https://reviews.llvm.org/rL322901. This got merged to the 6.0 branch in https://reviews.llvm.org/rL322931, which came into our tree with rS328381. I think this should be no longer necessary.

Feb 2 2018, 10:13 PM

dim committed rS328787: Tag llvm release_60 branch r324090..

Tag llvm release_60 branch r324090.

Feb 2 2018, 5:27 PM

dim committed rS328789: Tag clang release_60 branch r324090..

Tag clang release_60 branch r324090.

Feb 2 2018, 5:24 PM

dim committed rS328791: Tag libc++ release_60 branch r324090..

Tag libc++ release_60 branch r324090.

Feb 2 2018, 5:18 PM

dim committed rS328794: Tag lldb release_60 branch r324090..

Tag lldb release_60 branch r324090.

Feb 2 2018, 5:18 PM

dim committed rS328790: Tag compiler-rt release_60 branch r324090..

Tag compiler-rt release_60 branch r324090.

Feb 2 2018, 5:13 PM

dim committed rS328793: Tag lld release_60 branch r324090..

Tag lld release_60 branch r324090.

Feb 2 2018, 5:12 PM

dim committed rS328792: Vendor import of lld release_60 branch r324090:.

Vendor import of lld release_60 branch r324090:

Feb 2 2018, 5:08 PM

dim committed rS328788: Vendor import of clang release_60 branch r324090:.

Vendor import of clang release_60 branch r324090:

Feb 2 2018, 5:08 PM

dim committed rS328786: Vendor import of llvm release_60 branch r324090:.

Vendor import of llvm release_60 branch r324090:

Feb 2 2018, 5:08 PM

Feb 1 2018

dim committed rS328753: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to

Feb 1 2018, 9:41 PM

dim committed rS328738: Tag llvm release_60 branch r323948..

Tag llvm release_60 branch r323948.

Feb 1 2018, 9:40 PM

dim committed rS328740: Tag clang release_60 branch r323948..

Tag clang release_60 branch r323948.

Feb 1 2018, 9:35 PM

dim committed rS328744: Tag libc++ release_60 branch r323948..

Tag libc++ release_60 branch r323948.

Feb 1 2018, 9:29 PM

dim committed rS328747: Tag lldb release_60 branch r323948..

Tag lldb release_60 branch r323948.

Feb 1 2018, 9:29 PM

dim committed rS328743: Tag compiler-rt release_60 branch r323948..

Tag compiler-rt release_60 branch r323948.

Feb 1 2018, 9:24 PM

dim committed rS328746: Tag lld release_60 branch r323948..

Tag lld release_60 branch r323948.

Feb 1 2018, 9:23 PM

dim committed rS328745: Vendor import of lld release_60 branch r323948:.

Vendor import of lld release_60 branch r323948:

Feb 1 2018, 9:16 PM

dim committed rS328742: Vendor import of compiler-rt release_60 branch r323948:.

Vendor import of compiler-rt release_60 branch r323948:

Feb 1 2018, 9:16 PM

dim committed rS328739: Vendor import of clang release_60 branch r323948:.

Vendor import of clang release_60 branch r323948:

Feb 1 2018, 9:16 PM

dim committed rS328734: Vendor import of llvm release_60 branch r323948:.

Vendor import of llvm release_60 branch r323948:

Feb 1 2018, 9:08 PM

Jan 29 2018

dim committed rS328555: Pull in r217197 from upstream clang trunk (by Richard Smith):.

Pull in r217197 from upstream clang trunk (by Richard Smith):

Jan 29 2018, 6:11 PM

Jan 28 2018

dim committed rS328513: Pull in r322245 from upstream clang trunk (by Craig Topper):.

Pull in r322245 from upstream clang trunk (by Craig Topper):

Jan 28 2018, 4:10 PM

Jan 26 2018

dim added a comment to D14058: shells/fish: fix the build with Clang-6.0.0.

In D14058#295314, @asomers wrote:

In D14058#295310, @dim wrote:

I don't see what the OSVERSION check is for? Since libc++ never defined __cpp_lib_make_unique, this can't have worked on earlier versions either. Why is this suddenly needed now, because we're defaulting to gnu++14? In that case you could also just crank down the standard to e.g. -std=gnu++11 or even lower.

The problem is that while __cpp_lib_make_unique isn't defined, std::make_unique is. That causes error: call to 'make_unique' is ambiguous errors, because fish defines its own make_unique if the standard library doesn't provide one. I'm guessing that earlier versions of Clang didn't provide make_unique, at least not with our default --std option. Does libc++ have a different feature test macro for "supports all C++14 features" or something like that?

Jan 26 2018, 8:27 PM

dim added a comment to D14058: shells/fish: fix the build with Clang-6.0.0.

I don't see what the OSVERSION check is for? Since libc++ never defined __cpp_lib_make_unique, this can't have worked on earlier versions either. Why is this suddenly needed now, because we're defaulting to gnu++14? In that case you could also just crank down the standard to e.g. -std=gnu++11 or even lower.

Jan 26 2018, 5:29 PM

dim added a comment to D14058: shells/fish: fix the build with Clang-6.0.0.

I'm not entirely sure that this macro is defined by any C++ standard, though there appears to be a "recommendation" note that refers to it. It would be easier to just test for the C++ version instead, I think. But if #if 1 also works, I'm fine with it.

Jan 26 2018, 5:25 PM