This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is testing libgomp outside of the build tree supported?


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 <joseph@codesourcery.com> wrote:
On Mon, 3 Feb 2014, Andrew Pinski wrote:
On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo <dnovillo@google.com> wrote:
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor <iant@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]