[RFC] .fill does not accept forward labels

[Maciej W. Rozycki]

On Tue, 10 Oct 2017, Andreas Krebbel wrote:

> >  Please verify it suitably; offhand I smell endianness related problems 
> > with this pattern, but there can be other peculiarities with some targets.  
> 
> It is endianess-safe. That's why I've chosen patterns with duplicate bytes.

 Right, sorry for the confusion.

> It was already tested on
> s390 32/64 (big endian) and x86_64. I've now also tested it on mips64, 
> aarch64 and ppc64.

 Your updated patch seems to have been garbled in transit; I have fixed 
the breakage however and applied it regardless, and gave it a quick shot.  
It revealed failures for these targets:

hppa-hp-hpux10  +FAIL: fill test with forward labels
hppa64-hp-hpux11.23  +FAIL: fill test with forward labels
ia64-vms  +FAIL: fill test with forward labels
sh-pe  +FAIL: fill test with forward labels
tic4x-coff  +FAIL: fill test with forward labels
tic54x-coff  +FAIL: fill test with forward labels

Please investigate.

> >  If verifying actual output, then I suggest using `dc.w' instead.  With 
> > MIPS targets for example `.word' will produce 32-bit quantities.
> 
> Ok. I couldn't find .dc described in the gas manual. The only hit comes 
> from the S/390 gas doc with the very helpful statement: "A small subset 
> of the usual DC directive is supported." :)

 These have been supported since short of forever:

Tue Aug  1 17:35:26 1995  Ian Lance Taylor  <ian@cygnus.com>
[...]
	Initial support for MRI style labels and expressions.
[...]
	(potable): Add dc, dc.b, dc.d, dc.l, dc.s, dc.w, dc.x, ds, ds.b,
	ds.l, ds.w, and xdef.

It might be a good idea to document them somehow indeed.

> What about .2byte ? Would that be preferrable in any way?

 I have no preference.  Perhaps a global maintainer has.

  Maciej