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 <david@gibson.dropbear.id.au>

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);
+
         /* Map CPU interface per SMP Core */
         sprintf(cpu_alias_name, "%s%x", cpu_prefix, i);
         memory_region_init_alias(&s->cpu_alias[i], obj,
-- 
2.23.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 <david@gibson.dropbear.id.au>
> 
> 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~

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 <david@gibson.dropbear.id.au>
 >

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

--- <- here goes the separator I suppose

> 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);
> +
>           /* Map CPU interface per SMP Core */
>           sprintf(cpu_alias_name, "%s%x", cpu_prefix, i);
>           memory_region_init_alias(&s->cpu_alias[i], obj,
>