search for: compiler_types

.../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 definition...

...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 ?__sw...

...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: note...

...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 attempt...

...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 this...

....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); > } > > +/* >...

....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); > } > > +/* >...

...(~__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 ...

On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. > > Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4

On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to propose that trunk always have a version number which is in > between versions used by the previous release branch, and before the > versions used in the next release

...> > > > 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 w...

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, \ &g...