On 02/05/14 15:10, Matthias Klose wrote:
Am 04.02.2014 03:14, schrieb Mike Stump:
On Feb 3, 2014, at 3:52 PM, Joseph S. Myers <jos...@codesourcery.com> wrote:
On Mon, 3 Feb 2014, Andrew Pinski wrote:
On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo <dnovi...@google.com> wrote:
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor <i...@google.com> wrote:
If the presence of the build
tree makes writing some tests significantly simpler, I think that is
OK.
I would like to discourage that. Testing an already installed GCC for
which no build tree exists is a very useful feature.
I agree. Here at Cavium, we use the packaged up toolchain that comes
from a RPM and test it so we are testing exactly what we ship out to
our customers.
Similarly at Mentor.
And the maintainer of the test suite thinks that supporting the people that
ship gcc to large numbers of people who help ensure the quality of gcc is
useful. :-) It is nice to hear from people that this type of testing is
useful; thanks.
could somebody please shed some light on how this is done? It's nice that
everybody has this kind of testing, but the only bit in the gcc sources itself
seems to be a bit bit-rot and incomplete (contrib/test_installed).
I suspect most folks have a site.exp they drop somewhere and explicitly
call runtest --tool gcc ....
I know we do it internally in our QE team, but I never asked them about
the current mechanics of how it's done.
Jeff
