The trick I like, when I don't need quite so much detail as the guide provides, is to simply remember to look in 2 places for header files, /usr/include AND /usr/lib/gcc. From /usr/lib/gcc, it is easy to find one's way down to the include directory for intrinsics. The trick seems to cover both Ubuntu and RedHat and I don't have to remember very much.
Burt On Tue, Feb 20, 2018 at 3:26 AM, Ray Kinsella <m...@ashroe.eu> wrote: > > The Intel intrinsics guide are a handy reference for this kind of thing. > > https://software.intel.com/sites/landingpage/IntrinsicsGuide > /#text=_mm_testz_si128 > > You need to trim the additional underscore off the intrinsic to look it up. > > Ray K > > On 20/02/2018 02:52, Florin Coras wrote: > >> Okay, I take that back. Google tells me these are SSE4 intrinsics, not >> SSE2 … >> >> Florin >> >> On Feb 19, 2018, at 5:50 PM, Ed Kern <e...@cisco.com <mailto:e...@cisco.com>> >>> wrote: >>> >>> yes…it was considered a trivial rebase…. >>> >>> IF that was the case then ill take the wrap for that one wrt it getting >>> a +1… >>> >>> in a nutshell.. patch 2 failed…got its -1 ok fine. >>> >>> someone came and did a trivial rebase…IF those last three jobs docs, >>> csit-virl and whatever were also not set to run on trivial rebase >>> the -1 would have remained. BUT since those jobs triggered and passed >>> (csit-virl passed since thats built/run for ubuntu) it got a +1 >>> based on that. >>> >>> >>> I have no idea why the merge happened though…. >>> >>> Ed >>> >>> >>> >>> On Feb 19, 2018, at 6:37 PM, Florin Coras <fcoras.li...@gmail.com >>>> <mailto:fcoras.li...@gmail.com>> wrote: >>>> >>>> That’s .. interesting. Patch set 3 didn’t run all the jobs. Any idea >>>> why that would happen? >>>> >>>> Instead of reverting the patch, here’s a hammer-based attempt at >>>> solving the problem [1]. Damjan, feel free to propose a prettier solution >>>> :) >>>> >>>> Florin >>>> >>>> [1] https://gerrit.fd.io/r/#/c/10660/ >>>> >>>> On Feb 19, 2018, at 5:09 PM, Ed Kern <e...@cisco.com <mailto: >>>>> e...@cisco.com>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Feb 19, 2018, at 2:47 PM, Jon Loeliger <j...@netgate.com <mailto: >>>>>> j...@netgate.com>> wrote: >>>>>> >>>>>> Hey hey hey, >>>>>> >>>>>> I tried to build a variant of vppsb and failed miserably >>>>>> for lack of the __mm_testz_si128 symbol. >>>>>> >>>>>> >>>>> Wont make you feel better but my centos builds have been rolling and >>>>> croaking over this for a few hours as well... >>>>> >>>>> >>>>> From whence does that arrive on my doorstep? >>>>>> >>>>> >>>>> my best guess is that it came in with >>>>> c6969b55e40613479183141c01f057f9253f17a8 >>>>> >>>>> aka >>>>> >>>>> https://gerrit.fd.io/r/#/c/10636/ >>>>> >>>>> >>>>> Then again im still scratching my head on how this even got in since >>>>> this failed verification on patch 2. >>>>> Then im guessing it got the +1 because it was deemed a trivial rebase >>>>> so only a subset of jobs (aka not centos) fired. >>>>> >>>>> But even the merge job for centos failed…and I thought (obviously >>>>> incorrectly) that those had to have success for the >>>>> merge to take place. >>>>> >>>>> Ed >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I'm trying to figure out if vppsb needs to #define something new, >>>>>> or #include something first, or if my system is suddenly missing >>>>>> something assumed to be present and VPP cleverly allowed for >>>>>> it to be missing while vppsb was less so? >>>>>> >>>>>> Thanks, >>>>>> jdl >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ```libtool: compile: gcc -DPACKAGE_NAME=\"netlink\" >>>>>> -DPACKAGE_TARNAME=\"netlink\" "-DPACKAGE_VERSION=\"1.0.1-21~g888408a\"" >>>>>> "-DPACKAGE_STRING=\"netlink 1.0.1-21~g888408a\"" -DPACKAGE_BUGREPORT=\"\" >>>>>> -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >>>>>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 >>>>>> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 >>>>>> -DHAVE_UNISTD_H=1 >>>>>> -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"netlink\" >>>>>> "-DVERSION=\"1.0.1-21~g888408a\"" -I. -Wall -fstack-protector -fPIC >>>>>> -Werror -g -DFORTIFY_SOURCE=2 -O2 -I/home/jdl/work/vpp/build-roo >>>>>> t/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/ >>>>>> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>>>>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >>>>>> -m64 -mtune=generic -c librtnl/netns.c -fPIC -DPIC -o >>>>>> librtnl/.libs/netns.o >>>>>> In file included from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/vector.h:262:0, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/mheap_bootstrap.h:47, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/mem.h:47, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/vec.h:42, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/format.h:44, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/elf.h:41, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vppinfra/elf_clib.h:41, >>>>>> from /home/jdl/work/vpp/build-root/ >>>>>> rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/inclu >>>>>> de/vlib/vlib.h:44, >>>>>> from ./librtnl/netns.h:19, >>>>>> from librtnl/netns.c:16: >>>>>> /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-roo >>>>>> t/install-vpp-native/vpp/include/vppinfra/vector_sse2.h: In function >>>>>> 'u8x16_is_all_zero': >>>>>> /home/jdlwork/vpp/build-root/rpmbuild/vpp-18.04.0/build-root >>>>>> /install-vpp-native/vpp/include/vppinfra/vector_sse2.h:552:3: error: >>>>>> implicit declaration of function '_mm_testz_si128' >>>>>> [-Werror=implicit-function-declaration] >>>>>> return _mm_testz_si128 ((__m128i) x, (__m128i) x); >>>>>> ^ >>>>>> cc1: all warnings being treated as errors >>>>>> ``` >>>>>> >>>>> >>>>> >>>> >>> >> >> > > >
