From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT corrupted builds with below second changes Date: Wed, 14 Mar 2018 17:56:13 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Wed, 14 Mar 2018 22:56:13 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="15059"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:50979 Date: 2018-03-14T17:56:13-05:00 List-Id: "Alejandro R. Mosteo" wrote in message news:p8atvh$74r$1@dont-email.me... > Hi, > > I'm doing some automated testing that involves very fast file generation > and recompilation. Platform is linux, GPL 2017 or FSF 7.2. I've observed > that gprbuild seems to not detect that a file is changed if less than a > second has elapsed. I will guess here that the timestamp being used has > second precision. This leads to supposedly up-to-date builds that aren't, > among other funny effects. > > I faintly remember having read about this somewhere, but I'm unable to > find anything related in web searches. Anyone has experienced this? Not with GNAT, but we used to have such problems with Janus/Ada programs. I believe it caused certain ACATS tests to intermittently fail. I think I "fixed" that by introducing a delay into the compiler in certain circumstances (the delay being barely noticable to humans, but long enough to ensure that the time stamps are unique). [I don't remember for sure whether I fixed the problem, but since I don't remember it happening in the last 5 years, it seems likely that I did something to prevent it.] A better fix would have been to stop using time for such checks (compiles having gotten fast enough to make identical timestamps probable, and more so with every new generation of computers), but that would have required a lot of compiler and library change. (Definitely not the quick fix I was looking for at the time.) It wouldn't surprise me if GNAT ran into similar issues -- the file timestamps on Windows (which is what we were/are using) have a 2 second granularity. Randy.