Meador Inge added the comment: > 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8847> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com