In this case, it seems that the second parameter gets evaluated first.
(I used the FPC 3.0.4 on Linux x86-64)
But may I rely on this behaviour? Or does it depend on compiler optimizations an/or settings? And what about different compiler versions?
not tested but maybe make it inlined?
It's semi-documented here (https://wiki.freepascal.org/Code_Conversion_Guide#Order_of_parameter_evaluation) (and probably should be added to the official documentation).
Inlining doesn't guarantee when each parameter will be evaluated, so the "problem" persist: the inlined code for the second parameter might be either before or after that of the first, depending on target, optimization level, phase of the moon, ...
Inlining doesn't guarantee when each parameter will be evaluated, so the "problem" persist: the inlined code for the second parameter might be either before or after that of the first, depending on target, optimization level, phase of the moon, ...
OP should also note that PascalDragon didn't say "implementation defined", i.e. might depend on the target and the precise version of the compiler, he specifically said "may apply better optimizations" so there's no guarantee that consecutive invocations of the same function will have the same parameter evaluation order. And I suspect that inlining, by potentially allowing the optimiser to look at a bigger tree, could make that "worse" rather than "better".
I have run into this already using fpc. in 32 bit target I can use the PASCAL call convention and it seems to always call the arguments in the order that I present them... AS it should be
Calling the function inc twice within another function call (mean) obviously leads to different results, depending on the order of parameter evaluation.I understand that this is exactly why Inc and Dec are procedures in Pascal. Ambiguity caused by these functions in other languages is notorious.