Re: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant
[CCing to debian-alpha] As Chris (currently listed as package maintainer for gcc alpha) seems to be away, I'll ask on debian-alpha (Falk?), if this patch should be included. In that case the documentation should be changed to explicitely mention Debian instead of Linux. Tyson Whitehead writes: > On Sunday 28 September 2003 14:54, you wrote: > > did you submit this patch upstream? If not, please can you do and > > attach the upstream PR? > > > > Thanks, Matthias > > Hi Matthias. I'm not quite sure by what you mean be upstream. Is it a > Debian > thing or a GNU thing. If it's the later, I posted a message on GNU GCC > mailing list about it a month or two ago. > > It didn't go anywhere. Richard Henderson (the Alpha fellow from Red Hat) > said > he wouldn't accept it into the general GCC unless all users of GCC (i.e. BSD, > etc) came forward and said they wanted it. > > He also gave three reasons why he personally didn't like it: > 1- The default under DEC C is to not IEEE compliance > 2- IEEE compliance leads to 'severe' performance penalties > 3- The vast majority of SIGFPEs are due to unitialized data reads > > While one and three might be true (timing tests show that two is just plain > wrong), they miss the point of the patch. > > The patch is intended to help achieve the goal of having as many packages as > possible run on the Debian Alpha distribution as possible (without needing to > specify Alpha specific flags). > > This means matching the GNU defaults on the other Debian architectures, and > that just happens to be IEEE compliant libraries and code. > > Thanks -T > > -- > Tyson Whitehead ([EMAIL PROTECTED] -- WSC-) > Computer EngineerDept. of Applied Mathematics, > Graduate Student- Applied MathematicsUniversity of Western Ontario, > GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada
Re: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant
Matthias Klose <[EMAIL PROTECTED]> writes: > As Chris (currently listed as package maintainer for gcc alpha) > seems to be away, I'll ask on debian-alpha (Falk?), if this patch > should be included. I'd vote for not including it like it is now. > > Richard Henderson (the Alpha fellow from Red Hat) said he wouldn't > > accept it into the general GCC unless all users of GCC (i.e. BSD, > > etc) came forward and said they wanted it. > > > > He also gave three reasons why he personally didn't like it: > > 1- The default under DEC C is to not IEEE compliance > > 2- IEEE compliance leads to 'severe' performance penalties > > 3- The vast majority of SIGFPEs are due to unitialized data reads > > > > While one and three might be true (timing tests show that two is > > just plain wrong), Well, 20% looks pretty severe to me. > > they miss the point of the patch. > > > > The patch is intended to help achieve the goal of having as many > > packages as possible run on the Debian Alpha distribution as > > possible (without needing to specify Alpha specific flags). Then we should also compile with -O0 to avoid triggering bugs? There has to be some trade-off. > > This means matching the GNU defaults on the other Debian > > architectures, and that just happens to be IEEE compliant > > libraries and code. It has also been a GNU policy to not be standards compliant just for the sake of it. Very little code actually needs IEEE complicance. Like rth, I'd say as a minimum -ffast-math should turn off IEEE complicance. When that's the case, the patch would be OK with me, since actually also very little code needs high floating point performance. -- Falk
Re: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant
On Monday 06 October 2003 03:42, Falk Hueffner wrote: > > > Richard Henderson (the Alpha fellow from Red Hat) said he wouldn't > > > accept it into the general GCC unless all users of GCC (i.e. BSD, > > > etc) came forward and said they wanted it. > > > > > > He also gave three reasons why he personally didn't like it: > > > 1- The default under DEC C is to not IEEE compliance > > > 2- IEEE compliance leads to 'severe' performance penalties > > > 3- The vast majority of SIGFPEs are due to unitialized data reads > > > > > > While one and three might be true (timing tests show that two is > > > just plain wrong), > > Well, 20% looks pretty severe to me. For the record, the test results are as follows (on an EV56 machine): The programs: a) A hard coded C loop that takes 1024 complex Fast Fourier Transform of 2048 vector doubles. b) Monte Carlo option pricing. c) Molecular Dynamics simulation. The results (with out/with): a) 9.4s / 11.4s (82.5%) b) 10.2s / 10.3s (99.0%) c) 191.0s / 201.2s (95.0%) Program (a) was chosen to give an upper bound (as it did nothing but crunch crunch crunch in a tight loop). Programs (b) and (c) (two pieces of code from our department I had access to) to be Representative of the more standard intensive numerical simulations (i.e. code that has to maintain data structures for dynamic meshing, etc). I guess all can draw their own conclusions. However, I think it's fairly safe to conclude that the difference made to the performance of Joe average application is not even going to be measurable over OS noise. Do keep in mind that the purpose of the patch is simply to minimize work. The set of all packages that don't require IEEE compliance and need -mno-ieee to perform acceptably (I personally only know of one -- the FFTW libraries) is a lot smaller than those that SIGFPE without -mieee. > Like rth, I'd say as a minimum -ffast-math should turn off IEEE > complicance. When that's the case, the patch would be OK with me, > since actually also very little code needs high floating point > performance. I don't have time right now to look at any more GCC code, but from what I have seen, the OVERRIDE_OPTIONS macro looks like it might do what you are looking for. Possibly someone with could code this up as an additional patch. In the meantime, you can always specify -mno-ieee. Later -T -- Tyson Whitehead ([EMAIL PROTECTED] -- WSC-) Computer EngineerDept. of Applied Mathematics, Graduate Student- Applied MathematicsUniversity of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada
