Clang 3.4 does not know the "flatten" attribute yet. We've already
introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2,
so use this macro now here, too, to fix this issue.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
target/arm/sve_helper.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 8cbc651..bc84725 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -4382,20 +4382,20 @@ static void sve_ld4_r(CPUARMState *env, void *vg, target_ulong addr,
}
#define DO_LDN_1(N) \
-void __attribute__((flatten)) HELPER(sve_ld##N##bb_r) \
+void QEMU_FLATTEN HELPER(sve_ld##N##bb_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_ld##N##_r(env, vg, addr, desc, 1, GETPC(), sve_ld1bb_tlb); \
}
#define DO_LDN_2(N, SUFF, SIZE) \
-void __attribute__((flatten)) HELPER(sve_ld##N##SUFF##_le_r) \
+void QEMU_FLATTEN HELPER(sve_ld##N##SUFF##_le_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_ld##N##_r(env, vg, addr, desc, SIZE, GETPC(), \
sve_ld1##SUFF##_le_tlb); \
} \
-void __attribute__((flatten)) HELPER(sve_ld##N##SUFF##_be_r) \
+void QEMU_FLATTEN HELPER(sve_ld##N##SUFF##_be_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_ld##N##_r(env, vg, addr, desc, SIZE, GETPC(), \
@@ -4832,7 +4832,7 @@ static void sve_st4_r(CPUARMState *env, void *vg, target_ulong addr,
}
#define DO_STN_1(N, NAME, ESIZE) \
-void __attribute__((flatten)) HELPER(sve_st##N##NAME##_r) \
+void QEMU_FLATTEN HELPER(sve_st##N##NAME##_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, 1, \
@@ -4840,13 +4840,13 @@ void __attribute__((flatten)) HELPER(sve_st##N##NAME##_r) \
}
#define DO_STN_2(N, NAME, ESIZE, MSIZE) \
-void __attribute__((flatten)) HELPER(sve_st##N##NAME##_le_r) \
+void QEMU_FLATTEN HELPER(sve_st##N##NAME##_le_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, MSIZE, \
sve_st1##NAME##_le_tlb); \
} \
-void __attribute__((flatten)) HELPER(sve_st##N##NAME##_be_r) \
+void QEMU_FLATTEN HELPER(sve_st##N##NAME##_be_r) \
(CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
{ \
sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, MSIZE, \
@@ -4966,7 +4966,7 @@ static void sve_ld1_zd(CPUARMState *env, void *vd, void *vg, void *vm,
}
#define DO_LD1_ZPZ_S(MEM, OFS) \
-void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
+void QEMU_FLATTEN HELPER(sve_ld##MEM##_##OFS) \
(CPUARMState *env, void *vd, void *vg, void *vm, \
target_ulong base, uint32_t desc) \
{ \
@@ -4975,7 +4975,7 @@ void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
}
#define DO_LD1_ZPZ_D(MEM, OFS) \
-void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
+void QEMU_FLATTEN HELPER(sve_ld##MEM##_##OFS) \
(CPUARMState *env, void *vd, void *vg, void *vm, \
target_ulong base, uint32_t desc) \
{ \
@@ -5326,7 +5326,7 @@ static void sve_st1_zd(CPUARMState *env, void *vd, void *vg, void *vm,
}
#define DO_ST1_ZPZ_S(MEM, OFS) \
-void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
+void QEMU_FLATTEN HELPER(sve_st##MEM##_##OFS) \
(CPUARMState *env, void *vd, void *vg, void *vm, \
target_ulong base, uint32_t desc) \
{ \
@@ -5335,7 +5335,7 @@ void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
}
#define DO_ST1_ZPZ_D(MEM, OFS) \
-void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
+void QEMU_FLATTEN HELPER(sve_st##MEM##_##OFS) \
(CPUARMState *env, void *vd, void *vg, void *vm, \
target_ulong base, uint32_t desc) \
{ \
--
1.8.3.1
On 11/28/18 1:58 AM, Thomas Huth wrote: > Clang 3.4 does not know the "flatten" attribute yet. We've already > introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, > so use this macro now here, too, to fix this issue. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > target/arm/sve_helper.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
On 28/11/18 10:58, Thomas Huth wrote:
> Clang 3.4 does not know the "flatten" attribute yet. We've already
> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2,
> so use this macro now here, too, to fix this issue.
checkpatch candidate?
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> target/arm/sve_helper.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 8cbc651..bc84725 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -4382,20 +4382,20 @@ static void sve_ld4_r(CPUARMState *env, void *vg, target_ulong addr,
> }
>
> #define DO_LDN_1(N) \
> -void __attribute__((flatten)) HELPER(sve_ld##N##bb_r) \
> +void QEMU_FLATTEN HELPER(sve_ld##N##bb_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_ld##N##_r(env, vg, addr, desc, 1, GETPC(), sve_ld1bb_tlb); \
> }
>
> #define DO_LDN_2(N, SUFF, SIZE) \
> -void __attribute__((flatten)) HELPER(sve_ld##N##SUFF##_le_r) \
> +void QEMU_FLATTEN HELPER(sve_ld##N##SUFF##_le_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_ld##N##_r(env, vg, addr, desc, SIZE, GETPC(), \
> sve_ld1##SUFF##_le_tlb); \
> } \
> -void __attribute__((flatten)) HELPER(sve_ld##N##SUFF##_be_r) \
> +void QEMU_FLATTEN HELPER(sve_ld##N##SUFF##_be_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_ld##N##_r(env, vg, addr, desc, SIZE, GETPC(), \
> @@ -4832,7 +4832,7 @@ static void sve_st4_r(CPUARMState *env, void *vg, target_ulong addr,
> }
>
> #define DO_STN_1(N, NAME, ESIZE) \
> -void __attribute__((flatten)) HELPER(sve_st##N##NAME##_r) \
> +void QEMU_FLATTEN HELPER(sve_st##N##NAME##_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, 1, \
> @@ -4840,13 +4840,13 @@ void __attribute__((flatten)) HELPER(sve_st##N##NAME##_r) \
> }
>
> #define DO_STN_2(N, NAME, ESIZE, MSIZE) \
> -void __attribute__((flatten)) HELPER(sve_st##N##NAME##_le_r) \
> +void QEMU_FLATTEN HELPER(sve_st##N##NAME##_le_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, MSIZE, \
> sve_st1##NAME##_le_tlb); \
> } \
> -void __attribute__((flatten)) HELPER(sve_st##N##NAME##_be_r) \
> +void QEMU_FLATTEN HELPER(sve_st##N##NAME##_be_r) \
> (CPUARMState *env, void *vg, target_ulong addr, uint32_t desc) \
> { \
> sve_st##N##_r(env, vg, addr, desc, GETPC(), ESIZE, MSIZE, \
> @@ -4966,7 +4966,7 @@ static void sve_ld1_zd(CPUARMState *env, void *vd, void *vg, void *vm,
> }
>
> #define DO_LD1_ZPZ_S(MEM, OFS) \
> -void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
> +void QEMU_FLATTEN HELPER(sve_ld##MEM##_##OFS) \
> (CPUARMState *env, void *vd, void *vg, void *vm, \
> target_ulong base, uint32_t desc) \
> { \
> @@ -4975,7 +4975,7 @@ void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
> }
>
> #define DO_LD1_ZPZ_D(MEM, OFS) \
> -void __attribute__((flatten)) HELPER(sve_ld##MEM##_##OFS) \
> +void QEMU_FLATTEN HELPER(sve_ld##MEM##_##OFS) \
> (CPUARMState *env, void *vd, void *vg, void *vm, \
> target_ulong base, uint32_t desc) \
> { \
> @@ -5326,7 +5326,7 @@ static void sve_st1_zd(CPUARMState *env, void *vd, void *vg, void *vm,
> }
>
> #define DO_ST1_ZPZ_S(MEM, OFS) \
> -void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
> +void QEMU_FLATTEN HELPER(sve_st##MEM##_##OFS) \
> (CPUARMState *env, void *vd, void *vg, void *vm, \
> target_ulong base, uint32_t desc) \
> { \
> @@ -5335,7 +5335,7 @@ void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
> }
>
> #define DO_ST1_ZPZ_D(MEM, OFS) \
> -void __attribute__((flatten)) HELPER(sve_st##MEM##_##OFS) \
> +void QEMU_FLATTEN HELPER(sve_st##MEM##_##OFS) \
> (CPUARMState *env, void *vd, void *vg, void *vm, \
> target_ulong base, uint32_t desc) \
> { \
>
On 2018-11-28 15:34, Philippe Mathieu-Daudé wrote: > On 28/11/18 10:58, Thomas Huth wrote: >> Clang 3.4 does not know the "flatten" attribute yet. We've already >> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, >> so use this macro now here, too, to fix this issue. > > checkpatch candidate? I think we'd rather need a docker-based test with such an old version of Clang... (since there are also other issues like the double-typedef problem that regularly occurs there). Thomas
On 28/11/18 15:39, Thomas Huth wrote:
> On 2018-11-28 15:34, Philippe Mathieu-Daudé wrote:
>> On 28/11/18 10:58, Thomas Huth wrote:
>>> Clang 3.4 does not know the "flatten" attribute yet. We've already
>>> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2,
>>> so use this macro now here, too, to fix this issue.
>>
>> checkpatch candidate?
>
> I think we'd rather need a docker-based test with such an old version of
> Clang... (since there are also other issues like the double-typedef
> problem that regularly occurs there).
I was thinking of something such (broken code!):
if ($line =~ /.*__attribute__\w+\(\(flatten\)\)/) {
ERROR("Use QEMU_FLATTEN ...\n");
}
On Wed, 28 Nov 2018 at 15:50, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> On 28/11/18 15:39, Thomas Huth wrote:
> > On 2018-11-28 15:34, Philippe Mathieu-Daudé wrote:
> >> On 28/11/18 10:58, Thomas Huth wrote:
> >>> Clang 3.4 does not know the "flatten" attribute yet. We've already
> >>> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2,
> >>> so use this macro now here, too, to fix this issue.
> >>
> >> checkpatch candidate?
> >
> > I think we'd rather need a docker-based test with such an old version of
> > Clang... (since there are also other issues like the double-typedef
> > problem that regularly occurs there).
>
> I was thinking of something such (broken code!):
>
> if ($line =~ /.*__attribute__\w+\(\(flatten\)\)/) {
> ERROR("Use QEMU_FLATTEN ...\n");
> }
If you wanted to go down that path then it might be best to
opt for "warn about any use of __attribute__ outside compiler.h,
perhaps with a whitelist of known-ok attributes".
thanks
-- PMM
On Wed, 28 Nov 2018 at 09:58, Thomas Huth <thuth@redhat.com> wrote: > > Clang 3.4 does not know the "flatten" attribute yet. We've already > introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, > so use this macro now here, too, to fix this issue. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Applied to master, thanks. -- PMM
On Wed, Nov 28, 2018 at 10:58:14AM +0100, Thomas Huth wrote: > Clang 3.4 does not know the "flatten" attribute yet. We've already > introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, > so use this macro now here, too, to fix this issue. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Although we currently only aim to support CLang and GCC, we don't have any checks for a minimum version of these two tools in configure. So I was wondering if we actually still need to support CLang 3.4 at all in QEMU, given our targetted build platforms. Unfortunately repology.org is failing me in reporting clang versions for most distros, so I don't have an answer yet. I do see that Debian Jessie however ships clang == 3.5 and that's usually the oldest distro if RHEL hasn't got something older. If we did explicitly check min gcc + clang versions, we could sanitize stuff such as hacks for ancient clang 3.2 which lacks int128 support. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 2018-11-28 17:05, Daniel P. Berrangé wrote: > On Wed, Nov 28, 2018 at 10:58:14AM +0100, Thomas Huth wrote: >> Clang 3.4 does not know the "flatten" attribute yet. We've already >> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, >> so use this macro now here, too, to fix this issue. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > Although we currently only aim to support CLang and GCC, we don't have > any checks for a minimum version of these two tools in configure. > > So I was wondering if we actually still need to support CLang 3.4 at all > in QEMU, given our targetted build platforms. > > Unfortunately repology.org is failing me in reporting clang versions > for most distros, so I don't have an answer yet. I do see that Debian > Jessie however ships clang == 3.5 and that's usually the oldest distro > if RHEL hasn't got something older. I'm using RHEL7 and the clang that I get "for free" is 3.4.2 via EPEL. > If we did explicitly check min gcc + clang versions, we could sanitize > stuff such as hacks for ancient clang 3.2 which lacks int128 support. I guess we could try to force the minimum version to 3.4 and see whether somebody complains afterwards... Thomas PS: That reminds me that I also wanted to send a patch for compiler.h to properly fail there if the minimum version of GCC is not met (v4.1)...
On Wed, Nov 28, 2018 at 05:50:38PM +0100, Thomas Huth wrote: > On 2018-11-28 17:05, Daniel P. Berrangé wrote: > > On Wed, Nov 28, 2018 at 10:58:14AM +0100, Thomas Huth wrote: > >> Clang 3.4 does not know the "flatten" attribute yet. We've already > >> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, > >> so use this macro now here, too, to fix this issue. > >> > >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > Although we currently only aim to support CLang and GCC, we don't have > > any checks for a minimum version of these two tools in configure. > > > > So I was wondering if we actually still need to support CLang 3.4 at all > > in QEMU, given our targetted build platforms. > > > > Unfortunately repology.org is failing me in reporting clang versions > > for most distros, so I don't have an answer yet. I do see that Debian > > Jessie however ships clang == 3.5 and that's usually the oldest distro > > if RHEL hasn't got something older. > > I'm using RHEL7 and the clang that I get "for free" is 3.4.2 via EPEL. Hmm, raises interesting question of whether we should consider 3rd party repos for purposes of determining our min versions. I'd pretty much intended to only care about vendor provided repos, in which case RHEL7 would be considered to lack clang, for purposes of deciding min versions. EPEL is a bit murky because while it is a 3rd party repo, many users of RHEL consider to be a defacto standard repo. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 2018-11-28 17:58, Daniel P. Berrangé wrote: > On Wed, Nov 28, 2018 at 05:50:38PM +0100, Thomas Huth wrote: >> On 2018-11-28 17:05, Daniel P. Berrangé wrote: >>> On Wed, Nov 28, 2018 at 10:58:14AM +0100, Thomas Huth wrote: >>>> Clang 3.4 does not know the "flatten" attribute yet. We've already >>>> introduced the QEMU_FLATTEN macro for this in commit 97ff87c0ed020c2, >>>> so use this macro now here, too, to fix this issue. >>>> >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> >>> Although we currently only aim to support CLang and GCC, we don't have >>> any checks for a minimum version of these two tools in configure. >>> >>> So I was wondering if we actually still need to support CLang 3.4 at all >>> in QEMU, given our targetted build platforms. >>> >>> Unfortunately repology.org is failing me in reporting clang versions >>> for most distros, so I don't have an answer yet. I do see that Debian >>> Jessie however ships clang == 3.5 and that's usually the oldest distro >>> if RHEL hasn't got something older. >> >> I'm using RHEL7 and the clang that I get "for free" is 3.4.2 via EPEL. > > Hmm, raises interesting question of whether we should consider 3rd > party repos for purposes of determining our min versions. > > I'd pretty much intended to only care about vendor provided repos, > in which case RHEL7 would be considered to lack clang, for purposes > of deciding min versions. > > EPEL is a bit murky because while it is a 3rd party repo, many users > of RHEL consider to be a defacto standard repo. Looks like there's also the possibility to get newer versions of Clang on top of RHEL7: https://developers.redhat.com/blog/2018/07/07/yum-install-gcc7-clang/ ... so fine for me if we use another version as the minimum. But if we decide to use 3.4 as minimum version, I'll keep my current compiler to be able to report problems... Thomas
© 2016 - 2024 Red Hat, Inc.