Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/13/2017 12:25 PM, Marco Atzeri wrote:
> The risk of collision is very low on 64 bit.
> It is higher on 32 bit but as gcc don't depend on other libraries,
> I don't expect that to happen.
>
> If happens you can rebase in tree before running the tests,
> providing the list of new dll to rebase.
> I used it when I had problem on testing  Octave; but Octave
> dlls with debugging symbols are huge and pull tons of
> other dlls so the collision was almost sure on 32bit

I'm not so much concerned about the outcome of an individual run, but of 
test integrity, reliability and repeatability.  gcc's testsuite should 
be something you can fire off and forget about until it finishes (it 
current takes about 14 hours 100).  A test should fail when there's a 
bug and not when the god of random numbers frowns.  The possibility of 
this type of problem means that fewer developers are going to be willing 
to get on Cygwin and so gcc will be crappier and tend to break on 
Cygwin.  (This is combined with the fact that SO much of DejaGnu & gcc 
tests are already broken on Cygwin).  If this is a possible issue at 
all, it should be managed somewhere IN gcc's build process.  I've been 
through a few of weeks of BS now and I'm just starting on my 32-bit tests.

I would very much like to be able to come up with an automated process 
that can be run on a server somewhere under a VM using an LVM read/write 
snapshot, so that the environment can be easily reset to a pristine 
state (i.e., freshly installed Windows & Cygwin) with minimal I/O.  If I 
can solve this problem and the "broken pipe" issue then we might be 
getting close!

Daniel


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple