clang broken on current?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

clang broken on current?

Steve Kargl
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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20000000<LM>
  AMD Features2=0x1<LAHF>
  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)'
qimage.cpp:(.text+0x268f): undefined reference to `qt_memfill32(unsigned int*,
unsigned int, int)'
qimage.cpp:(.text+0x26cf): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
.obj/qcompositionfunctions.o: In function `comp_func_solid_Clear(unsigned
int*, int, unsigned int, unsigned int)':
qcompositionfunctions.cpp:(.text+0x33): undefined reference to
`qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qcompositionfunctions.o: In function `comp_func_Clear(unsigned int*,
unsigned int const*, int, unsigned int)':
qcompositionfunctions.cpp:(.text+0x293): undefined reference to
`qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qcompositionfunctions.o: In function `comp_func_solid_Source(unsigned
int*, int, unsigned int, unsigned int)':
qcompositionfunctions.cpp:(.text+0x4f1): undefined reference to
`qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qcompositionfunctions.o: In function `comp_func_solid_SourceOver(unsigned
int*, int, unsigned int, unsigned int)':
qcompositionfunctions.cpp:(.text+0xc4b): undefined reference to
`qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qcompositionfunctions.o: In function `rasterop_solid_NotSource(unsigned
int*, int, unsigned int, unsigned int)':
qcompositionfunctions.cpp:(.text+0x2da8b): undefined reference to
`qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qcompositionfunctions.o:qcompositionfunctions.cpp:(.text+0x2e603): more
undefined references to `qt_memfill32(unsigned int*, unsigned int, int)'
follow
.obj/qdrawhelper.o: In function `blend_color_rgb16(int, QT_FT_Span_ const*,
void*)':
qdrawhelper.cpp:(.text+0x14968): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
.obj/qdrawhelper.o: In function `qt_bitmapblit_quint16(QRasterBuffer*, int,
int, QRgba64 const&, unsigned char const*, int, int, int)':
qdrawhelper.cpp:(.text+0x14ea1): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
qdrawhelper.cpp:(.text+0x14eed): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
qdrawhelper.cpp:(.text+0x14f3e): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
qdrawhelper.cpp:(.text+0x14f8f): undefined reference to `qt_memfill16(unsigned
short*, unsigned short, int)'
.obj/qdrawhelper.o:qdrawhelper.cpp:(.text+0x14fde): more undefined references
to `qt_memfill16(unsigned short*, unsigned short, int)' follow
.obj/qdrawhelper.o: In function `qt_rectfill_rgba(QRasterBuffer*, int, int,
int, int, QRgba64 const&)':
qdrawhelper.cpp:(.text+0x16b7b): undefined reference to `qt_memfill32(unsigned
int*, unsigned int, int)'
qdrawhelper.cpp:(.text+0x16b9f): undefined reference to `qt_memfill32(unsigned
int*, unsigned int, int)'
.obj/qdrawhelper.o: In function `qt_rectfill_nonpremul_rgba(QRasterBuffer*,
int, int, int, int, QRgba64 const&)':
qdrawhelper.cpp:(.text+0x16cfc): undefined reference to `qt_memfill32(unsigned
int*, unsigned int, int)'
qdrawhelper.cpp:(.text+0x16d21): undefined reference to `qt_memfill32(unsigned
int*, unsigned int, int)'
.obj/qdrawhelper.o: In function
`_ZL17qt_rectfill_rgb30IL12QtPixelOrder1EEvP13QRasterBufferiiiiRK7QRgba64':
qdrawhelper.cpp:(.text+0x17054): undefined reference to `qt_memfill32(unsigned
int*, unsigned int, int)'
.obj/qdrawhelper.o:qdrawhelper.cpp:(.text+0x1707c): more undefined references
to `qt_memfill32(unsigned int*, unsigned int, int)' follow
.obj/qdrawhelper.o: In function `_GLOBAL__sub_I_qdrawhelper.cpp':
qdrawhelper.cpp:(.text+0x2cfe7): undefined reference to
`qt_bitmapblit32_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned char
const*, int, int, int)'
qdrawhelper.cpp:(.text+0x2cfff): undefined reference to
`qt_bitmapblit16_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned char
const*, int, int, int)'
qdrawhelper.cpp:(.text+0x2d00b): undefined reference to
`qt_bitmapblit8888_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned
char const*, int, int, int)'
qdrawhelper.cpp:(.text+0x2d023): undefined reference to
`qt_scale_image_argb32_on_argb32_sse2(unsigned char*, int, unsigned char
const*, int, int, QRectF const&, QRectF const&, QRect const&, int)'
qdrawhelper.cpp:(.text+0x2d047): undefined reference to
`qt_blend_rgb32_on_rgb32_sse2(unsigned char*, int, unsigned char const*, int,
int, int, int)'
qdrawhelper.cpp:(.text+0x2d05f): undefined reference to
`qt_blend_argb32_on_argb32_sse2(unsigned char*, int, unsigned char const*,
int, int, int, int)'
qdrawhelper.cpp:(.text+0x2d089): undefined reference to
`qt_fetch_radial_gradient_sse2(unsigned int*, Operator const*, QSpanData
const*, int, int, int)'
qdrawhelper.cpp:(.text+0x2d095): undefined reference to
`comp_func_SourceOver_sse2(unsigned int*, unsigned int const*, int, unsigned
int)'
qdrawhelper.cpp:(.text+0x2d0a3): undefined reference to
`comp_func_solid_SourceOver_sse2(unsigned int*, int, unsigned int, unsigned
int)'
qdrawhelper.cpp:(.text+0x2d0b1): undefined reference to
`comp_func_Source_sse2(unsigned int*, unsigned int const*, int, unsigned int)'
qdrawhelper.cpp:(.text+0x2d0ba): undefined reference to
`comp_func_Plus_sse2(unsigned int*, unsigned int const*, int, unsigned int)'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Removing the additional of -march=native -mtune=native fixes the
build.
--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Dimitry Andric-4
On 10 Feb 2019, at 06:00, Steve Kargl <[hidden email]> 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>  Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
>  AMD Features=0x20000000<LM>
>  AMD Features2=0x1<LAHF>
>  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 (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:

> On 10 Feb 2019, at 06:00, Steve Kargl <[hidden email]> 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >  Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
> >  AMD Features=0x20000000<LM>
> >  AMD Features2=0x1<LAHF>
> >  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=0x050000 -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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
In reply to this post by Dimitry Andric-4
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:

> On 10 Feb 2019, at 06:00, Steve Kargl <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
In reply to this post by Dimitry Andric-4
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
In reply to this post by Dimitry Andric-4
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

freebsd-toolchain mailing list


On 2019-Feb-10, at 10:46, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:

>
> On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
>> On 10 Feb 2019, at 06:00, Steve Kargl <sgk at 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.

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)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote:

>
> On 2019-Feb-10, at 10:46, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> >
> > On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> >> On 10 Feb 2019, at 06:00, Steve Kargl <sgk at 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

Steve Kargl
In reply to this post by freebsd-toolchain mailing list
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: <none>)

*** 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 .................................. <none>

*** That's not good. ***

    AVX .................................. <none>
    AVX512 ............................... <none>
    Other x86 ............................ RDRAND
    Intrinsics without -mXXX option ...... yes
  Build parts ............................ libs tools


--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

freebsd-toolchain mailing list
In reply to this post by Steve Kargl


On 2019-Feb-10, at 11:24, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:

> On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote:
>>
>> On 2019-Feb-10, at 10:46, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
>>>
>>> On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
>>>> On 10 Feb 2019, at 06:00, Steve Kargl <sgk at 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: [hidden email]
Approved by: maintainer timeout (2 weeks)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

freebsd-toolchain mailing list
In reply to this post by Steve Kargl


On 2019-Feb-10, at 11:34, Steve Kargl <sgk at troutmask.apl.washington.edu> 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: <none>)
>
> *** 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 .................................. <none>
>
> *** That's not good. ***
>
>    AVX .................................. <none>
>    AVX512 ............................... <none>
>    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)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: clang broken on current?

freebsd-toolchain mailing list


On 2019-Feb-10, at 12:02, Mark Millard <marklmi at yahoo.com> wrote:



> On 2019-Feb-10, at 11:34, Steve Kargl <sgk at troutmask.apl.washington.edu> 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: <none>)
>>
>> *** 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 .................................. <none>
>>
>> *** That's not good. ***
>>
>>   AVX .................................. <none>
>>   AVX512 ............................... <none>
>>   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)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"