Caveat: GCC-based analysis unreliable for Free Software [LWN.net]

Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 27, 2010 16:19 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
In reply to: Caveat: GCC-based analysis unreliable for Free Software by pjm
Parent article: LCA: Static analysis with GCC plugins

(ii) By using less of gcc, there's more work for the analysis code to do. For example, you need to work out what all the valid evaluation orders are,

You just need to scan the list once and work out if any of the arguments have side effects. If two arguments have side effects on objects that may alias (and I imagine you can consult GCC's alias analysis to get a "YES/MAYBE/NO" answer), throw a warning.

That doesn't require generating and analyzing all N! potential orderings among N arguments. It just requires an O(M²) loop to check pairwise for all pairs, where M is the number arguments with side effects. M is generally rather small, too.

And I'd hope GCC has functions to help you find the arguments with side effects.

(Log in to post comments)

Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 28, 2010 0:15 UTC (Thu) by marcH (subscriber, #57642) [Link]

> If two arguments have side effects on objects that may alias throw a warning.

I think a warning should be thrown even if just one argument has a side-effect on any other.

But to be honest a side-effect in argument passing should not even pass code reviews in the first place. Any side-effect deserves at least a (practically free) temporary variable.

Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 28, 2010 16:20 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

I think a warning should be thrown even if just one argument has a side-effect on any other.

You know, that's closer to what I really meant. I guess I got in a hurry and didn't completely think through what I was suggesting. Basically, if any argument looks like it could potentially modify any other argument, flag it.

But to be honest a side-effect in argument passing should not even pass code reviews in the first place. Any side-effect deserves at least a (practically free) temporary variable.

I agree. There was a similar (but not identical) situation that bit me once when porting DOOM to one of our DSPs at work for a demo. In the case of DOOM, it wasn't argument order to a function call, but rather order of evaluation of terms in an expression.

The weird behavior I was seeing was that the built-in demo (which serves as something like a test case) wouldn't run correctly because the player and/or bad guys wouldn't take exactly the same course they did when the demo was recorded. The DOOM engine is supposed to be deterministic--if you run through the course in exactly the same way every time, then everything should behave identically.

DOOM has a "random number" function (P_Random()) that just returns the next unsigned byte out of a table of random bytes, keeping a pointer to which one is next. It resets this pointer at the start of the game. This allows the engine to ask for a "random" number and get a deterministic stream each time. That function was fine. The problem was with how it was being called.

There were several places in the code where the engine wanted a signed random number that had more of a triangular distribution. To get that, it would do this: P_Random()-P_Random() That idiom appears about a dozen places in the code.

You can guess what happened. GCC would make the two function calls in left-to-right order. Our DSP's compiler, however, made them in right-to-left order. *d'oh*

Same class of problem (getting burned by side effects where order isn't defined), just a different manifestation. It was this particular case I had in mind when I made my original comment. That said, your point is still quite valid. foo(x, ++x) is no better than foo(++x, ++x).