Re: libgfortran3 respin : status and problem
On Sun, Mar 27, 2011 at 1:43 PM, marco atzeri wrote: > On Sun, Mar 27, 2011 at 10:15 AM, Yaakov (Cygwin/X) wrote: >> On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote: >>> which lapack ? 3.2.2-1 of distro ? >> >> 3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2. >> >> >> Yaakov >> > > Thanks, > I start to think that there is a problem in lapack-3.2.2.-2 built with > gcc-4.3.4-4. > > It looks that slartg never returns; I need to further dig. > > Marco I guess I catched. There is likely an optimization bomb that never exploded before during lapack building. For what ever reason gcc-4.3.4-4 activates it and all the previous version not. slamch.f and dlamch.f could fall in never ending loop if the optimization is active. The funny thing is that they were created in such a way to fool optimization to recover hardware real data. So at the end it is a PEBCAK problem from the first time that I adopted lapack and used automake/autoconf. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sun, Mar 27, 2011 at 10:15 AM, Yaakov (Cygwin/X) wrote: > On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote: >> which lapack ? 3.2.2-1 of distro ? > > 3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2. > > > Yaakov > Thanks, I start to think that there is a problem in lapack-3.2.2.-2 built with gcc-4.3.4-4. It looks that slartg never returns; I need to further dig. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote: > which lapack ? 3.2.2-1 of distro ? 3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sun, Mar 27, 2011 at 6:34 AM, Yaakov (Cygwin/X) wrote: > On Sat, 2011-03-26 at 11:33 +0100, marco atzeri wrote: >> the test case is a normal Fortran program that call numerical functions and >> print output with a really standard "write" command, nothing fancy. >> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7 > > FWIW, qrupdate's test suite WJFFM with DLL from recent CVS (2011-03-20) > and Ports' gcc 4.5.2-2 (which was also rebuilt for 1.7.8). > > > Yaakov > > which lapack ? 3.2.2-1 of distro ? Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sat, 2011-03-26 at 11:33 +0100, marco atzeri wrote: > the test case is a normal Fortran program that call numerical functions and > print output with a really standard "write" command, nothing fancy. > It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7 FWIW, qrupdate's test suite WJFFM with DLL from recent CVS (2011-03-20) and Ports' gcc 4.5.2-2 (which was also rebuilt for 1.7.8). Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On 03/26/2011 11:18 AM, marco atzeri wrote: --- snip --- Today I have cygwin-1.7.7 , libgfortran3-4.3.4-3, lapack-3.2.2-1, qrupdate-qrupdate-1.1.0-1 fine cygwin-1.7.8 , libgfortran3-4.3.4-4, lapack-3.2.2-2, qrupdate-qrupdate-1.1.1-1 broken (as also octave3.4.0-3) The full source is here, and it is a very tiny lib http://matzeri.altervista.org/cygwin-1.7/qrupdate/ Yes, well, are you going to debug this problem? yes but very slowly, my real job take me real busy and I have little spare time. I just got cygwin-1.7.8 loaded. I am going to see if I can then build gcc/gfortran, and go from there. Marco, please continue your efforts to a reduced example. Jerry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sat, Mar 26, 2011 at 5:05 PM, Corinna Vinschen wrote: > On Mar 26 11:33, marco atzeri wrote: >> On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen wrote: >> > So, what you see is a supposedly endless stream of calls to the write >> > function. Usually, if an error occurs, you would also see an error >> > message. The only reason you don't see it is if an error already >> > occured in an earlier call to write. The important would be prior to >> > the endless loop then. Maybe the testcase doesn't check for errors? >> >> the test case is a normal Fortran program that call numerical functions and >> print output with a really standard "write" command, nothing fancy. >> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7 > > What about current libgfortran3 and cygwin 1.7.7? What about previous > libgfortran3 and cygwin 1.7.8? I will make all the test as soon I built a simpler test case involving only libgfortran3 and cygwin . Currently qrupdate require lapack and lapack 3.2.2-1 was broken by the libgfortran3 update. Today I have cygwin-1.7.7 , libgfortran3-4.3.4-3, lapack-3.2.2-1, qrupdate-qrupdate-1.1.0-1 fine cygwin-1.7.8 , libgfortran3-4.3.4-4, lapack-3.2.2-2, qrupdate-qrupdate-1.1.1-1 broken (as also octave3.4.0-3) >> The full source is here, and it is a very tiny lib >> http://matzeri.altervista.org/cygwin-1.7/qrupdate/ > > Yes, well, are you going to debug this problem? yes but very slowly, my real job take me real busy and I have little spare time. > Corinna > Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Mar 26 11:33, marco atzeri wrote: > On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen wrote: > > So, what you see is a supposedly endless stream of calls to the write > > function. Usually, if an error occurs, you would also see an error > > message. The only reason you don't see it is if an error already > > occured in an earlier call to write. The important would be prior to > > the endless loop then. Maybe the testcase doesn't check for errors? > > the test case is a normal Fortran program that call numerical functions and > print output with a really standard "write" command, nothing fancy. > It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7 What about current libgfortran3 and cygwin 1.7.7? What about previous libgfortran3 and cygwin 1.7.8? > The full source is here, and it is a very tiny lib > http://matzeri.altervista.org/cygwin-1.7/qrupdate/ Yes, well, are you going to debug this problem? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On 03/26/2011 08:35 AM, Jerry DeLisle wrote: I have been monitoring this thread for the libgfortran maintainer side, but have not had time yet to investigate further. The only platform reporting the issue so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of Cygwin, but I will check the logs. The latest upstream change in libgfortran was May of 2010. That points to downstream tweaks or not related to libgfortran itself. Jerry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On 03/26/2011 03:33 AM, marco atzeri wrote:
On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen wrote:
On Mar 26 06:56, marco atzeri wrote:
Hi,
I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
( If you wan to try them, install with
setup.exe -X -O -s http://matzeri.altervista.org )
lapack tests passed
netcdf also (i am not 100% sure)
but testing qrupdate I catched another problem.
The test programs go in a never ending loop:
37 15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: waiting -1 ms
31 15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: acquired
33 15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
tty output_mutex released
That's not an endless loop as far as Cygwin is concerned. When a
process writes to the console, then every write is atomic. To accomplish
that, a mutex is used, like this:
write()
{
acquire mutex
while (there's still something to write)
write it
release mutex
}
So, what you see is a supposedly endless stream of calls to the write
function. Usually, if an error occurs, you would also see an error
message. The only reason you don't see it is if an error already
occured in an earlier call to write. The important would be prior to
the endless loop then. Maybe the testcase doesn't check for errors?
Corinna
the test case is a normal Fortran program that call numerical functions and
print output with a really standard "write" command, nothing fancy.
It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
-
write (*,*)
write (*,*) 'testing Cholesky rank-1 downdate routines.'
write (*,*) 'All residual errors are expected to be small.'
write (*,*)
n = 50
write (*,*) 'sch1dn test:'
call stest(n)
write (*,*) 'dch1dn test:'
call dtest(n)
write (*,*) 'cch1dn test:'
call ctest(n)
write (*,*) 'zch1dn test:'
call ztest(n)
-
subroutine smdump(name,m,n,A,lda)
character(*) name
integer m,n,lda
real A(lda,n)
integer i,j
write (*,1001) name
do i = 1,m
do j = 1,n
write(*,1002) A(i,j)
end do
write(*,*)
end do
--
I have been monitoring this thread for the libgfortran maintainer side, but have
not had time yet to investigate further. The only platform reporting the issue
so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of
Cygwin, but I will check the logs.
Jerry
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen wrote:
> On Mar 26 06:56, marco atzeri wrote:
>> Hi,
>> I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
>>
>> ( If you wan to try them, install with
>> setup.exe -X -O -s http://matzeri.altervista.org )
>>
>> lapack tests passed
>> netcdf also (i am not 100% sure)
>>
>> but testing qrupdate I catched another problem.
>> The test programs go in a never ending loop:
>>
>> 37 15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>> tty output_mutex: waiting -1 ms
>> 31 15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>> tty output_mutex: acquired
>> 33 15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
>> tty output_mutex released
>
> That's not an endless loop as far as Cygwin is concerned. When a
> process writes to the console, then every write is atomic. To accomplish
> that, a mutex is used, like this:
>
> write()
> {
> acquire mutex
> while (there's still something to write)
> write it
> release mutex
> }
>
> So, what you see is a supposedly endless stream of calls to the write
> function. Usually, if an error occurs, you would also see an error
> message. The only reason you don't see it is if an error already
> occured in an earlier call to write. The important would be prior to
> the endless loop then. Maybe the testcase doesn't check for errors?
>
>
> Corinna
the test case is a normal Fortran program that call numerical functions and
print output with a really standard "write" command, nothing fancy.
It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
-
write (*,*)
write (*,*) 'testing Cholesky rank-1 downdate routines.'
write (*,*) 'All residual errors are expected to be small.'
write (*,*)
n = 50
write (*,*) 'sch1dn test:'
call stest(n)
write (*,*) 'dch1dn test:'
call dtest(n)
write (*,*) 'cch1dn test:'
call ctest(n)
write (*,*) 'zch1dn test:'
call ztest(n)
-
subroutine smdump(name,m,n,A,lda)
character(*) name
integer m,n,lda
real A(lda,n)
integer i,j
write (*,1001) name
do i = 1,m
do j = 1,n
write(*,1002) A(i,j)
end do
write(*,*)
end do
--
The full source is here, and it is a very tiny lib
http://matzeri.altervista.org/cygwin-1.7/qrupdate/
May be a mutex problem in Fortran lib ?
We already had long time ago a "WRITE" problem
http://cygwin.com/ml/cygwin/2009-03/msg00428.html
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libgfortran3 respin : status and problem
On Mar 26 06:56, marco atzeri wrote:
> Hi,
> I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
>
> ( If you wan to try them, install with
> setup.exe -X -O -s http://matzeri.altervista.org )
>
> lapack tests passed
> netcdf also (i am not 100% sure)
>
> but testing qrupdate I catched another problem.
> The test programs go in a never ending loop:
>
> 37 15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
> tty output_mutex: waiting -1 ms
> 31 15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
> tty output_mutex: acquired
> 33 15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
> tty output_mutex released
That's not an endless loop as far as Cygwin is concerned. When a
process writes to the console, then every write is atomic. To accomplish
that, a mutex is used, like this:
write()
{
acquire mutex
while (there's still something to write)
write it
release mutex
}
So, what you see is a supposedly endless stream of calls to the write
function. Usually, if an error occurs, you would also see an error
message. The only reason you don't see it is if an error already
occured in an earlier call to write. The important would be prior to
the endless loop then. Maybe the testcase doesn't check for errors?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
