Google is a powerful toy:

However they didn't correct yet a couple of very nasty bugs I found.. time to register for the beta program and report the bugs.
Posted on 2006-10-01 08:37:25 by Maverick
google is nice :)

What are those bugs you found?
Posted on 2006-10-01 09:23:36 by f0dder

Hei Sune :)

One, the serious and nasty and subtle one, I already reported on Usenet:

The other, to be pedantic, is not strictly a bug, but for me it is anyway. :)
I am using link time code generation to aggressively optimize for space and speed (by better inlining, etc..) and if I "help" the linker by compiling with the /Gy option, the compiler goes way too far. While it absolutely should merge two identical functions into one piece of code, if I take the address of any of them (via the & operator), it should create unique instances of them in my opinion, because it's clear that the programmer is taking the address of those functions for identification purposes. It creates an instance of the function (otherwise you could not take the address of it), but it's not unique. If you simply invoked the functions, then the optimizer would be entitled to merge them into one piece of code, absolutely. But to optimize so that &function1==&function2 (identical body) I think even violates ISO C++ specifications (haven't looked at this, though, since I don't really care about standards compliance because C++ is just a temporary migration tool for me towards my own compiler and language).
So I have to disable the option, via /Gy-, but this also causes function that would otherwise be always only inlined to appear in the EXE, making it uselessly bigger. I use to #include only what I need, but I think it would be
handy if the compiler didn't put in the EXE functions that were never called. I hoped that the Service Pack would have fixed this problem and make the compiler do the right thing. It's obvious that if you take the address of a function and compare it you are doing it for identification purposes. C++ is not assembly, doing it for other purposes would surely violate some ISO C++ rules anyway.

Sorry, am in a hurry and cannot Express myself better at it right now.. also because English is not my native programming language (and even less so C++). :P

Posted on 2006-10-01 09:49:47 by Maverick

Oh yes.. I found a better workaround for the second issue: the /OPT:NOICF linker option (still keeping the /OPT:REF though).

It would be nicer if the optimizer still pooled identical functions when they are only invoked but not taken the address of, anyway it's still better than disabling /Gy completely. :)

The first bug instead needs a fix by MS or I'll have to look at all my sources for every "struct {" and insert before those two tokens the symbol after the corresponding "}".

When you have thousands modules you really want to wait that they fix the bug, since it is definitely a (very subtle and thus bad) bug. If they won't, I'll write an utility to do the needed workaround, otherwise my hands and eyes will get consumed soon fixing tens of thousands of struct/class declarations..  :lol:
Posted on 2006-10-01 11:59:50 by Maverick