Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

2021-10-23 Thread Thomas Koenig via Fortran

Hi Steve,


libgomp.fortran/async_io_[1,2,3,4,8,9].f90 account for a number
of FAILS on x86_64-*-freebsd.  Please fix.


I'd try to see what is going on, but I have been unable to boot gcc
(and thus gfortran) on any of the *BSD machines running on the
gcc compile farm, and more specifically on gcc303 which is a VM
running FreeBSD, after spending quite some hours on it.

I have submitted a couple of PRs, but apperenty others (including you)
have a working toolchain, so the PRs have been left unfixed so far.

Also, bootstrapping on gcc303 is going to be a very long process
because it's a two-processor machine :-|

So, any idea how to proceed?

Best regards

Thomas



Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

2021-10-23 Thread Steve Kargl via Fortran
On Sat, Oct 23, 2021 at 05:56:46PM +0200, Thomas Koenig wrote:
> Hi Steve,
> 
> > libgomp.fortran/async_io_[1,2,3,4,8,9].f90 account for a number
> > of FAILS on x86_64-*-freebsd.  Please fix.
> 
> I'd try to see what is going on, but I have been unable to boot gcc
> (and thus gfortran) on any of the *BSD machines running on the
> gcc compile farm, and more specifically on gcc303 which is a VM
> running FreeBSD, after spending quite some hours on it.
> 
> I have submitted a couple of PRs, but apperenty others (including you)
> have a working toolchain, so the PRs have been left unfixed so far.
> 
> Also, bootstrapping on gcc303 is going to be a very long process
> because it's a two-processor machine :-|
> 
> So, any idea how to proceed?
> 

I saw that you were having problems on the compile
farm with bootstrapping a *BSD gcc.  I simply cannot
tell why.  It just works on a true FreeBSD system.

Do you know how to run a single libgomp.fortran test?
I tried 

% gmake check-fortran RUNTESTSFLAGS="gomp.exp=async_io.f90"

but this runs all the testcases.  Now that I look at the
commit date of 2020-05-23 for async_io_9.f90, I know these
tests were passing in the past.  I fear a reason Sandra/Tobias
commit has broken things.

 

-- 
Steve


Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

2021-10-23 Thread Tobias Burnus

Hi Steve,

On 23.10.21 18:31, Steve Kargl via Fortran wrote:

Do you know how to run a single libgomp.fortran test? I tried
% gmake check-fortran RUNTESTSFLAGS="gomp.exp=async_io.f90"

but this runs all the testcases.


First, it should be RUNTESTFLAGS=  (test not tests).

Additionally, gomp.exp (for Fortran) is in 
gcc/testsuite/gfortran.dg/gomp/ but if you want to test 
libgomp/testsuite/libgomp.fortran/ (or libgomp.oacc-fortran/), you have 
to use "fortran.exp" (and not "gomp.exp").


And in order to make RUNTESTFLAGS effective, you cannot run in 
$(BUILD).* You either have to move to $(BUILD)/gcc – and run there "make 
check-fortran". For for libgomp, you need to go to 
$(BUILD)/$target_triplet/libgomp/ and run "make check" there. 
($target_triplet is "x86_64-pc-linux-gnu" on my laptop.)


(* at least it does not seem to work here.)

commit date of 2020-05-23 for async_io_9.f90, I know these
tests were passing in the past.  I fear a reason Sandra/Tobias
commit has broken things.


I sincerely doubt that our Fortran commits have broken this – they are 
not related to anything like TS29113, BIND(C), polymorphism or 
assumed-rank. I am even skeptical that any OpenMP change could have 
caused that, given that those do not really use OpenMP at all – but only 
pthreads (which is the reason they are in libgomp as OpenMP also depends 
on threads). Granted, as they are compiled with -fopenmp, libgomp is 
linked in (but should never be called, except for library initialization).


Nonetheless, if it used to work and now fails, something must have 
changed, causing the breakage.


If you compile and run the program manually without the DejaGNU, does it 
fail when compiled as is, compiled with -pthreads, compiled with -fopenmp?


Tobias



Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

2021-10-23 Thread Tobias Burnus

Hi Steve, hi Gerald,

@Gerald: Do you see those issues as well? Or do you have an idea what 
could go wrong?


@Gerald (and unrelated to the topic below): Can you provide more log 
data regarding the failing gfortran.dg tests? (Esp. excess errors but 
also the ICE.)


On 23.10.21 20:00, Tobias Burnus wrote:

On 23.10.21 18:31, Steve Kargl via Fortran wrote:

commit date of 2020-05-23 for async_io_9.f90, I know these
tests were passing in the past.


If I look at Gerald's results for x86_64-unknown-freebsd12.2 at 
https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/730072.html I 
do not see those async fails.


Tobias


Re: libgomp.fortran/async_io_[1,2,3,4,8,9].f90 fail on FreeBSD

2021-10-23 Thread Steve Kargl via Fortran
On Sat, Oct 23, 2021 at 08:00:44PM +0200, Tobias Burnus wrote:
> Hi Steve,
> 
> On 23.10.21 18:31, Steve Kargl via Fortran wrote:
> > Do you know how to run a single libgomp.fortran test? I tried
> > % gmake check-fortran RUNTESTSFLAGS="gomp.exp=async_io.f90"
> > 
> > but this runs all the testcases.
> 
> First, it should be RUNTESTFLAGS=  (test not tests).

Yes, of course, it was a typo,

> I sincerely doubt that our Fortran commits have broken this – they are not
> related to anything like TS29113, BIND(C), polymorphism or assumed-rank. I
> am even skeptical that any OpenMP change could have caused that, given that
> those do not really use OpenMP at all – but only pthreads (which is the
> reason they are in libgomp as OpenMP also depends on threads). Granted, as
> they are compiled with -fopenmp, libgomp is linked in (but should never be
> called, except for library initialization).
> 
> Nonetheless, if it used to work and now fails, something must have changed,
> causing the breakage.
> 
> If you compile and run the program manually without the DejaGNU, does it
> fail when compiled as is, compiled with -pthreads, compiled with -fopenmp?
> 

I have the gfortran.log file, I'll see if I can reduce the log
to determine why things are broken now.

-- 
Steve