http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255
--- Comment #2 from Seth Robertson <in-gnu at baka dot org> 2011-01-11 18:40:36 UTC --- Created attachment 22946 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22946 Revised test program exhibiting missed optimization Well, my point is that even if I remove the obvious side-effect, gcc cannot take advantage of the knowledge I am providing it. If instead of a printf() I make a system call which will return a (what I know/guarantee is, but is not declared as, a) ((const)) value (like getgid(), getuid(), or geteuid()) and use it in the expression, it is likewise not optimized. I'm attaching a second test program using these system calls. Test with `strace ./x 2>&1 | grep get | wc -l`. When you compile w/`gcc -O2` you should get the number 12. When you compile w/`gcc -O3` or with "-finline-functions -finline-small-functions", you get 21 (ie. it did more work than necessary). Of course without any optimization you get the maximum of 30. I am perfectly willing to believe that inlining happens first and throws away the information such that it will miss the opportunity to CSE. I also believe that if gcc could intuit that it was const (e.g. pure multiplication operations) that it wouldn't duplicate the work. I'm just saying this is a missed optimization. There could be a dup bug somewhere, but none of the tickets with "pure" or "const" and "__attributes__" subjects discuss it. Nor "inline' and 'cse'.
