> This is probably meant to imply that pointers to different functions must
> not compare equal.

I think so.  Also, in our case the functions have different names, therefore
they can't be the "same" function.

> So if this is determined to be a compiler bug, the most natural conclusion
> is to stop using PGI/PGO entirely.

I think it is non-conformant behavior.  Microsoft warns about it in their
documentation, but they don't go as far to say it is non-conformant.

Also, this isn't really a problem with PGO.  AFAICT, it is the COMDAT folding
optimization in the linker.  That optimization just happens to be enabled on
our PGO configurations.

Do we even use PGO to the fullest extent?  Does someone actually build an
instrumented Python, run training inputs on it, and then rebuild with the
training data to take advantage of the profile-guided optimizations?  If not,
then I doubt PGO is buying us anything anyway.

Also, PGO is only available on the Premium and Ultimate versions of VC++ [1].
I noticed when building with VC++ 2010 Express on the PGI/PGO builds that it
warns about PGO not being available.  I don't know what version we build our
Python release bits with.

[1] http://msdn.microsoft.com/en-us/library/hs24szh9.aspx