http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
--- Comment #5 from jvdelisle at frontier dot com 2011-04-03 21:14:41 UTC --- On 04/03/2011 12:49 PM, inform at tiker dot net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 > > --- Comment #3 from Andreas Kloeckner<inform at tiker dot net> 2011-04-03 > 19:49:51 UTC --- > (In reply to comment #2) >> There is already -fdefault-real-8, -fdefault-integer-8, and >> -fdefault-double-8. This is already 3 too many hacks. Adding >> an additional 7 options is 7 too many. > >> From a purist perspective, I absolutely gree with you. Practically however, > in dealing with legacy codes (*), the value of being able to do this should > not > be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu > have included these flags? > Lets take another perspective, different than Steve's comments. Lets assume no-one is blindly using the legacy codes with changes in default kinds without at least some understanding of the code and knowing what it is doing. With modern editors or scripts, one could modify declarations to use a kind=parameter. This could be done to change REAL to REAL(kind=wp). wp meaning working precision. One could also update real constants to append _wp to them. Then add a use statement at the beginning of each file that sets wp. Several different precision parameters could be set up and used in varying places depending on the application. One gets a finer degree of control. Now I have presented a simplistic example and I am sure the real code may offer some additional challenges. But, the net result would be more flexible code that is more portable and the original issue becomes moot. If ones knowledge of the code is greater then mine it is likely one could see more opportunities for improving it with simple changes like this, especially in the code that is critical to the issue. Once the changes are made, perhaps even incrementally over time in small parts, they never have to be changed back, because the code is standard conforming to do so. Now, we can make arguments to go in either direction; put the burden of resolving the issue on the compiler team or put the burden on the user/developers. I think Steve is saying that we have an obligation on the compiler side to protect users who may not be as knowledgeable/experienced from doing stupid things, whereas someone such as yourself would probably know what to be careful of and could avoid it. Providing the adjustable precision on the user/developer side assures that it is done carefully and correctly, specific to the application. Now the flip side is that the less than 100 lines of code patch on the compiler side is a lot less effort then perhaps updating the 100,000 lines of legacy code. However, the compiler changes affect thousands of users and thousands of applications. That means there is, lets say, 1000 times more risk to the change on the compiler side. (With no warranty of course). I am leaning toward we need to err on the conservative side, and let others comment from here. We have had these discussions on this topic many times before. I don't think there is an easy answer. My personal preference would be to update the user code. (aka software maintenance). Regards
