Mail Archives: djgpp/2006/04/02/06:16:47
On 29 Mar 2006 12:34:54 GMT in comp.os.msdos.djgpp, Hans-Bernhard
Broeker <broeker AT physik DOT rwth-aachen DOT de> wrote:
>Martin Steuer <martin AT x DOT invalid> 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
- Raw text -