target/arm/sve_helper: Fix compilation with clang 3.4
PATCH 1/1 target/arm/sve_helper: Fix compilation with clang 3.4
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.
--- target/arm/sve_helper.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
target/arm/sve_helper.c +10 -10
@@ -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) \ { \
Signature · 1 line
1.8.3.1
Quoted 8 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>--- target/arm/sve_helper.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
r~
Quoted 3 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.
checkpatch candidate?
Quoted 2 lines
Signed-off-by Thomas Huth <[email protected]>
Quoted 94 lines
--- target/arm/sve_helper.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)target/arm/sve_helper.c +10
-10@@ -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) \ { \
Quoted 6 lines · Philippe Mathieu-Daudé
Quoted 3 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, 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
Quoted 11 lines · Thomas Huth
Quoted 6 lines · Philippe Mathieu-Daudé
Quoted 3 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, 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");
}Quoted 14 lines · Philippe Mathieu-Daudé
Quoted 11 lines · Thomas Huth
Quoted 6 lines · Philippe Mathieu-Daudé
Quoted 3 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, 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).
Quoted 5 lines
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
Peter Maydell
AppliedQuoted 6 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>
Applied to master, thanks.
-- PMM
Quoted 5 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>
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
Signature · 3 lines
|: 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 :|
Quoted 10 lines · Daniel P. Berrangé
Quoted 5 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>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.
Quoted 7 lines
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.
Quoted 2 lines
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)...
Quoted 14 lines · Thomas Huth
Quoted 13 lines · Daniel P. Berrangé
Quoted 5 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>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.
Quoted 6 lines
Quoted 4 lines
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
Signature · 3 lines
|: 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 :|
Quoted 25 lines · Daniel P. Berrangé
Quoted 14 lines · Thomas Huth
Quoted 13 lines · Daniel P. Berrangé
Quoted 5 lines · Thomas Huth
Clang 3.4 does not know the "flatten" attribute yet. We've already introduced the
QEMU_FLATTENmacro for this in commit97ff87c0ed020c2, so use this macro now here, too, to fix this issue.Signed-off-by Thomas Huth <[email protected]>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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 6 lines
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