On Apr 12, 2012, at 7:44 AM, Daniel D. Daugherty wrote: >> >> Why do we need to change compiler flags besides symbol generation ? >> >> e.g. for gcc -O3 -g3 is perfectly valid combination. > > You'd have to dig into the history of why a FASTDEBUG flavor build > chose the options that it did. All I'm doing is using their research.
Historically, the hotspot C++ code has sometimes stressed the C++ compilers we have used over the years, and in addition the dynamic code generated by Hotspot at runtime can sometimes conflict with the C++ compiler, both use various optimization tactics and sometimes they collide. I haven't heard of that happening recently, usually it happens when we switch to newer compilers on Windows and Solaris, but I'm sure it has happened with gcc too. Adding -g to an optimized build can complicate matters further. And it's not just the optimization level but all the various compiler options we use. Sometimes we just have to gear back due to size or time issues compiling one particular file. So with each 'build flavor' you create unique situations that need to be tweaked because of that unique flavor. I had tried to make sure that at least with Solaris, when the a compiler bug caused us to add or adjust the compiler options on a file, that a comment (with CR#) was placed around this area and the makefile logic would do an 'if compiler version is N.N or less', assuming the bug was fixed in N.N+1. This is all just a consequence of living in an imperfect world, and walking on the edge of the cliff, which Hotspot code often does. Be careful out there. -kto
