[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] exynos4210_gic: Suppress gcc9 format-truncation warnings
From: |
Richard Henderson |
Subject: |
Re: [PATCH v2] exynos4210_gic: Suppress gcc9 format-truncation warnings |
Date: |
Thu, 21 Nov 2019 13:00:41 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 11/21/19 2:38 AM, David Gibson wrote:
> exynos4210_gic_realize() prints the number of cpus into some temporary
> buffers, but it only allows 3 bytes space for it. That's plenty:
> existing machines will only ever set this value to EXYNOS4210_NCPUS
> (2). But the compiler can't always figure that out, so some[*] gcc9
> versions emit -Wformat-truncation warnings.
>
> We can fix that by hinting the constraint to the compiler with a
> suitably placed assert().
>
> [*] The bizarre thing here, is that I've long gotten these warnings
> compiling in a 32-bit x86 container as host - Fedora 30 with
> gcc-9.2.1-1.fc30.i686 - but it compiles just fine on my normal
> x86_64 host - Fedora 30 with and gcc-9.2.1-1.fc30.x86_64.
>
> Signed-off-by: David Gibson <address@hidden>
>
> Changes since v1:
> * Used an assert to hint the compiler, instead of increasing the
> buffer size.
>
> ---
> hw/intc/exynos4210_gic.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/hw/intc/exynos4210_gic.c b/hw/intc/exynos4210_gic.c
> index a1b699b6ba..ed4d8482e3 100644
> --- a/hw/intc/exynos4210_gic.c
> +++ b/hw/intc/exynos4210_gic.c
> @@ -314,6 +314,14 @@ static void exynos4210_gic_realize(DeviceState *dev,
> Error **errp)
> EXYNOS4210_EXT_GIC_DIST_REGION_SIZE);
>
> for (i = 0; i < s->num_cpu; i++) {
> + /*
> + * This clues in gcc that our on-stack buffers do, in fact
> + * have enough room for the cpu numbers. gcc 9.2.1 on 32-bit
> + * x86 doesn't figure this out, otherwise and gives spurious
> + * warnings.
> + */
> + assert(i <= EXYNOS4210_NCPUS);
You should be able to do
n = s->num_cpu;
assert(n <= EXYNOS4210_NCPUS);
for (i = 0; i < n; i++) {
What's happening here is that the compiler thinks that s->num_cpu may be
modified by the loop, and that's why an assert on s->num_cpu doesn't help.
r~