Re: unexpected NOP encodings

[Alan Modra <amodra at gmail dot com>]

On Tue, Jun 25, 2019 at 01:01:17AM -0600, Jan Beulich wrote:
> >>> On 25.06.19 at 05:36, <amodra@gmail.com> wrote:
> >  void
> >  ppc_handle_align (struct frag *fragP)
> >  {
> >    valueT count = (fragP->fr_next->fr_address
> >  		  - (fragP->fr_address + fragP->fr_fix));
> > +  char *dest = fragP->fr_literal + fragP->fr_fix;
> > +  enum ppc_nop_encoding_for_rs_align_code nop_select = *dest & 0xff;
> > +
> > +  /* Pad with zeros if not inserting a whole number of instructions.
> > +     We could pad with zeros up to an instruction boundary then follow
> > +     with nops but odd counts indicate data in an executable section
> > +     so padding with zeros is most appropriate.  */
> > +  if (count == 0
> > +      || nop_select == PPC_NOP_VLE ? (count & 1) != 0 : (count & 3) != 0)
> 
> Did you mean to put parentheses around the ?: expression?

Errm, yes, thanks.  Caught out by combining
  if (count == 0)
    return;
  if (nop_select == ...)
    {
    }

Curiously, the code I committed will actually work since the zero
count case will just needlessly write 4 bytes into the variable part
of the frag (and there isn't a buffer overflow).  :)

-- 
Alan Modra
Australia Development Lab, IBM