Re: VAX: Another small GAS bug?

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Sun, 7 Apr 2024, Kalvis Duckmanton wrote:

> >    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.
> 
> So I had a look today.  I don't believe GAS is at fault; it has assembled an
> F-floating zero (so 32 bits wide) ... into the lower part of a buffer big
> enough to hold a quadword (64 bits) or a D-floating value (again 64 bits). 
> The other 32 bits in that buffer, which are mantissa bits in the D-floating
> type, are not initialised.  As rin points out, VAX looks only at the sign and
> exponent fields to determine whether a value is a zero.

 I can't say offhand what the VAX assembly language semantics is here, but 
I find the use of uninitialised data for an instruction operand clearly a 
bug in GAS (and then a rather nasty one).

 I think the tool is supposed to either reject an immediate F-floating 
operand given to an instruction that operates on D-floating data or make 
an arithmetic conversion of the operand to correctly represent it in the 
D-floating format.  Likewise for other data format mismatches.

 What actually to do I'd expect to see in the VAX assembly language 
reference specification.  If not fixed right away, this needs to be filed 
as a bug upstream, so that we don't forget about it.

  Maciej