breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Hans-Peter Nilsson]

On Mon, 16 Jun 2014, Steven Bosscher wrote:
> On Mon, Jun 16, 2014 at 12:36 AM, Hans-Peter Nilsson wrote:
> > On Sun, 15 Jun 2014, Steven Bosscher wrote:
> >> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> >> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
> >> > merge_in_block(int, basic_block_def*)':
> >> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
> >> > was not declared in this scope
> >> > make[2]: *** [auto-inc-dec.o] Error 1
> >> >
> >> > brgds, H-P
> >>
> >>
> >> Bah, this is why I just *hate* all the gcc code that's only compiled
> >> if certain #defines are set...
> >
> > I couldn't agree more.  Might not have been obvious when writing
> > the mosly-mechanical patch, still the auto-inc-dec.c name should
> > have been a red flag that a representative target should have
> > been tested (i.e. not x86_64 and i686).
>
> I agree, but I think you'd agree with me if I say that Richard S. is
> one of the few people who almost always goes beyond the normal amount
> of testing required for a patch.

His testing efforts relative many others I'd agree on (and I
seem to have a knack for being caught when things still go bad
with his patches), but I'd say the amount of testing that
Richard S usually applies is entirely appropriate and I wish
others would follow!  Also, looks like he fixed it.  (Thanks!)

> Breakage like this will just happen
> to us all, every once in a while, until we compile all middle-end code
> at least, regardless of #defines and whatnot (conditionally compiled
> code, from the top of my head: CC0, scheduler, dbrsched, auto-inc-dec,
> HAVE_conditional_move, etc...).

The patch looked pretty mechanical.  I feared the rabbit-hole,
but the stage 2 issue was apparently just the use of stale data
from the loop.  Exercising that required actually running the
code when testing.

brgds, H-P