[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

rob1weld at aol dot com gcc-bugzilla@gcc.gnu.org
Tue Jan 27 16:18:00 GMT 2009

------- 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 ...




More information about the Gcc-bugs mailing list