X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Trace-PostClient-IP: 68.147.232.190 From: Brian Inglis Newsgroups: comp.os.msdos.djgpp Subject: Re: new gcc 4.10 behaviour Organization: Systematic Software Message-ID: <6q6v225evfpih3nbj2ts20qre7br1i8an7@4ax.com> References: <1143542847 DOT 613686 DOT 87820 AT v46g2000cwv DOT googlegroups DOT com> <48sjvaFlir4cU1 AT news DOT dfncis DOT de> <48v4k4Fm65abU1 AT news DOT dfncis DOT de> <48vd7eFm0rukU5 AT news DOT dfncis DOT de> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 47 Date: Sun, 02 Apr 2006 10:01:14 GMT NNTP-Posting-Host: 64.59.135.176 X-Complaints-To: abuse AT shaw DOT ca X-Trace: pd7tw2no 1143972074 64.59.135.176 (Sun, 02 Apr 2006 04:01:14 MDT) NNTP-Posting-Date: Sun, 02 Apr 2006 04:01:14 MDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On 29 Mar 2006 12:34:54 GMT in comp.os.msdos.djgpp, Hans-Bernhard Broeker wrote: >Martin Steuer wrote: > >> And if not, why? Would the optimizer have to assume that the first call >> to clock has changed the internal state of that function? > >Generally it would --- but not if the two calles are initializers of >variables. The initializer guarantees a sequence point: see below. >> And in general: how can one guarantee a certain order of execution for >> code like that from the OP? > >By making them statements, rather than series of variable definitions. >That changes introduces what the C standard calls "sequence points", >which the optimizer must respect, and thus maintains order of things. ISO C 9899-1999 Annex C Sequence points "1 The following are the sequence points described in 5.1.2.3: ... - The end of a full declarator: declarators (6.7.5); - The end of a full expression: an initializer (6.7.8); ..." >This would appear to be a side effect of the C99 feature allowing >variable definitions to occur in the middle of a block, rather than at >the start of it only. Then it's a bug, perhaps over zealous optimization, perhaps in (an internal) definition of the clock function assuming attributes const or pure apply (when they do not); in such cases, an optimizer could hoist or rearrange a function call, but it should not in this case. It's also a suspicious coincidence that the poster reports a speed increase of 5 times, and that ticks are 18.2/sec but multiplied by 5 so that CLK_TCK and CLOCKS_PER_SEC can be kept as an integral 91; perhaps the ticks are being multiplied by 5 elsewhere, as well as in clock.c? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian DOT Inglis AT CSi DOT com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply