X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Sequence points, any? Date: 5 Apr 2006 14:01:43 GMT Lines: 55 Message-ID: <49i0u7Foq6jlU1@news.dfncis.de> References: <1144238453 DOT 674596 DOT 302360 AT z34g2000cwc DOT googlegroups DOT com> X-Trace: news.dfncis.de kpetQFrioYLO0YvuJIFWBgXY29jkWU6nQlHuNmLVMm1KrPjaf5e6wr7Zqx X-Orig-Path: not-for-mail To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Bob W wrote: > As mentioned already in a previous post, gcc 4.10 > tends to optimize code in a way so that it gets out > of sequence. Well, sort of. The tricky part is that if the 2 of the three things you're doing hadn't been the clock() function, of all things, this would have been unnoticeable to the program, which would tend to make it an allowed optimization. On top of that, the function you call between the two is local to the translation unit, eligible for (partial) inlining, and doesn't have any side effects. On a lot of modern processors, intermixing the calls to clock() and the evaluation of the Ack() function would allow the CPU to parallelize them (--> Hyperthreading, ...) and finish the overall job faster. In other words, for *any* other function but clock() and some close relatives of it, this would be a desirable optimization. > - gcc calls clock() to start timing > - Ack() is called the 1st time > - gcc calls clock() again to end the timing > - now Ack() is called again and this obsoletes timing More to the point, these two calls of Ack() are part of an unrolled, inline rendition of this highly recursive function. [Workarounds...]: > - assign the return value of Ack() to a static or > global variable instead of using a local var This works because as far as GCC knows, clock() might be reading that global variable, so the sequence point after calling Ack() requires finishing it before calling clock(). > - 'hide' the second clock() call after the first > printf() statement That's not hiding, that's just that printf() can't be called before Ack() is finished, and again, as far as GCC knows, printf() might change data clock() uses, so clock() can't be called until printf() returns. > If gcc's out-of-sequence optimisation is prevented > by using one of the methods mentioned previously, > the program actually executes a touch faster. ... on the CPU you tried it on. Which may not be the one it was optimizing for. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.