[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
On Tue, Aug 23, 2016 at 06:36:57PM +0200, Thomas Monjalon wrote: > After rebasing the patchset, the compilation of each patch seems good. > But the new checks fail with clang: > rte_memcpy.h:814:2: error: > implicit declaration of function '_mm_alignr_epi8' is invalid > in C99 This is an unfortunate false positive. mmintrin.h and other x86 intrinsics headers files define their macros and types only if compiled with the right -march or CPU flags options. check-includes.sh does not provide any of those and relies on whatever the C compiler falls back to by default. The problem is actually that we haven't implemented any fallback in DPDK for such cases. In the meantime it can be worked around like this: EXTRA_CFLAGS=-march=core2 EXTRA_CXXFLAGS=-march=core2 ./scripts/check-includes.sh > Other comments about the script: > - it is too long (can it be parallelized?) > - it does not stop printing errors after the first one Addressing these concerns would require a complete redesign of that script as a Makefile, and even then it would most likely end up taking too long when there are no errors (all headers end up being checked). I've removed it from test-build.sh, people will have to run it manually like check-git-log.sh, updated v5 accordingly. -- Adrien Mazarguil 6WIND
[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
After rebasing the patchset, the compilation of each patch seems good. But the new checks fail with clang: rte_memcpy.h:814:2: error: implicit declaration of function '_mm_alignr_epi8' is invalid in C99 Other comments about the script: - it is too long (can it be parallelized?) - it does not stop printing errors after the first one
[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
2016-07-15 22:03, Bruce Richardson: > On Wed, Jul 13, 2016 at 03:02:37PM +0200, Adrien Mazarguil wrote: > > DPDK uses GNU C language extensions in most of its code base. This is fine > > for internal source files whose compilation flags are controlled by DPDK, > > however user applications that use exported "public" headers may experience > > compilation failures when enabling strict error/standard checks (-std and > > -pedantic for instance). > > > > Exported headers are installed system-wide and must be as clean as possible > > so applications do not have to resort to workarounds. > > > > This patchset affects exported headers only, compilation problems are > > addressed as follows: > > > > - Adding the __extension__ keyword to nonstandard constructs (same method > > as existing libraries when there is no other choice). > > - Adding the __extension__ keyword to C11 constructs to remain compatible > > with pure C99. > > - Adding missing includes so exported files can be included out of order > > and on their own. > > - Fixing GNU printf-like variadic macros as there is no magic keyword for > > these. > > > > Having upgraded to Fedora 24, I'm seeing quite a few errors compiling with gcc > 6.1.1 in debug mode. Applying this patchset seems to really cut down on those > errors, so may need to be applied for 16.07 release. It is reducing the number of warnings but do not completely solve it, right? It is a very good patchset but it needs to be validated with a large number of compilers and options. That's why I think it is too late for 16.07.
[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
On Fri, Jul 15, 2016 at 10:03:02PM +0100, Bruce Richardson wrote: > On Wed, Jul 13, 2016 at 03:02:37PM +0200, Adrien Mazarguil wrote: > > DPDK uses GNU C language extensions in most of its code base. This is fine > > for internal source files whose compilation flags are controlled by DPDK, > > however user applications that use exported "public" headers may experience > > compilation failures when enabling strict error/standard checks (-std and > > -pedantic for instance). > > > > Exported headers are installed system-wide and must be as clean as possible > > so applications do not have to resort to workarounds. > > > > This patchset affects exported headers only, compilation problems are > > addressed as follows: > > > > - Adding the __extension__ keyword to nonstandard constructs (same method > > as existing libraries when there is no other choice). > > - Adding the __extension__ keyword to C11 constructs to remain compatible > > with pure C99. > > - Adding missing includes so exported files can be included out of order > > and on their own. > > - Fixing GNU printf-like variadic macros as there is no magic keyword for > > these. > > > > Having upgraded to Fedora 24, I'm seeing quite a few errors compiling with gcc > 6.1.1 in debug mode. Applying this patchset seems to really cut down on those > errors, so may need to be applied for 16.07 release. > > The remaining error I'm seeing is, in mlx drivers, complaints about the > pedantic flag (the flag which I think was causing all the other errors to be > triggered too): > > error: `-pedantic' is not an option that controls warnings Saw this as well with GCC 6, I've planned to drop these #pragmas as soon as possible after this series is applied, however there is some work left to do on the libibverbs side before that. > For this set though, I don't see any new errors introduced into gcc or clang > builds for the libs or drivers, and a number of errors cleared, so: > > Tested-by: Bruce Richardson Thanks for testing. -- Adrien Mazarguil 6WIND
[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
On Wed, Jul 13, 2016 at 03:02:37PM +0200, Adrien Mazarguil wrote: > DPDK uses GNU C language extensions in most of its code base. This is fine > for internal source files whose compilation flags are controlled by DPDK, > however user applications that use exported "public" headers may experience > compilation failures when enabling strict error/standard checks (-std and > -pedantic for instance). > > Exported headers are installed system-wide and must be as clean as possible > so applications do not have to resort to workarounds. > > This patchset affects exported headers only, compilation problems are > addressed as follows: > > - Adding the __extension__ keyword to nonstandard constructs (same method > as existing libraries when there is no other choice). > - Adding the __extension__ keyword to C11 constructs to remain compatible > with pure C99. > - Adding missing includes so exported files can be included out of order > and on their own. > - Fixing GNU printf-like variadic macros as there is no magic keyword for > these. > Having upgraded to Fedora 24, I'm seeing quite a few errors compiling with gcc 6.1.1 in debug mode. Applying this patchset seems to really cut down on those errors, so may need to be applied for 16.07 release. The remaining error I'm seeing is, in mlx drivers, complaints about the pedantic flag (the flag which I think was causing all the other errors to be triggered too): error: `-pedantic' is not an option that controls warnings For this set though, I don't see any new errors introduced into gcc or clang builds for the libs or drivers, and a number of errors cleared, so: Tested-by: Bruce Richardson Regards, /Bruce
[dpdk-dev] [PATCH v4 00/10] Fix build errors related to exported headers
DPDK uses GNU C language extensions in most of its code base. This is fine for internal source files whose compilation flags are controlled by DPDK, however user applications that use exported "public" headers may experience compilation failures when enabling strict error/standard checks (-std and -pedantic for instance). Exported headers are installed system-wide and must be as clean as possible so applications do not have to resort to workarounds. This patchset affects exported headers only, compilation problems are addressed as follows: - Adding the __extension__ keyword to nonstandard constructs (same method as existing libraries when there is no other choice). - Adding the __extension__ keyword to C11 constructs to remain compatible with pure C99. - Adding missing includes so exported files can be included out of order and on their own. - Fixing GNU printf-like variadic macros as there is no magic keyword for these. Changes in v4: - Dropped "lib: work around structs with no members" patch, now addressed as a separate issue outside of this patchset by "mempool: fix empty structure definition". - Fixed remaining compilation error with ICC reported by Ferruh. Finally settled on using the __extension__ keyword directly in struct rte_pipeline_table_entry as converting it to a standard flexible array may break existing programs. Changes in v3: - Fixed compilation issue on ARM and POWER8 due to missing parenthesis. - Added bit-field fix for rte_kni.h. Changes in v2: - Rebased on top of the current HEAD. - Added script to check headers automatically (check-includes.sh), for both C and C++ compilation. - Updated test-build.sh to use it. - Fixed consistency of new #include directives, now inside extern "C" blocks for files that already do that (Jan, fixing these was too much work for this patchset so I settled on this solution in the meantime). - Updated headlines to address check-git-log.sh complaints. Adrien Mazarguil (10): lib: work around braced-groups within expressions lib: work around large enum values lib: use C99 syntax for zero-size arrays lib: work around nonstandard bit-fields lib: work around unnamed structs/unions lib: add missing include dependencies lib: work around forward reference to enum types lib: remove named variadic macros in exported headers lib: hide static functions never defined scripts: check compilation of exported header files MAINTAINERS | 1 + lib/librte_acl/rte_acl.h| 2 +- lib/librte_cfgfile/rte_cfgfile.h| 2 + lib/librte_cmdline/cmdline.h| 1 + lib/librte_cmdline/cmdline_parse_portlist.h | 1 + lib/librte_cmdline/cmdline_socket.h | 3 + lib/librte_cryptodev/rte_crypto.h | 2 + lib/librte_cryptodev/rte_crypto_sym.h | 3 + lib/librte_cryptodev/rte_cryptodev.h| 40 ++- lib/librte_cryptodev/rte_cryptodev_pmd.h| 6 +- .../common/include/arch/arm/rte_byteorder.h | 2 + .../common/include/arch/arm/rte_memcpy_32.h | 3 +- .../common/include/arch/arm/rte_prefetch_32.h | 1 + .../common/include/arch/arm/rte_prefetch_64.h | 1 + .../common/include/arch/arm/rte_vect.h | 1 + .../common/include/arch/ppc_64/rte_atomic.h | 1 + .../common/include/arch/ppc_64/rte_byteorder.h | 1 + .../common/include/arch/ppc_64/rte_cycles.h | 2 + .../common/include/arch/ppc_64/rte_memcpy.h | 3 +- .../common/include/arch/ppc_64/rte_prefetch.h | 1 + .../common/include/arch/x86/rte_atomic.h| 2 + .../common/include/arch/x86/rte_atomic_32.h | 9 + .../common/include/arch/x86/rte_atomic_64.h | 8 + .../common/include/arch/x86/rte_byteorder.h | 2 + .../common/include/arch/x86/rte_byteorder_32.h | 7 + .../common/include/arch/x86/rte_byteorder_64.h | 7 + .../common/include/arch/x86/rte_cycles.h| 2 + .../common/include/arch/x86/rte_memcpy.h| 4 +- .../common/include/arch/x86/rte_prefetch.h | 1 + .../common/include/arch/x86/rte_rtm.h | 1 + .../common/include/arch/x86/rte_vect.h | 8 +- .../common/include/generic/rte_atomic.h | 1 + .../common/include/generic/rte_byteorder.h | 2 + .../common/include/generic/rte_cpuflags.h | 3 + .../common/include/generic/rte_memcpy.h | 4 + lib/librte_eal/common/include/rte_common.h | 22 +- lib/librte_eal/common/include/rte_devargs.h | 1 + lib/librte_eal/common/include/rte_eal.h | 1 + lib/librte_eal/common/include/rte_interrupts.h | 2 + lib/librte_eal/common/include/rte_memory.h | 4 + lib/librte_eal/common/include/rte_memzone.h | 2 + lib/librte_eal/common/include/rte_time.h| 8 + lib/librte_eal/common/include/rte_version.h | 1 + .../eal/include/exec-env/rte_interrupts.h | 1 +
