Re: [patch, fortran] Implement maxloc and minloc for unsigned

[Thomas Koenig]

Am 05.10.24 um 22:52 schrieb Thomas Koenig:

Hi Jerry,

I see all the generated files in the patch, but I do not see the M4 
macro or other mechanism which generated these.  Was this in a 
previous submission that I missed?


The "magic" in this case is mentioning them in Makefile.am and
(regenerated) in Makefile.in.

The rest is done by the previous modification to m4/iparm.m4 in
5d98fe096b5d17021875806ffc32ba41ea0e87b0 , which generates
the type from the file name, in this case containing the 'm'
as the type-specifying letter.


To be a little bit more elaborate...

Since the patch which removed some machinery warnings, you have to use
--enable-maintainer-mode (and do the above). The generated files will
then be in (assuming your build directory is trunk/bin and the
architecture is AMD64 on Linux)
trunk-bin/x86_64-pc-linux-gnu/libgfortran/generated
and you then have to copy what's new over to
trunk/libgfortran/generated , then do a second bootstrap, preferably in
a separate directory) without --enable-maintainer-mode to see if
everything works right.

Best regards

Thomas

Re: [patch, fortran] Implement maxloc and minloc for unsigned

[Jerry Delisle]

The iparm.m4 was what I was looking for. Thanks,

Jerry

On Sun, Oct 6, 2024, 5:26 AM Thomas Koenig  wrote:

> Am 05.10.24 um 22:52 schrieb Thomas Koenig:
> > Hi Jerry,
> >
> >> I see all the generated files in the patch, but I do not see the M4
> >> macro or other mechanism which generated these.  Was this in a
> >> previous submission that I missed?
> >
> > The "magic" in this case is mentioning them in Makefile.am and
> > (regenerated) in Makefile.in.
> >
> > The rest is done by the previous modification to m4/iparm.m4 in
> > 5d98fe096b5d17021875806ffc32ba41ea0e87b0 , which generates
> > the type from the file name, in this case containing the 'm'
> > as the type-specifying letter.
>
> To be a little bit more elaborate...
>
> Since the patch which removed some machinery warnings, you have to use
> --enable-maintainer-mode (and do the above). The generated files will
> then be in (assuming your build directory is trunk/bin and the
> architecture is AMD64 on Linux)
> trunk-bin/x86_64-pc-linux-gnu/libgfortran/generated
> and you then have to copy what's new over to
> trunk/libgfortran/generated , then do a second bootstrap, preferably in
> a separate directory) without --enable-maintainer-mode to see if
> everything works right.
>
> Best regards
>
> Thomas
>
>
>

possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

[John Campbell]

I would like to report a problem I have identified with using "call
omp_set_num_threads (n)", which has appeared when on Windows 10 using
Gfortran version 11.3.0, (12.3.0 and 14.1.0). 

Prior versions ( 9.2.0, 10.2.0 and 11.1.0 run to completion.

The reproducer program below does not exit, but hangs after the last print
statement. ( I wonder if there are excess threads outside the END DO?)

 

I have experienced this problem for a while now, mainly with small
demonstration programs on https://fortran-lang.discourse.group, but now have
identified the cause of the program hanging.

 

I have listed a simple reproducer below which exhibits the problem if "call
omp_set_num_threads (4)" is included. I am not aware that this form of usage
of omp_set_num_threads has been made obsolete ?

 

I can confirm that the bug is not evident in equation.com's Gfortran 11.1.0
and earlier, but is present from Gfortran 11.3.0.

 

I am unsure where the bug is located. It could be in either Gfortran or
Equation.com's windows thread interface modifications.

 

Could others run the test example below to confirm where the problem is
identified.

 

Either the program runs to completion (ok) or hangs after "print..."
reporting the calculation result.

 

To confirm this problem, I have a windows test batch file to first select
the Gfortran version then compile and run the test.

I have 2 batch files : 

set_gcc.bat which updates the path for the required gfortran
version. I store different versions in C:\Program Files
(x86)\gcc_eq\gcc_xx.y.0 ( not provided)

do_test.bat which selects compiler, compiles the code example and
runs the test. (listed below, the first compiler options are from earlier
tests, but second also show error)

 

{{ do_test.bat }}

call set_gcc %1

 

set program=test4

set vec=-fimplicit-none -O3 -march=native -ffast-math -fopenmp
-fstack-arrays

set vec=-O2 -march=native -fopenmp

 

del %program%.exe

gfortran %program%.f90 %vec% -o %program%.exe

%program%

 

My latest test program is below, but probably could be further simplified.

{{ test4.f90 }}

program test

 

!  small working version of OpenMP program hanging on Win 10 with Gfortran
11.3.0 +

  use iso_fortran_env

   implicit none

 

integer, parameter :: num = 1000

real:: A(num)

 

real:: RA

integer :: i

 

write (*,*) 'Vern : ',compiler_version ()

write (*,*) 'Opts : ',compiler_options ()

 

call omp_set_num_threads (4)   ! omit to run to completion with recent
Gfortran versions

  

 write ( *,*) 'Test n=',num

 A = 1

 ra = 0

 

  !$OMP PARALLEL DO private (i) shared (A), REDUCTION (+: RA)

 do i = 1, size(A)

   RA = RA + A(i)**2

 end do

  !$OMP END PARALLEL DO

 

 RA = sqrt (RA)

 print*,RA,' OpenMP', sqrt(real(num))

 

!   Program hangs here but does not exit on recent Gfortran versions

!Gfortran versions since 11.1.0 hang, however if "call
omp_set_num_threads (4)" is omitted runs to completion.

!Gfortran versions 11.1.0 and earlier run to completion.

 

end program test

!

 

Could others please confirm if you can reproduce this problem.

 

Regards,

 

John Campbell

 

Re: possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

[Thomas Koenig]

Hi John,

I would like to report a problem I have identified with using “call 
omp_set_num_threads (n)”, which has appeared when on Windows 10 using 
Gfortran version 11.3.0, (12.3.0 and 14.1.0).


Prior versions ( 9.2.0, 10.2.0 and 11.1.0 run to completion.

The reproducer program below does not exit, but hangs after the last 
print statement. ( I wonder if there are excess threads outside the END DO?)


I have experienced this problem for a while now, mainly with small 
demonstration programs on https://fortran-lang.discourse.group 
, but now have identified the 
cause of the program hanging.


I have listed a simple reproducer below which exhibits the problem if 
"call omp_set_num_threads (4)" is included. I am not aware that this 
form of usage of omp_set_num_threads has been made obsolete ?


I tried your program on Linux (current trunk and 11.4), Cygwin under
Windows (11.4.0) and the mingw-w64 cross compiler under Cygwin (also
11.4.0). None of these compilers had issues,so

> I am unsure where the bug is located. It could be in either Gfortran
> or Equation.com's windows thread interface modifications.

it seems to be a bug introduced by equation.com, which should be
reported to them.

Maybe you are better off using the mingw-64 compiler, available from
their website (together with msys2).

Best regards

Thomas

Re: possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

[Steve Kargl]

On Sun, Oct 06, 2024 at 07:16:18PM +1100, John Campbell wrote:
> 
> I can confirm that the bug is not evident in equation.com's Gfortran 11.1.0
   
This is your problem.

> and earlier, but is present from Gfortran 11.3.0.

Program seems to work on x86_64-*-freebsd.

-- 
Steve