In message <200310051544.LAA80918@raptor.research.att.com> (on 5 October 2003 11:44:27 -0400), jpl@research.att.com (John P. Linderman) wrote: >Allen Smith guessed: > >> IP27? R10000 chip, I'm guessing? > >Right on both counts. > >Processor 0: 250 MHZ IP27 >CPU: MIPS R10000 Processor Chip Revision: 3.4 >FPU: MIPS R10010 Floating Point Chip Revision: 3.4 I thought as much, and I'm duplicating the failure here with: 2 180 MHZ IP27 Processors CPU: MIPS R10000 Processor Chip Revision: 2.6 FPU: MIPS R10010 Floating Point Chip Revision: 2.6 I'll be sending in smoketest reports on Monday morning (the automated smoketesting on most of the machines here seems to have gotten accidentally gonked by one thing or another, unfortunately). >> -DHAS_LDBL_SPRINTF_BUG but not -DHAS_LDBL_SPRINTF_BUG_LESS1? >> Interesting. I've seen this here also with an R5000 machine (non-64-bit), >> but hadn't had time to check things out further. I've done some >> rearrangements on the local smoketest configuration files and will see what >> happens > >I tried turning off -DHAS_LDBL_SPRINTF_BUG and all that did was >generate an *additional* failure from sprintf. Since the library is still buggy (I'm currently bugging my dissertation advisor to write up a Fortran test for it to see if it's also the case for Fortran's I/O, before we send in a bug report to SGI), unsurprising. >Didn't try -DHAS_LDBL_SPRINTF_BUG_LESS1, perhaps I'll give that a shot. That one _should_ be getting activated (the sprintf for long doubles problem turns out to be restricted to the range between -1 and 1, and the workaround is inadvisable if the bug isn't present (-DHAS_LDBL_SPRINTF_BUG activates the workaround, -DHAS_LDBL_SPRINTF_BUG_LESS1 deactivates it aside from the range between -1 and 1)); not sure why it isn't, will have to take a look when I have the time. -Allen -- Allen Smith http://cesario.rutgers.edu/easmith/ February 1, 2003 Space Shuttle Columbia Ad Astra Per Aspera To The Stars Through Asperity