public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Add compile testing to glibc test framework.
Date: Fri, 17 Jun 2016 13:54:00 -0000	[thread overview]
Message-ID: <1b98cc43-5787-0f5d-5773-41edaea63b92@redhat.com> (raw)
In-Reply-To: <82e0dffc-bfd9-e06e-5798-e240ec7c8877@redhat.com>

On 06/17/2016 03:51 PM, Carlos O'Donell wrote:
> On 06/17/2016 07:27 AM, Florian Weimer wrote:
>> On 06/07/2016 07:28 PM, Joseph Myers wrote:
>>> On Tue, 7 Jun 2016, Carlos O'Donell wrote:
>>>
>>>> Previously these kinds of tests would result in the testsuite
>>>> failing to run to completion because compiler errors are treated
>>>> as harness failures.
>>>
>>> I don't actually see this as a problem - that is, I don't see why
>>> any compile failure should be hard to fix for some system-specific
>>> reason. I'd rather just add such tests as normal tests, that break
>>> the build if they fail.
>>
>> What's annoying with that is that you lose test summary reporting.
>> If this was somehow fixed (without impacting make running times,
>> please), I think there wouldn't much of an incentive to add such
>> compile-time testing.
>
> What would you like fixed? Summary reporting of failed compile
> and link?

Yes, and the existing reports for tests that ran.

> That's an interesting solution, wrap the compiles and link with
> something like evaluate-test.sh but designed to capture failed
> compiles and failed links and report them properly as a new
> kind of failed test code?

Something like that, yes.

If anyone wants to work on this: Potential future directions in this 
area involve compiling all tests -static, as PIE, as PIC, with Address 
Sanitizer, and so on, and also run them under valgrind.

(I also see considerable value in separating the test suite from the 
glibc source body, with the goal that you can compile the tests on an 
older glibc release, and check that they still work with the current 
version, but that is probably a different conversation.)

Florian

      reply	other threads:[~2016-06-17 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07  7:37 Carlos O'Donell
2016-06-07  7:44 ` Andreas Schwab
2016-06-07  8:13   ` Carlos O'Donell
2016-06-07  8:40     ` Carlos O'Donell
2016-06-07 17:28 ` Joseph Myers
2016-06-17  3:15   ` Carlos O'Donell
2016-06-17  9:18     ` Joseph Myers
2016-06-17 11:27   ` Florian Weimer
2016-06-17 13:51     ` Carlos O'Donell
2016-06-17 13:54       ` Florian Weimer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b98cc43-5787-0f5d-5773-41edaea63b92@redhat.com \
    --to=fweimer@redhat.com \
    --cc=carlos@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).