On Tue, Apr 27, 2021 at 03:20:47PM +0100, Richard Earnshaw via Gcc-patches
wrote:
> > --- gcc/config/aarch64/aarch64.c.jj 2021-04-16 20:49:23.602579852 +0200
> > +++ gcc/config/aarch64/aarch64.c 2021-04-26 16:40:46.835269671 +0200
> > @@ -10778,7 +10778,7 @@ aarch64_print_operand (FILE *f, rtx x, i
> > }
> > if (GET_MODE_CLASS (GET_MODE (x)) == MODE_VECTOR_INT)
> > - asm_fprintf (f, "%wd", -INTVAL (elt));
> > + asm_fprintf (f, "%wd", -UINTVAL (elt));
>
> This one looks wrong as you're now passing a UHWI to asm_fprintf when the
> format expects HWI. I think you need a cast back to HWI.
I'm not aware of any compiler that would care, but it is true that at least
C99 says on va_arg:
"or if type is not compatible with the type of the actual next argument (as
promoted according
to the default argument promotions), the behavior is undefined, except for the
following
cases:
— one type is a signed integer type, the other type is the corresponding
unsigned integer
type, and the value is representable in both types;
— one type is pointer to void and the other is a pointer to a character type."
So for pedantic reasons I should add the cast.
Note, -Wformat* doesn't warn on this.
2021-04-27 Jakub Jelinek <ja...@redhat.com>
PR target/100200
* config/aarch64/aarch64.c (aarch64_print_operand): Cast -UINTVAL
back to HOST_WIDE_INT.
--- gcc/config/aarch64/aarch64.c.jj 2021-04-27 15:46:13.477346613 +0200
+++ gcc/config/aarch64/aarch64.c 2021-04-27 16:50:27.335821271 +0200
@@ -10778,7 +10778,7 @@ aarch64_print_operand (FILE *f, rtx x, i
}
if (GET_MODE_CLASS (GET_MODE (x)) == MODE_VECTOR_INT)
- asm_fprintf (f, "%wd", -UINTVAL (elt));
+ asm_fprintf (f, "%wd", (HOST_WIDE_INT) -UINTVAL (elt));
else if (GET_MODE_CLASS (GET_MODE (x)) == MODE_VECTOR_FLOAT
&& aarch64_print_vector_float_operand (f, x, true))
;
Jakub
