Alexander Leidinger Alexander at leidinger.net wrote on Sat Feb 9 17:26:10 UTC 2019 : > Quoting Alexander Leidinger <Alexander at leidinger.net> (from Sat, 09 > Feb 2019 13:44:25 +0100): > > > This is after deleting /usr/obj, and cleaning the ccache cache. All > > cases are with CPUTYPE=native (Intel Xeon E5620). > > > > I remember a commit of a new clang to head. Anything else in the > > area of influence for this? > > My next try is to compile without CPUTYPE=native to see if the new > > clang is doing something in this area which it didn't do before. Has > > anyone else seen a similar issue or has an idea what to look at next? > > Removing the CPUTYPE setting in make.conf didn't help. Ideas welcome. > I am running: # uname -apKU FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #9 r343884M: Thu Feb 7 19:22:33 PST 2019 markmi_at_FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1300010 1300010 but I happen to have been booting the SSD via Hyper-V under Windows 10 Pro instead of directly in recent times. (Things are configured to allow booting from the BIOS as well.) Also: My builds are normally with non-debug kernels, the above included. I'm not seeing any problems with booting in my context. But I've been running various FreeBSD versions based on clang 7 for a while. Currently: # clang -v FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin I'd not expect clang vintage to be the issue. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Sat Feb 09 2019 - 20:11:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC