[RFA:] Override randomness 2 plus "as" wrapper machinery usable for diffing assembly output.

[Hans-Peter Nilsson]

Thanks for the reviews!

> From: Geoffrey Keating <geoffk@apple.com>
> Date: Fri, 24 Feb 2006 15:38:47 -0800

> It seems like most of this patch is a workaround for bugs elsewhere:

No.  There were no bugs to fix or work around; all randomness
were there for reasons IIUC, but they kind of get in the way
when you want to diff assembly output between two build-and-test
runs.

> - projects not using -frandom-seed

What projects?  This is just for GCC internal use.  Do you mean
I should make the --disable-random-seed configure option cause
-frandom-seed=0 to be added for all gcc libraries and whatever
build rules and test-suite, instead of disabling the random-seed
generation at the source(s)?  That'd be a maintenance nightmare
for this feature.  I'll have to decline.

> - temporary file names appearing in debug information

Umm, it's been some time.  I'm not sure, but IIRC that was not
the case; I presume you refer to the libiberty patches?  (I'll
have to check that next time I use the patch set; IIRC it was
quite on purpose that the random bits were generated - else I'd
remember it as a bug.)  If the act of changing mkstemps is the
problem, I guess that could be handled some other way, like
instead instrumenting the testsuite bits that correctly provoked
it or the mkstemps call sites in gcc.

> I think it would be better to work on those bugs rather than put in a  
> workaround which
> 
> - aggrevates security problems

Oh, come on, that's really reaching!  This is instrumentation
for GCC testing.  There's no "security problem" with it; the
code isn't compiled into GCC by default and whoever uses the
compiler can't cause problems other than *for themselves*
collisions in temporary filenames.

Do you refer to the case when someone would *install* an
instrumented compiler as the system compiler?  That has been
covered in the previous discussion with D.J.  Sure, we could
disable the "install" target whenever --disable-random-seed was
used, or alternatively disable the option at release time by
using the same bits that flip the default for
--enable-checking=release...

> - will cause the compiler to behave incorrectly on some projects.

Um no, what makes you think so?

Oh well, I'll keep this patch set local then.  (For completeness
I mention again that I used it to investigate the effect of the
REG_LABEL_* patches you just approved.)

brgds, H-P