Alexander Leidinger Alexander at leidinger.net wrote on
Sat Feb 9 17:26:10 UTC 2019 :
> Quoting Alexander Leidinger (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@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)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
