[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 ...
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
More information about the Gcc-bugs
mailing list