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
