dev-cpp-users

[Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[<p_d...@ya...>]

I quiet often get this message when compile my projet. Does anyone know why and what I can do to avoid this warning (problem).

I am using the new release 4.9.4.0

Thx.



---------------------------------
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Hongli L. <h....@ch...>]

On Fri, 2002-06-28 at 08:34, Pierre Delporte wrote:
> 
> I quiet often get this message when compile my projet. Does anyone know why and what I can do to avoid this warning (problem).
> 
> I am using the new release 4.9.4.0
> 
> Thx.
> 

That's a known problem, but we can't find out the cause.
Just ignore it or hit the Compile button again, it's nothing serious.

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[<p_d...@ya...>]

 Nothing serious ! I am not sure about this. It is always anoying to have to compile two, three or more times to get a good result. I think, to improve the quality of the product, that this matter should be investigated with high priority.
Yours,
Pierre
  Hongli Lai <h....@ch...> a écrit : On Fri, 2002-06-28 at 08:34, Pierre Delporte wrote:
> 
> I quiet often get this message when compile my projet. Does anyone know why and what I can do to avoid this warning (problem).
> 
> I am using the new release 4.9.4.0
> 
> Thx.
> 

That's a known problem, but we can't find out the cause.
Just ignore it or hit the Compile button again, it's nothing serious.




---------------------------------
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Carlos d. M. <cg...@wo...>]

I agree.

=3D?iso-8859-1?q?Pierre=3D20Delporte?=3D escribi=F3:

>  Nothing serious ! I am not sure about this. It is always anoying to
> have to compile two, three or more times to get a good result. I
> think, to improve the quality of the product, that this matter should
> be investigated with high priority.
>
> Yours,
>
> Pierre
>
>   Hongli Lai <h....@ch...> a =E9crit :
>
>      On Fri, 2002-06-28 at 08:34, Pierre Delporte wrote:
>      >
>      > I quiet often get this message when compile my projet.
>      Does anyone know why and what I can do to avoid this warning
>      (problem).
>      >
>      > I am using the new release 4.9.4.0
>      >
>      > Thx.
>      >
>
>      That's a known problem, but we can't find out the cause.
>      Just ignore it or hit the Compile button again, it's nothing
>      serious.
>
>
>
> -----------------------------------------------------------------------
> Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en fran=E7ais !

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Hongli L. <h....@ch...>]

On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
> 
>  Nothing serious ! I am not sure about this. It is always anoying to have to compile two, three or more times to get a good result. I think, to improve the quality of the product, that this matter should be investigated with high priority.

Always? I only experience this once every 20 compiles.

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[<p_d...@ya...>]

 I would not say every time but once every 4 times !
  Hongli Lai <h....@ch...> a écrit : On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
> 
> Nothing serious ! I am not sure about this. It is always anoying to have to compile two, three or more times to get a good result. I think, to improve the quality of the product, that this matter should be investigated with high priority.

Always? I only experience this once every 20 compiles.




---------------------------------
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

RE: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Ioannis V. <no...@ho...>]

Hongli why not try to recompile Dev-C++ in Delphi without any caching
(full Building)?
=20
=20
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
<http://www.noicys.cjb.net/>=20
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Pierre
Delporte
Sent: Friday, June 28, 2002 5:26 PM
To: Hongli Lai
Cc: dev...@li...
Subject: Re: [Dev-C++] [Warning] Clock skew detected. Your build may be
incomplete.



I would not say every time but once every 4 times !=20


  Hongli Lai <h....@ch...> a =E9crit :=20


On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
>=20
> Nothing serious ! I am not sure about this. It is always anoying to
have to compile two, three or more times to get a good result. I think,
to improve the quality of the product, that this matter should be
investigated with high priority.

Always? I only experience this once every 20 compiles.






  _____ =20

Yahoo! Mail <http://fr.mail.yahoo.com>  -- Une adresse @yahoo.fr
gratuite et en fran=E7ais !

RE: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Hongli L. <h....@ch...>]

On Fri, 2002-06-28 at 17:34, Ioannis Vranos wrote:
> Hongli why not try to recompile Dev-C++ in Delphi without any caching
> (full Building)?
>  

How does that have anything to do with make?

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Colin L. <col...@wa...>]

Hello,

Just to say you can set a delay before the compiler will be called (in 
Compiler Options), if you really want to get rid of this message.

Greetings,
Colin

On Friday 28 June 2002 13:45, you wrote:
> On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
> >  Nothing serious ! I am not sure about this. It is always anoying to have
> > to compile two, three or more times to get a good result. I think, to
> > improve the quality of the product, that this matter should be
> > investigated with high priority.
>
> Always? I only experience this once every 20 compiles.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Mac R. <re...@no...>]

At 06:15 PM 6/28/02 +0200, Colin Laplace wrote:
>Hello,
>
>Just to say you can set a delay before the compiler will be called (in 
>Compiler Options), if you really want to get rid of this message.
>
>Greetings,
>Colin
>
>On Friday 28 June 2002 13:45, you wrote:
>> On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
>> >  Nothing serious ! I am not sure about this. It is always anoying to have
>> > to compile two, three or more times to get a good result. I think, to
>> > improve the quality of the product, that this matter should be
>> > investigated with high priority.
>>
>> Always? I only experience this once every 20 compiles.

Just trying to understand what is happening.  If adding a delay to each
compilation step (prior to invoking gcc/g++) fixes the problem, it sounds
like it is possible for compilation to occur and linking to start before
the clock has advanced enough for 'make' to be able to distinguish that
time has elapsed.

Example:

main.o, timestamp 5:13:47pm

I tell it to make, so it saves my file:

main.cpp, timestamp 5:25:23pm (timestamp of autosave prior to make)

which occurs REALLY FAST, and GCC compiles main.cpp REALLY FAST, so that
the saved .cpp file and the .o file both have the same timestamp (not even
one second has elapsed between save and compilation of this file):

main.o, timestamp 5:25:23pm

Now the linker pass comes along and has some kind of problem, because it
can't tell if main.o is newer than main.cpp or not.  Does this sound like
the problem?  If so, either make needs to be modified to somehow use more
accurate timestamps (difficult, since it relies on file timestamps, which
are OS determined), or GCC needs to be modified so that if it completes
compilation in less than one second, it delays a second to let the
timestamps differ.  If this actually is the problem, it is only going to
get worse as machines get faster.

My Athlon XP 1900+ with Barracuda ATA IV driver does seem to get the clock
skew warning quite frequently, suggesting that it might be CPU and/or
harddrive speed dependent.

Thanks for the delay suggestion Colin!  (And for including the capability).
 Delaying for 1 second _should_ fix the problem, if it is the one just
described, and a one second delay shouldn't be a problem for most builds.
If this really IS the problem, it might be worth modifying Dev-C++ to
always add a one second delay, or to time the runtime of GCC and add a
second if it looks like no time has passed.  Can that even be done, or is
make in complete control?

On a somewhat unrelated note, I do know that if you ever use
QueryPerformanceCounter() and QueryPerformanceFrequency() to calculate
really accurate times, you can get clock rollback.  If you use these
functions and want proof, write a loop that simply stares at the results
from QueryPerformanceCounter() over and over again for several seconds.
Keep track of every time the clock jumps backward -- you'll get one pretty
quickly.  I looked at the bit patterns for the clock, and the problem is
that the clock register is not protected while it is being incremented, or
while it is being read.  So *while* you are copying off the 64bit integer
(which takes at least 2 instructions, probably 3), the value of that
register changes.  Most of the time it isn't a problem, but since you are
reading out portions of the integer, when a carry occurs that crosses the
boundary between the pieces, you can end up with really funky numbers:

Example, shorted into a byte and nybbles for ease of typing:

Clock value   : 0101 1111

Read High Half into variable -> 0101 0000

Clock updates : 0110 0000

Change index in preparation for reading low half

Clock updates : 0110 0001

Read Low Half into variable -> 0101 0001


Notice that the high half changed *after* you had already read it, but
before you managed to read the low half.  This is the problem with the new
processors having a clock that increments once for every instruction, but
which takes multiple cycles (only one instruction, but it internally takes
longer) to read.

The moral?  If you use super high resolution clocks
(QueryPerformanceCounter or directly playing with the RDSTC opcode), check
the clock a few times for each read, and reject silly numbers.  Your timing
code will be slightly slower, but you will not report negative elapsed
times or unnecessarily long times (imagine if your recorded start time was
the bad read of 01010001 above, and then very shortly afterward you took
another reading and got an accurate 01100100.  You would think that almost
00100000 ticks had occurred, when only 00000100 ticks had actually
occurred.  That's not bad with a byte and nybbles, but think about a 64 bit
int with two long int halves -- the reading would claim that over 4 billion
ticks had occurred...)

Sorry for the rambling...
Mac
-
 _____________________________     /"\
 Mac Reiter                        \ /    ASCII Ribbon Campaign
 Nomadics, Inc.                     X     Against HTML Mail
 re...@no...               / \   (To join the campaign, simply use
                                          this in your signature.)
                                          

Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Hongli L. <h....@ch...>]

On Fri, 2002-06-28 at 20:59, Mac Reiter wrote:
> At 06:15 PM 6/28/02 +0200, Colin Laplace wrote:
> Now the linker pass comes along and has some kind of problem, because it
> can't tell if main.o is newer than main.cpp or not.  Does this sound like
> the problem?  If so, either make needs to be modified to somehow use more
> accurate timestamps (difficult, since it relies on file timestamps, which
> are OS determined), or GCC needs to be modified so that if it completes
> compilation in less than one second, it delays a second to let the
> timestamps differ.  If this actually is the problem, it is only going to
> get worse as machines get faster.
> 

Actually, GCC or the linker don't check on anything. Make does that.
So make will have to be modified, not GCC.

Re: [Dev-C++] [Warning] Clock skew detected. Your build may beincomplete.

[Mac R. <re...@no...>]

At 12:11 AM 6/29/02 +0200, Hongli Lai wrote:
>On Fri, 2002-06-28 at 20:59, Mac Reiter wrote:
>> At 06:15 PM 6/28/02 +0200, Colin Laplace wrote:
>> Now the linker pass comes along and has some kind of problem, because it
>> can't tell if main.o is newer than main.cpp or not.  Does this sound like
>> the problem?  If so, either make needs to be modified to somehow use more
>> accurate timestamps (difficult, since it relies on file timestamps, which
>> are OS determined), or GCC needs to be modified so that if it completes
>> compilation in less than one second, it delays a second to let the
>> timestamps differ.  If this actually is the problem, it is only going to
>> get worse as machines get faster.
>> 
>
>Actually, GCC or the linker don't check on anything. Make does that.
>So make will have to be modified, not GCC.

I am aware of that.  But the problem *could* be fixed by GCC ensuring that
from the time it started until the time it wrote the result was at least
one second long.  It would NOT be the RIGHT place to fix it, but it WOULD
guarantee that the timestamps all differed.

The RIGHT place to fix it is in 'make', obviously, since it is 'make' that
is having timestamp problems.  Since 'make' cannot go to more accurate
timers (it must rely on file timestamps, which are OS specified), it could
use the "delay if I need to" method between each program invocation stage.
If it guaranteed that at least one second passed between each step, that
should fix most things.  It still wouldn't guarantee that the first step
was OK, since the file could have been saved, then make started, then GCC
run to completion all within one second.  To fix that, make would need to
perform the delay step *before* each invocation, not just *between* all
invocations -- that way it would delay before the first invocation,
allowing the clock to advance between the save and the running of GCC.

Oh, and while I'm on the subject of clocks -- keep in mind that staring at
a computer clock can keep it from moving.  In particular on DOS machines,
running a program that loops continuously asking for the time and
displaying it will cause the clock to lose several minutes per hour,
possibly more on faster machines.  A fast enough machine might be able to
stop it completely.  On DOS, reading the clock does lock out the update
interrupt, so if you read the clock enough, the update interrupt can't ever
get through.  This is the flip side to the problem I described earlier
about reading a clock that did *not* lock itself during read, which allowed
for having the value change while you were reading, leading to clocks
appearing to run backward and other atrocities.

In case you're wondering, the right (or at least better) solution (which
can only be implemented by hardware designers) is to double buffer (I
believe the hardware term is register, or latch, but I'm not sure) the
clock.  Allow the update interrupt to always be able to write into the
writable buffer.  Allow upper layers to always be able to read from the
readable buffer.  Whenever either buffer is unlocked (when either update
interrupt exits or upper layer read function exits), see if the other
buffer is also unlocked, and if it is, copy (latch) the value from the
writable buffer to the readable buffer.  Really fast readers could still
stall out the update process, but once the program went away, the clock
would properly update.  I suppose you could have a bit to signal that an
update is pending, so that you could block reader applications out until
you could get the latching from writable to readable done...

Oh well -- doesn't matter, since the PC hardware won't be changing any time
soon (at least in that regard).  Just passing on some painfully learned
knowledge about how clocks are not nearly as nice and simple as you would
think they are...
-
 _____________________________     /"\
 Mac Reiter                        \ /    ASCII Ribbon Campaign
 Nomadics, Inc.                     X     Against HTML Mail
 re...@no...               / \   (To join the campaign, simply use
                                          this in your signature.)
                                          

Re: [Dev-C++] [Warning] Clock skew detected. Your build may beincomplete.

[Hongli L. <h....@ch...>]

On Mon, 2002-07-01 at 17:47, Mac Reiter wrote:
> At 12:11 AM 6/29/02 +0200, Hongli Lai wrote:
> I am aware of that.  But the problem *could* be fixed by GCC ensuring that
> from the time it started until the time it wrote the result was at least
> one second long.  It would NOT be the RIGHT place to fix it, but it WOULD
> guarantee that the timestamps all differed.

I call that a hack. When I type make in DO$ or in Linux, I almost never
get a "clock skew detected" (once in every 1000 compiles it may happen).
So the problem must be somewhere in Dev-C++, but I can't figure out what
might have caused it.
And putting a delay in GCC, not the IDE, will only slow things down.

Oh BTW... I suggest you to submit a solution to the authors of GNU make.
I've never seen one line of GNU make's source code, so there's nothing
much I can do about it.