On Mon, Feb 15, 2016 at 11:45 AM, Tom de Vries <tom_devr...@mentor.com> wrote: > On 15/02/16 10:07, Bernd Edlinger wrote: >> >> On 15/02/16 09:07, Tom de Vries wrote: >>>> >>>> >>On 15/02/16 08:24, Dmitry Vyukov wrote: >>>> >> >>>> >> If we are talking about pr 68580, then I would try: >>>> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2 >>>> >> first. >>> >>> > >>> >As I tried to explain in the follow-up comment >>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c3 ), >>> >since unfortunately I have no reliable way of reproducing the failure, >>> > there's no defined way to 'try' something. > > >> But your proposed patch is also only guessing. > > > I've tried to be as clear as possible in the RFC submission that I'm not > certain about the cause of the failure, and that the patch is proposing a > fix that would make that guessed failure cause explicit. > >> Sure pthread_create can fail, as malloc and mmap. >> But if that is the reason for the failure it would happen >> just randomly, everywhere. >> >> Why do you think that only this test case shows the problem? >> > > As I explained in the RFC submission, my reasoning there was that the test > is one of the very few test cases that tests the result of pthread_create > and then returns 0, which causes the failure in combination with > dg-shouldfail. > > But thinking about it some more, even if pthread_create would fail, causing > the testcase to fail in execution, allowing the execution test to pass due > to dg-shouldfail, presumably the dg-output test would still fail in that > case, so my reasoning was not sound. > > So I suppose you're right, indeed the pthread_create fail hypothesis is not > the most logical one. > > Still, the patch is an improvement irrespective of the PR that inspired it, > and perhaps a lot more library calls should be checked for errors that just > pthread_create. > >> I think Dmitry's comment may be right on the point. > > > If someone proposes that as a patch for the testcase, great. I'm more that > willing to test that in my setup to be able to claim 'bootstrapped and > reg-tested on x86_64' in the submission. > > I'm just trying to point out that I cannot 'try' out that patch and come > back with the conformation that 'the patch fixes the failure', given the > nature of the failure.
Yes, we can't directly test a fix. But s/int/long long/ is still the right thing to do. We do it in other tests for similar reasons. We can submit it and see if flakes remain or go away.
