Re: clang broken on current?
On 2019-Feb-10, at 12:02, Mark Millard wrote:
> On 2019-Feb-10, at 11:34, Steve Kargl
> wrote:
>
>> Having set CFLAGS+=-march=native -mtune=native and trying to
>> force qt5-gui configure with -sse2 option, I have a config.summary
>> that contains (my in-line comments ***)
>>
>> Build type: freebsd-clang (i386, CPU features: )
>>
>> *** What? ***
>>
>> Compiler: clang 7.0.1
>> Configuration: compile_examples largefile rdrnd x86SimdAlways sharedr
>> rpath release c++11 c++14 concurrent dbus reduce_exports reduce_relocations
>> stl
>> Build options:
>> Mode ... release
>> Optimize release build for size no
>> Building shared libraries .. yes
>> Using C standard ... C11
>> Using C++ standard . C++14
>> Using ccache ... no
>> Using gold linker .. no
>> Using precompiled headers .. no
>> Using LTCG . no
>> Target compiler supports:
>> SSE ..
>>
>> *** That's not good. ***
>>
>> AVX ..
>> AVX512 ...
>> Other x86 RDRAND
>> Intrinsics without -mXXX option .. yes
>> Build parts libs tools
>
>
> /usr/ports/Mk/Uses/qt-dist.mk has:
>
> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
> CONFIGURE_ARGS+=-no-sse2
> .endif
>
> This traces back to:
>
> /usr/src/share/mk/bsd.cpu.mk and its:
>
> . elif ${MACHINE_CPUARCH} == "amd64"
> MACHINE_CPU = amd64 sse2 sse mmx
> . elif ${MACHINE_CPUARCH} == "arm"
> MACHINE_CPU = arm
> . elif ${MACHINE_CPUARCH} == "i386"
> MACHINE_CPU = i486
>
> and (I'll not list it all):
>
> ## i386
> . if ${MACHINE_CPUARCH} == "i386"
> . if ${CPUTYPE} == "znver1"
> MACHINE_CPU = avx2 avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "bdver4"
> MACHINE_CPU = xop avx2 avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5
> i586
> . elif ${CPUTYPE} == "bdver3" || ${CPUTYPE} == "bdver2" || \
>${CPUTYPE} == "bdver1"
> MACHINE_CPU = xop avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "btver2"
> MACHINE_CPU = avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "btver1"
> MACHINE_CPU = ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "amdfam10"
> MACHINE_CPU = athlon-xp athlon k7 3dnow sse4a sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3"
> MACHINE_CPU = athlon-xp athlon k7 3dnow sse3 sse2 sse mmx k6 k5 i586
> . elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || \
>
> . . .
>
> and:
>
> ## amd64
> . elif ${MACHINE_CPUARCH} == "amd64"
> . if ${CPUTYPE} == "znver1"
> MACHINE_CPU = avx2 avx sse42 sse41 ssse3 sse4a sse3
> . . .
> . endif
> MACHINE_CPU += amd64 sse2 sse mmx
> ## Mips
> . elif ${MACHINE_CPUARCH} == "mips"
>
>
> So it looks like freeBSD expects CPUTYPE to be set for i368 in order
> to enable sse2 in MACHINE_CPU . Other things have a similar status
> for amd64 but amd64 always has sse2 .
>
[I see I switched which message that I was replying to. Sorry.]
Looks like when native works and clang is in use, and the context
is amd64 (or i386), CPUTYPE could be generated by the likes of
(example from my amd64 context):
# sh -c "clang -v -fsyntax-only -march=native -x c /dev/null 2>&1 | grep -e
'-target-cpu' | sed -e 's|.*-target-cpu \([[:alnum:]]*\) .*|\1|'"
znver1
(I got that command from
https://forums.freebsd.org/threads/make-conf-optimizations-optimizing-builds.63461/
.)
Trying such on a cortex-a57 (aarch64) got an empty-string result.
Same for cortex-a53 (aarch64) and cortex-a7 (armv7). (I do not have
a powerpc* available at the moment.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On 2019-Feb-10, at 11:34, Steve Kargl
wrote:
> Having set CFLAGS+=-march=native -mtune=native and trying to
> force qt5-gui configure with -sse2 option, I have a config.summary
> that contains (my in-line comments ***)
>
> Build type: freebsd-clang (i386, CPU features: )
>
> *** What? ***
>
> Compiler: clang 7.0.1
> Configuration: compile_examples largefile rdrnd x86SimdAlways sharedr
> rpath release c++11 c++14 concurrent dbus reduce_exports reduce_relocations
> stl
> Build options:
> Mode ... release
> Optimize release build for size no
> Building shared libraries .. yes
> Using C standard ... C11
> Using C++ standard . C++14
> Using ccache ... no
> Using gold linker .. no
> Using precompiled headers .. no
> Using LTCG . no
> Target compiler supports:
>SSE ..
>
> *** That's not good. ***
>
>AVX ..
>AVX512 ...
>Other x86 RDRAND
>Intrinsics without -mXXX option .. yes
> Build parts libs tools
/usr/ports/Mk/Uses/qt-dist.mk has:
.if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
CONFIGURE_ARGS+=-no-sse2
.endif
This traces back to:
/usr/src/share/mk/bsd.cpu.mk and its:
. elif ${MACHINE_CPUARCH} == "amd64"
MACHINE_CPU = amd64 sse2 sse mmx
. elif ${MACHINE_CPUARCH} == "arm"
MACHINE_CPU = arm
. elif ${MACHINE_CPUARCH} == "i386"
MACHINE_CPU = i486
and (I'll not list it all):
## i386
. if ${MACHINE_CPUARCH} == "i386"
. if ${CPUTYPE} == "znver1"
MACHINE_CPU = avx2 avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "bdver4"
MACHINE_CPU = xop avx2 avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "bdver3" || ${CPUTYPE} == "bdver2" || \
${CPUTYPE} == "bdver1"
MACHINE_CPU = xop avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "btver2"
MACHINE_CPU = avx sse42 sse41 ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "btver1"
MACHINE_CPU = ssse3 sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "amdfam10"
MACHINE_CPU = athlon-xp athlon k7 3dnow sse4a sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "opteron-sse3" || ${CPUTYPE} == "athlon64-sse3"
MACHINE_CPU = athlon-xp athlon k7 3dnow sse3 sse2 sse mmx k6 k5 i586
. elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || \
. . .
and:
## amd64
. elif ${MACHINE_CPUARCH} == "amd64"
. if ${CPUTYPE} == "znver1"
MACHINE_CPU = avx2 avx sse42 sse41 ssse3 sse4a sse3
. . .
. endif
MACHINE_CPU += amd64 sse2 sse mmx
## Mips
. elif ${MACHINE_CPUARCH} == "mips"
So it looks like freeBSD expects CPUTYPE to be set for i368 in order
to enable sse2 in MACHINE_CPU . Other things have a similar status
for amd64 but amd64 always has sse2 .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On 2019-Feb-10, at 11:24, Steve Kargl wrote: > On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote: >> >> On 2019-Feb-10, at 10:46, Steve Kargl >> wrote: >>> >>> On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: On 10 Feb 2019, at 06:00, Steve Kargl >>> troutmask.apl.washington.edu> wrote: How did you arrive at the conclusion that this has anything to do with the specific compiler? From these errors, I think it is more likely something in Qt5 that is erroneously convinced that those qt_memfillXY functions exist. Or they get referenced, but not compiled at all, for some reason. >>> >>> If I have "CFLAGS+= -march=i686 -mmmx -msse" in /etc/make.conf >>> qt5-gui builds without issue. If I add -msse2 to CFLAGS, then >>> the build dies. >>> >>> So, either clang is miscompiling qt5-gui with -mmse2 or the >>> qt5-gui port is being too smart for its own good. >> >> That lead to an old memory of getting results like ((armv6 >> time frame I think, before the armv7 addition to FreeBSD): >> >> image/qimage.cpp:(.text+0x1e14): undefined reference to >> `qt_memfill32(unsigned int*, unsigned int, int)' >> image/qimage.cpp:(.text+0x1f34): undefined reference to >> `qt_memfill32(unsigned int*, unsigned int, int)' >> >> where it turned out that arm NEON was not supported by various >> parts of qt5. >> > > It is definitely some problem between clang and the qt5-gui > port. It seems qt5-gui tries to auto-detect sse2. Don't > know if qt5-gui has a bogus auto-detect code, clang miscompiles > the auto-detect code, or FreeBSD is lying about the features > of my cpu (although x86info says it found sse2). In poking > around the qt5-gui sources, I found that configure can be > given a -sse2 argument. I tried to force sse2, but I'm seeing > qt5-gui is doing > > % find qtbase-everywhere-src-5.12.0 -name config.\* | xargs grep -i sse2 > qtbase-everywhere-src-5.12.0/config.log:Command line: -no-eglfs -sse2 > -no-evdev -no-libudev -system-harfbuzz -c++std c++14 -opensource > -confirm-license -no-pch -prefix /usr/local -bindir /usr/local/lib/qt5/bin > -headerdir /usr/local/include/qt5 -libdir /usr/local/lib/qt5 -plugindir > /usr/local/lib/qt5/plugins -importdir /usr/local/lib/qt5/imports -datadir > /usr/local/share/qt5 -docdir /usr/local/share/doc/qt5 -translationdir > /usr/local/share/qt5/translations -sysconfdir /usr/local/etc/xdg -nomake > examples -nomake tests -platform freebsd-clang -archdatadir > /usr/local/lib/qt5 -libexecdir /usr/local/libexec/qt5 -qmldir > /usr/local/lib/qt5/qml -examplesdir /usr/local/share/examples/qt5 -testsdir > /usr/local/share/qt5/tests -no-sse2 -no-use-gold-linker -recheck-all -release > -no-separate-debug-info > qtbase-everywhere-src-5.12.0/config.opt:-sse2 > qtbase-everywhere-src-5.12.0/config.opt:-no-sse2 > > Note my -sse2 is followed by a -no-sse2! FYI: from the "24 May 2015 16:41:17" check in description: Qt 5.3 removed runtime detection of SSE2 so it needs to be configured with -no-sse2 at buildtime on i386. PR: 198738, 200258 Reported by:sasamotik...@gmail.com Approved by:maintainer timeout (2 weeks) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
Having set CFLAGS+=-march=native -mtune=native and trying to force qt5-gui configure with -sse2 option, I have a config.summary that contains (my in-line comments ***) Build type: freebsd-clang (i386, CPU features: ) *** What? *** Compiler: clang 7.0.1 Configuration: compile_examples largefile rdrnd x86SimdAlways sharedr rpath release c++11 c++14 concurrent dbus reduce_exports reduce_relocations stl Build options: Mode ... release Optimize release build for size no Building shared libraries .. yes Using C standard ... C11 Using C++ standard . C++14 Using ccache ... no Using gold linker .. no Using precompiled headers .. no Using LTCG . no Target compiler supports: SSE .. *** That's not good. *** AVX .. AVX512 ... Other x86 RDRAND Intrinsics without -mXXX option .. yes Build parts libs tools -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote: > > On 2019-Feb-10, at 10:46, Steve Kargl > wrote: > > > > On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > >> On 10 Feb 2019, at 06:00, Steve Kargl >> troutmask.apl.washington.edu> wrote: > >> > >> How did you arrive at the conclusion that this has anything to do with > >> the specific compiler? From these errors, I think it is more likely > >> something in Qt5 that is erroneously convinced that those qt_memfillXY > >> functions exist. Or they get referenced, but not compiled at all, for > >> some reason. > >> > > > > If I have "CFLAGS+= -march=i686 -mmmx -msse" in /etc/make.conf > > qt5-gui builds without issue. If I add -msse2 to CFLAGS, then > > the build dies. > > > > So, either clang is miscompiling qt5-gui with -mmse2 or the > > qt5-gui port is being too smart for its own good. > > That lead to an old memory of getting results like ((armv6 > time frame I think, before the armv7 addition to FreeBSD): > > image/qimage.cpp:(.text+0x1e14): undefined reference to > `qt_memfill32(unsigned int*, unsigned int, int)' > image/qimage.cpp:(.text+0x1f34): undefined reference to > `qt_memfill32(unsigned int*, unsigned int, int)' > > where it turned out that arm NEON was not supported by various > parts of qt5. > It is definitely some problem between clang and the qt5-gui port. It seems qt5-gui tries to auto-detect sse2. Don't know if qt5-gui has a bogus auto-detect code, clang miscompiles the auto-detect code, or FreeBSD is lying about the features of my cpu (although x86info says it found sse2). In poking around the qt5-gui sources, I found that configure can be given a -sse2 argument. I tried to force sse2, but I'm seeing qt5-gui is doing % find qtbase-everywhere-src-5.12.0 -name config.\* | xargs grep -i sse2 qtbase-everywhere-src-5.12.0/config.log:Command line: -no-eglfs -sse2 -no-evdev -no-libudev -system-harfbuzz -c++std c++14 -opensource -confirm-license -no-pch -prefix /usr/local -bindir /usr/local/lib/qt5/bin -headerdir /usr/local/include/qt5 -libdir /usr/local/lib/qt5 -plugindir /usr/local/lib/qt5/plugins -importdir /usr/local/lib/qt5/imports -datadir /usr/local/share/qt5 -docdir /usr/local/share/doc/qt5 -translationdir /usr/local/share/qt5/translations -sysconfdir /usr/local/etc/xdg -nomake examples -nomake tests -platform freebsd-clang -archdatadir /usr/local/lib/qt5 -libexecdir /usr/local/libexec/qt5 -qmldir /usr/local/lib/qt5/qml -examplesdir /usr/local/share/examples/qt5 -testsdir /usr/local/share/qt5/tests -no-sse2 -no-use-gold-linker -recheck-all -release -no-separate-debug-info qtbase-everywhere-src-5.12.0/config.opt:-sse2 qtbase-everywhere-src-5.12.0/config.opt:-no-sse2 Note my -sse2 is followed by a -no-sse2! -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On 2019-Feb-10, at 10:46, Steve Kargl wrote: > > On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: >> On 10 Feb 2019, at 06:00, Steve Kargl >> wrote: >> >> How did you arrive at the conclusion that this has anything to do with >> the specific compiler? From these errors, I think it is more likely >> something in Qt5 that is erroneously convinced that those qt_memfillXY >> functions exist. Or they get referenced, but not compiled at all, for >> some reason. >> > > If I have "CFLAGS+= -march=i686 -mmmx -msse" in /etc/make.conf > qt5-gui builds without issue. If I add -msse2 to CFLAGS, then > the build dies. > > So, either clang is miscompiling qt5-gui with -mmse2 or the > qt5-gui port is being too smart for its own good. That lead to an old memory of getting results like ((armv6 time frame I think, before the armv7 addition to FreeBSD): image/qimage.cpp:(.text+0x1e14): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' image/qimage.cpp:(.text+0x1f34): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' where it turned out that arm NEON was not supported by various parts of qt5. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216816 There is some more explicit error message text in the closed duplicate: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217278 qt5-webkit produced an error message: alpha2/Source/JavaScriptCore/assembler/MacroAssemblerARM.h:33: /wrkdirs/usr/ports/www/qt5-webkit/work/qtwebkit-5.212.0-alpha2/Source/JavaScriptCore/assembler/ARMAssembler.h:1132:2: error: "The cacheFlush support is missing on this platform." #error "The cacheFlush support is missing on this platform." ^ 1 error generated. Eventually patch(s) enabled arm NEON support and the problem disappeared. This suggests that that things missing in your context were simply never built, due to qt5 not having the the matching optimized code for the mode --or at least no building it. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > How did you arrive at the conclusion that this has anything to do with > the specific compiler? From these errors, I think it is more likely > something in Qt5 that is erroneously convinced that those qt_memfillXY > functions exist. Or they get referenced, but not compiled at all, for > some reason. > If I have "CFLAGS+= -march=i686 -mmmx -msse" in /etc/make.conf qt5-gui builds without issue. If I add -msse2 to CFLAGS, then the build dies. So, either clang is miscompiling qt5-gui with -mmse2 or the qt5-gui port is being too smart for its own good. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > > world and kernel without a problem. If I try to build > > x11-toolkits/qt5-gui the build dies with > > Might be related to https://bugs.llvm.org/show_bug.cgi?id=35678 -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > > world and kernel without a problem. If I try to build > > x11-toolkits/qt5-gui the build dies with > > > > How did you arrive at the conclusion that this has anything to do with > the specific compiler? From these errors, I think it is more likely > something in Qt5 that is erroneously convinced that those qt_memfillXY > functions exist. Or they get referenced, but not compiled at all, for > some reason. > Of course, with llvm/clang/clang++, there appears to be *no documentation* on the set of valid inputs for -march. If I do 'cc -c --verbose a.c' on my FreeBSD laptop, I see -target-cpu i486 among the cc1 options. This is a rather pessimistic choice for a Core2 Duo cpu. If I do 'cc -c --verbose -march=native.c', I see -target-cpu core2 -target-feature +sse2 -target-feature +cx16 -target-feature +sahf -target-feature -tbm -target-feature -avx512ifma -target-feature -sha -target-feature -gfni -target-feature -fma4 -target-feature -vpclmulqdq -target-feature -prfchw -target-feature -bmi2 -target-feature -cldemote -target-feature -fsgsbase -target-feature -ptwrite -target-feature -xsavec -target-feature -popcnt -target-feature -aes -target-feature -avx512bitalg -target-feature -movdiri -target-feature -xsaves -target-feature -avx512er -target-feature -avx512vnni -target-feature -avx512vpopcntdq -target-feature -pconfig -target-feature -clwb -target-feature -avx512f -target-feature -clzero -target-feature -pku -target-feature +mmx -target-feature -lwp -target-feature -rdpid -target-feature -xop -target-feature -rdseed -target-feature -waitpkg -target-feature -movdir64b -target-feature -sse4a -target-feature -avx512bw -target-feature -clflushopt -target-feature -xsave -target-feature -avx512vbmi2 -target-feature -avx512vl -target-feature -invpcid -target-feature -avx512cd -target-feature -avx -target-feature -vaes -target-feature -rtm -target-feature -fma -target-feature -bmi -target-feature -rdrnd -target-feature -mwaitx -target-feature -sse4.1 -target-feature -sse4.2 -target-feature -avx2 -target-feature -wbnoinvd -target-feature +sse -target-feature -lzcnt -target-feature -pclmul -target-feature -prefetchwt1 -target-feature -f16c -target-feature +ssse3 -target-feature -sgx -target-feature -shstk -target-feature +cmov -target-feature -avx512vbmi -target-feature -movbe -target-feature -xsaveopt -target-feature -avx512dq -target-feature -adx -target-feature -avx512pf -target-feature +sse3 My conclusion "Wrong code bug in llvm/clang". -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > I have > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386 > > > > % dmesg | more > > ... > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > > 7.0.1) > > VT(vga): resolution 640x480 > > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class > > CPU) > > Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > > > Features=0xbfebfbff > > Features2=0xe3bd > > AMD Features=0x2000 > > AMD Features2=0x1 > > VT-x: (disabled in BIOS) HLT,PAUSE > > TSC: P-state invariant, performance statistics > > ... > > > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > > world and kernel without a problem. If I try to build > > x11-toolkits/qt5-gui the build dies with > > > > c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined > > -Wl,--version-script,QtGui.version -pthread -Wl,-rpath,/usr/local/lib/qt5 > > -shared -Wl,-Bsymbolic-functions > > -Wl,--dynamic-list,/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src- > > 5.12.0/src/gui/QtGui.dynlist -Wl,-soname,libQt5Gui.so.5 -o > > libQt5Gui.so.5.12.0 > > > > (long list of *.o files) > > > > -L/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.12.0/lib > > -L/lib > > -L/usr/local/lib/qt5 -lQt5Core -L/usr/local/lib -lGL -lpng16 -lharfbuzz -lz > > .obj/qimage.o: In function `QImage::fill(unsigned int)': > > qimage.cpp:(.text+0x2442): undefined reference to `qt_memfill32(unsigned > > int*, > > unsigned int, int)' > > qimage.cpp:(.text+0x2477): undefined reference to `qt_memfill16(unsigned > > short*, unsigned short, int)' > > How did you arrive at the conclusion that this has anything to do with > the specific compiler? From these errors, I think it is more likely > something in Qt5 that is erroneously convinced that those qt_memfillXY > functions exist. Or they get referenced, but not compiled at all, for > some reason. > If I have "CFLAGS+=-march=native -mtune=native" in /etc/make.conf, the building of qt5-gui dies. If I remove "CFLAGS+=-march=native -mtune=native" from /etc/make.conf, the bulding of qt5-gui completes without incidence. The only difference in command lines is the inclusion/exclusion of -march=native -mtune=native. I came to my conclusion by noticing noticing argv[0], argv[4] and argv[5] below. c++ -c -O2 -pipe -march=native -mtune=native -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O3 -std=c++1y -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wdate-time -Winconsistent-missing-override -pthread -fPIC -DQT_ACCESSIBILITY -DQT_DBUS -DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG -DQT_OPENGL -DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWHELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I../../include -I../../include/QtGui -I../../include/QtGui/5.12.0 -I../../include/QtGui/5.12.0/QtGui -I.tracegen -I/usr/local/include -I/usr/local/include/libdrm -I/usr/local/include/qt5/QtCore/5.12.0 -I/usr/local/include/qt5/QtCore/5.12.0/QtCore -I/usr/local/include/qt5 -I/usr/local/include/qt5/QtCore -I.moc -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o .obj/qdrawhelper.o painting/qdrawhelper.cpp -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang broken on current?
On 10 Feb 2019, at 06:00, Steve Kargl wrote: > > I have > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386 > > % dmesg | more > ... > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > VT(vga): resolution 640x480 > CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class > CPU) > Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x2000 > AMD Features2=0x1 > VT-x: (disabled in BIOS) HLT,PAUSE > TSC: P-state invariant, performance statistics > ... > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > world and kernel without a problem. If I try to build > x11-toolkits/qt5-gui the build dies with > > c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined > -Wl,--version-script,QtGui.version -pthread -Wl,-rpath,/usr/local/lib/qt5 > -shared -Wl,-Bsymbolic-functions > -Wl,--dynamic-list,/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src- > 5.12.0/src/gui/QtGui.dynlist -Wl,-soname,libQt5Gui.so.5 -o libQt5Gui.so.5.12.0 > > (long list of *.o files) > > -L/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.12.0/lib -L/lib > -L/usr/local/lib/qt5 -lQt5Core -L/usr/local/lib -lGL -lpng16 -lharfbuzz -lz > .obj/qimage.o: In function `QImage::fill(unsigned int)': > qimage.cpp:(.text+0x2442): undefined reference to `qt_memfill32(unsigned int*, > unsigned int, int)' > qimage.cpp:(.text+0x2477): undefined reference to `qt_memfill16(unsigned > short*, unsigned short, int)' How did you arrive at the conclusion that this has anything to do with the specific compiler? From these errors, I think it is more likely something in Qt5 that is erroneously convinced that those qt_memfillXY functions exist. Or they get referenced, but not compiled at all, for some reason. -Dimitry signature.asc Description: Message signed with OpenPGP
