search for: compiler_typ

.../libip6tc.h:5, from /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-next/iptables-1.8.1/libiptc/libip6tc.c:30: /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-next/linux-4.20-rc1/include/linux/compiler_types.h:199:2: warning: redundant redeclaration of '__maybe_unused' [-Wredundant-decls] __maybe_unused notrace ^~~~~~~~~~~~~~ /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel-next/iptables-1.8.1/libiptc/libiptc.c:268:8: note: in expansion of macro...

...from arch/mips/include/asm/bitops.h:20, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/linux/mlx5/driver.h:36, from drivers/vdpa/mlx5/core/resources.c:4: >> include/linux/compiler_types.h:135:35: error: invalid use of undefined type 'struct mlx5_ifc_create_uctx_out_bits' 135 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) | ^~~~~~~~~~~~~~~~~~ include/uapi/linux/byteorder/big_endian.h:40:51: note: in definiti...

...ps.h:29, from ./include/linux/kernel.h:12, from ./include/linux/list.h:9, from ./include/linux/module.h:12, from drivers/vdpa/mlx5/net/main.c:4: drivers/vdpa/mlx5/net/main.c: In function ?required_caps_supported?: ././include/linux/compiler_types.h:129:35: error: ?struct mlx5_ifc_device_virtio_emulation_cap_bits? has no member named ?event_mode? 129 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) | ^~~~~~~~~~~~~~~~~~ ./include/uapi/linux/swab.h:115:54: note: in definition of macro ?__...

...nel.h:12, > > from ./include/linux/list.h:9, > > from ./include/linux/module.h:12, > > from drivers/vdpa/mlx5/net/main.c:4: > > drivers/vdpa/mlx5/net/main.c: In function ?required_caps_supported?: > > ././include/linux/compiler_types.h:129:35: error: ?struct mlx5_ifc_device_virtio_emulation_cap_bits? has no member named ?event_mode? > > 129 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) > > | ^~~~~~~~~~~~~~~~~~ > > ./include/uapi/linux/swab.h:115:54: no...

...typ, fld))) | (((_v) & __mlx5_mask(typ, fld)) \ | ^~~~~~~~~~~~~~ drivers/vdpa/mlx5/net/mlx5_vnet.c:1192:2: note: in expansion of macro 'MLX5_SET' 1192 | MLX5_SET(rqtc, rqtc, list_q_type, MLX5_RQTC_LIST_Q_TYPE_VIRTIO_NET_Q); | ^~~~~~~~ include/linux/compiler_types.h:135:35: error: 'struct mlx5_ifc_rqtc_bits' has no member named 'list_q_type' 135 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) | ^~~~~~~~~~~~~~~~~~ include/uapi/linux/swab.h:115:54: note: in definition of macro ...

..., yes. It compiled, which was all I cared about :-) > > BTW, if we do that conversion, we should upgrade the checkpatch warn to > an error I suppose. More like remove altogether as __inline and __inline__ will no longer be #defined $ git grep -P 'define\s+__inline' include/linux/compiler_types.h:#define __inline__ inline include/linux/compiler_types.h:#define __inline inline

On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote: > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote: > > > > Anyway, with the below patch, I get: > > > > text data bss dec hex filename > > 17385183 5064780 1953892 24403855 1745f8f defconfig-build/vmlinux > > 17385678 5064780 1953892 24404350

On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote: > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote: > > > > Anyway, with the below patch, I get: > > > > text data bss dec hex filename > > 17385183 5064780 1953892 24403855 1745f8f defconfig-build/vmlinux > > 17385678 5064780 1953892 24404350

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- Changes from v2: https://lore.kernel.org/virtualization/20230410074929-mutt-send-email-mst at kernel.org/ - Fix a typo of commit title include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h

...gt; > index 2c51bccb97bb..1f3a15b954b9 100644 > > --- a/tools/virtio/linux/compiler.h > > +++ b/tools/virtio/linux/compiler.h > > @@ -2,6 +2,8 @@ > > #ifndef LINUX_COMPILER_H > > #define LINUX_COMPILER_H > > > > +#include "../../../include/linux/compiler_types.h" While I understand your need to not want to duplicate code, what in the world is this doing? Why not use the in-kernel compiler.h instead? Why are you copying loads of .h files into tools/virtio/? What is this for and why not just use the real files so you don't have to even attem...

...do not require ordering or that interact > + * with an explicit memory barrier or atomic instruction that provides the > + * required ordering. > + */ > +#ifndef __ASM_GENERIC_RWONCE_H > +#define __ASM_GENERIC_RWONCE_H > + > +#ifndef __ASSEMBLY__ > + > +#include <linux/compiler_types.h> > +#include <linux/kasan-checks.h> > +#include <linux/kcsan-checks.h> > + > +#include <asm/barrier.h> > + > +/* > + * Use __READ_ONCE() instead of READ_ONCE() if you do not require any > + * atomicity or dependency ordering guarantees. Note that thi...

....h > index 3b4eae5ac5e3..64da491936f7 100644 > --- a/include/linux/virtio_config.h > +++ b/include/linux/virtio_config.h > @@ -6,6 +6,7 @@ > #include <linux/bug.h> > #include <linux/virtio.h> > #include <linux/virtio_byteorder.h> > +#include <linux/compiler_types.h> > #include <uapi/linux/virtio_config.h> > > struct irq_affinity; > @@ -287,12 +288,57 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val) > return __cpu_to_virtio64(virtio_is_little_endian(vdev), val); > } > > +/* &gt...

....h > index 3b4eae5ac5e3..64da491936f7 100644 > --- a/include/linux/virtio_config.h > +++ b/include/linux/virtio_config.h > @@ -6,6 +6,7 @@ > #include <linux/bug.h> > #include <linux/virtio.h> > #include <linux/virtio_byteorder.h> > +#include <linux/compiler_types.h> > #include <uapi/linux/virtio_config.h> > > struct irq_affinity; > @@ -287,12 +288,57 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val) > return __cpu_to_virtio64(virtio_is_little_endian(vdev), val); > } > > +/* &gt...

...(~__mlx5_dw_mask(typ, fld))) | (((_v) & __mlx5_mask(typ, fld)) \ | ^~~~~~~~~~~~~~ drivers/vdpa/mlx5/core/mr.c:194:2: note: in expansion of macro 'MLX5_SET' 194 | MLX5_SET(create_mkey_in, in, uid, mvdev->res.uid); | ^~~~~~~~ include/linux/compiler_types.h:135:35: error: 'struct mlx5_ifc_create_mkey_in_bits' has no member named 'uid' 135 | #define __compiler_offsetof(a, b) __builtin_offsetof(a, b) | ^~~~~~~~~~~~~~~~~~ include/uapi/linux/swab.h:115:54: note: in definition of macro...

.... > #endif Yes, this is often done in the FreeBSD ports system, sometimes using the major version in the source, but more often in Makefiles, where the X.Y.Z version is condensed to just 'XY', as shown in https://github.com/freebsd/freebsd-ports/blob/master/lang/v8/Makefile#L36 : .if ${COMPILER_TYPE} == clang CXXFLAGS+= -Wno-nested-anon-types -Wno-unused-function -Wno-unused-private-field MAKE_ENV+= LINK=clang++ .if ${COMPILER_VERSION} >= 34 CXXFLAGS+= -Wno-unused-const-variable .if ${COMPILER_VERSION} >= 35 CXXFLAGS+= -Wno-tautological-undefined-compare .if ${COMPIL...

...is often done in the FreeBSD ports system, sometimes using the > major version in the source, but more often in Makefiles, where the X.Y.Z > version is condensed to just 'XY', as shown in https://github.com/freebsd/ > freebsd-ports/blob/master/lang/v8/Makefile#L36 : > > .if ${COMPILER_TYPE} == clang > CXXFLAGS+= -Wno-nested-anon-types -Wno-unused-function > -Wno-unused-private-field > MAKE_ENV+= LINK=clang++ > .if ${COMPILER_VERSION} >= 34 > CXXFLAGS+= -Wno-unused-const-variable > .if ${COMPILER_VERSION} >= 35 > CXXFLAGS+= -Wno-tautolog...

...> > > > So here's what I see ontop of 4.19-rc7: > > > > First marked the alternative asm() as inline and undeffed the "inline" > > keyword. I need to do that because of the funky games we do with > > "inline" redefinitions in include/linux/compiler_types.h. > > > > And Segher hinted at either doing: > > > > asm volatile inline(... > > > > or > > > > asm volatile __inline__(... > > > > but both "inline" variants are defined as macros in that file. > > > > Which means...

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

...; @@ -0,0 +1,63 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2020 Google LLC. > > + */ > > +#ifndef __ASM_RWONCE_H > > +#define __ASM_RWONCE_H > > + > > +#ifdef CONFIG_CLANG_LTO > > + > > +#include <linux/compiler_types.h> > > +#include <asm/alternative-macros.h> > > + > > +#ifndef BUILD_VDSO > > + > > +#ifdef CONFIG_AS_HAS_LDAPR > > +#define __LOAD_RCPC(sfx, regs...) \ > > + ALTERNATIVE( \ > > + "ldar" #sfx "\t" #regs, \...