Mail Archives: djgpp/2006/04/06/12:31:43
On 6 Apr 2006 08:50:04 GMT in comp.os.msdos.djgpp, Hans-Bernhard
Broeker <broeker AT physik DOT rwth-aachen DOT de> wrote:
>Brian Inglis <Brian DOT Inglis AT systematicsw DOT invalid> wrote:
>
>> The compiler should not be rearranging the order of calls to external
>> functions specified in separate statements, unless there were some
>> other factors involved that it could infer.
>
>Well --- it's not rearranging calls to external functions, since Ack()
>is not exactly an external function in the example case. The only
>calls to external functions are those to clock() and printf(), in that
>example, and those are left in their original order. The only strange
>thing is that GCC apparently detected that Ack() and clock() were
>independent jobs that could be done in parallel, since the result of
>one could not possibly depend on whether the other was finished yet.
>So it expanded Ack() inline (at least partially), and put the call to
>clock right in the middle of it.
>
>Unfortunately, that detection is wrong for a function like clock(). I
>may be going out on a limb there, but this could require a change to
>the declaration of clock() and similar functions to forbid this kind
>of optimization.
That kind of optimization is forbidden unless the (external) function
is declared with attributes pure or const (clock is not), or the
compiler can sufficiently determine the effect of the (internal)
function: even declaring the internal function static did not change
the code. If the compiler had inlined or reorganized the internal
function better, I could understand why it did what it did, but when
the workaround is declaring an auto variable (local) static, looks to
me like a bug: something is toggled the wrong way here.
--
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 -