Re: VAX: Another small GAS bug?

On Sun, 2024-04-07 01:42:49 +0900, Rin Okuyama <[email protected]> wrote:
> On 2024/04/07 1:16, Jan-Benedict Glaw wrote:
> > What the heck?! The original output (full unimpl_emul.S) was
> > different, but the critical excerpt is no longer? That'll be "fun" to
> > debug. Unfortunately, paid work is demanding right now, that might
> > take a while for me to really work on...
> 
> Yeah, I assembled unimpl_emul.S on NetBSD/amd64 and aarch64{,eb}
> hosts, and obtained different values in immediate fields of the
> instructions.
> 
> There should be bugs in gas logic handling floating-point immediates.
> 
> Note also:
> 
> - MALLOC_CONF="junk:true" (for NetBSD jemalloc) does not affect
>   the results.
> 
> - This is not a recent regression; objdump for GENERIC kernel of
>   NetBSD/vax 5.0 has the same bit pattern as NetBSD 10.0 in the insns.
> 
> It would be nice if we can fix gas, but cannot we replace $0f0.0 with
> $0x0 for now? According to "Vax Architecture Handbook", a floating-
> point number is recognized as 0.0 if sign and exponent fields are zero,
> and CPU always generates 0x0 for 0.0.

I haven't even _looked_ at the code, so I don't know what it's
actually doing. I don't know the FP representation out of my head, but
if an all-zero value is interpreted as 0.0, a CLRx would probably be
enough? Still, I'd like to see that bug fixed (and maybe add a
testcase for it to upstream Binutils.)

  Unfortunately, I guess I'll only have time for this in a month or
the like, maybe you, or Kalvin, or Anders, or Martin, or Maciej, or
Mouse, or ... may want to have a look?  Esp, since it happened in a
regular CI build, but I was unable (in a few-minutes attempt) to
reproduce it. :-/  I'd like to make sure there isn't much more hidden
behind this issue.

MfG, JBG

--

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQlDTvPcScNjKREqWEdvV51g5nhuwUCZhGcDQAKCRAdvV51g5nh
u5d1AJ95xJ+nyT3HynkIrPm+ZQxkHctEjQCggdaC4tdx6fnyKuD2lQeHbx2IZh8=
=K6GV
-----END PGP SIGNATURE-----