Marcin Dalecki wrote: > Sorry but I just got completely fed up by the references to "math" by > the original post, since the authors leak of basic experience in the > area of numerical computation was more then self evident.
My apologies for not meeting your high intellectual standards, ;P > Making the code generated by GCC somehow but not 100% compliant with > some idealistic standard, will just increase the scope of the > analysis you will have to face. And in esp. changing behavior > between releases will just make it even worser. Perhaps my understanding of math isn't as elite as yours, but I do know that "worser" isn't a word. ;) Then again, I *am* the fellow who started a thread with "Porposal" in the title. It sounds like I'm making a suggestion about dolphins... :) > Only the following options would make sense: > > 1. An option to declare 100% IEEE compatibility if possible at all on > the particular arch, since it's a well known reference. > > 2. An option to declare 100% FPU architecture exposure. > > 3. A set of highly target dependent options to control some well > defined features of a particular architecture. (Rounding mode, > controll, use of MMX or SSE[1234567] for example...) I would replace 3 above with: 3. When compiled without either of the above options, adhere strictly to the relevant language standard. Given that Java, Fortran 95, C and C++ all have differences in their definitions of floating-point, this will need to be (as it already is, to some extent) language-specific. > Any kind of abstraction between point 1. and 2. and I would see > myself analyzing the assembler output to see what the compiler > actually did anyway. On further reflection, I don't see how a middle ground can even be defined. The three states above seem to make sense: IEEE, hardware, or language standard. > And last but not least: Most of this isn't really interesting at the > compilation unit level at all. This is the completely uninteresting > scope. If anything one should discuss about the pragma directive > level, since this is where fine control of numerical behavior happens > in the world out there. The ability to say for example: > > #pragma unroll 4 sturd 8 > > would be really of "infinite" more value then some fancy -fblah-blah. GCC seems to have a fancy for options, since that is what most people ask for. I agree that a set of "tuning" pragmas would be a good way of defining the compilation requirements for a given algorithm. I'm always open to friendly, intelligent conversation. Starting off by being high-handed and insulting (as you did) accomplishes nothing. ..Scott