[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #6 from rob1weld at aol dot com 2009-01-27 15:50 --- Here is a newer result on Fedora 10: === gfortran tests === Running target unix === gfortran Summary === # of expected passes29107 # of expected failures 14 # of unsupported tests 113 /mnt/drive2/gcc_build/gcc/testsuite/gfortran/../../gfortran version 4.4.0 20090126 (experimental) [trunk revision 143680] (GCC) # grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | grep -v XFAIL # grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | wc -l 14 It works OK (now) on i386-redhat-linux-* . Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #7 from rob1weld at aol dot com 2009-01-27 16:00 --- (In reply to comment #5) ! Test XFAILed on these platforms because the system's printf() lacks ! proper support for denormalized long doubles. See PR24685 Looks like this testcase should be xfailed on solaris also. Eric says PR24685 works on Solaris (which is not the same OS as mine): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685#c27 Should libiberty test if the printf() fails and replace it we a better one? Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #8 from rob1weld at aol dot com 2009-01-27 16:18 --- (In reply to comment #4) (In reply to comment #3) This is not so much an error in Fortran than it is an error in the scripting and it's ability to add it's own LD_LIBRARY_PATH components. No. The current linking scheme links to the just-built libgfortran, not to the system libgfortran. This is fine, because it is the newly built library that we want to test. No. It is the same library since I type make install before I type make -i check. They worked last week. Sure, this is a regression. I installed cloog in /usr/local on F10 and needed to use LD_LIBRARY_PATH on this platform also. On i386-redhat-linux we don't have any trouble. Here is my most recent test. Above you ask Could you try before/after this do you mean compile and run the Testuite on both r143461 and r143463? Yes. But to save time you can update only fortran or libgfortran and narrow the testsuite run to the failing tests using the RUNTESTFLAGS variable as explained here http://gcc.gnu.org/wiki/TestCaseWriting OK, I'll be back on my OpenSolaris platform tomorrow. Furthermore, as your tests show that the failure is in the libgfortran, there is only one commit in that area in the window you gave (r143454-r143562): r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines I don't know though how this could cause system-dependent failures :-(. Daniel? No reply. Thanks for fixing this, Thanks for helping to fix this. One piece at a time ... Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
Re: [Bug testsuite/38946] [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test.
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #9 from dj at redhat dot com 2009-01-27 19:38 --- Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #10 from rob1weld at aol dot com 2009-01-27 22:28 --- (In reply to comment #1) Note that some of the tests require specific features (such as denormalized long doubles) and are ... (In reply to comment #4) (In reply to comment #3) This is not so much an error in Fortran than it is an error in the scripting and it's ability to add it's own LD_LIBRARY_PATH components. No. The current linking scheme links to the just-built libgfortran, not to the system libgfortran. This is fine, because it is the newly built library that we want to test. ... I don't know though how this could cause system-dependent failures :-(. Daniel? How about this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38820 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443#c36 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #11 from rob1weld at aol dot com 2009-01-27 22:45 --- (In reply to comment #9) Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously I think adding a printf() clone to libiberty is WAY overkill just to silence one failing test. Two alternatives are: 1. A POSIX compliant Testsuite to check gcc libraries. Any program, on any platform, using (new) gcc _must_ printf() the _same_ output under any circumstances. 2. Incorrect operation. Sometimes there is one failing test because the Testsuite Coverage is poor (and we hope more Tests will be forthcoming). RFE - Need Makefile to test coverage of Testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38833 By the term Testsuite Coverage I mean both in that the tests that we do have do not fully exercise the features they test _and_ also that we do not test all possible features but instead we slack off and simply disable the Tests (as is being suggested in this Thread). I believe Bug 36443 should be investigated first but failing that is it not the place of Libiberty to fix what GNU believes is broken? Wave @ DJ (net-acquaintance of 25+ years), Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #12 from rob1weld at aol dot com 2009-01-27 23:26 --- (In reply to comment #11) (In reply to comment #9) Two alternatives are: I guess there is three. 3. The gcc Testsuite is testing 'outside of gcc' and exercising the libraries of the Operating System (maybe GNU libc / libmath, maybe not). Features of the Operating System are checked for in ./configure and compensated for with: 1. alternate source, 2. #ifdefs, 3. Libiberty. Using the Testsuite to check outside the scope of the Testsuite is not valid and should be removed _OR_ at the very least we should split this into a different test and have it excluded on all platforms that do not support this ONE Operating System specific feature. That course of action means that other system libraries would also need to be excluded. You would not want to test Sun's libm for errors, compare that with any other library, and on that basis determine that the gcc Testsuite passed or failed. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug testsuite/38946] [trunk regression]�gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-26 19:28 --- ! Test XFAILed on these platforms because the system's printf() lacks ! proper support for denormalized long doubles. See PR24685 Looks like this testcase should be xfailed on solaris also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
