date:20230308


On 08.03.23 22:35, I wrote:

On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.


I can confirm that.

I presume that this is a serious regression since it involves 
optimization?

Which component should I post it against?


Probably against tree-optimization.  If later analysis determines that
it is something else, people will reassign it.

This one probably calls for bisection.


I have submitted this as

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 .

Paul, thanks for catching this!

@Richard: Is there a possibility of doing regular Polyhedron runs
at Suse in addition to the SPEC runs?  This could also be interesting.

Best regards

Thomas

Re: [PATCH][stage1] Remove conditionals around free()

2023-03-08 Thread Thomas Schwinge

Hi Bernhard!

On 2023-03-01T22:28:56+0100, Bernhard Reutner-Fischer via Gcc-patches 
 wrote:
> // POSIX: free(NULL) is perfectly valid
> // quote: If ptr is a null pointer, no action shall occur.
> @ rule1 @
> expression e;
> @@
>
> - if (e != NULL)
> -  { free(e); }
> + free (e);

Nice, Coccinelle/spatch!  (Another very interesting tool that I so far
had no chance to actually use.)

> # find ./ \( -name "*.[ch]" -o -name "*.cpp" \) -a \( ! -path 
> "./gcc/testsuite/*" -a ! -path "./gcc/contrib/*" \) -exec spatch --sp-file 
> ~/coccinelle/free-without-if-null.0.cocci --in-place

Also include '*.cc' if you'd like to find some more in 'gcc/' (and
possibly elsewhere, too) than just the following lonely one.  ;-)

> --- a/gcc/ada/rtinit.c
> +++ b/gcc/ada/rtinit.c
> @@ -481,8 +481,7 @@ __gnat_runtime_initialize (int install_handler)
>
>FindClose (hDir);
>
> -  if (dir != NULL)
> -free (dir);
> +  free (dir);


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch, fortran] PR37336 finalization


On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.


I can confirm that.


I presume that this is a serious regression since it involves optimization?
Which component should I post it against?


Probably against tree-optimization.  If later analysis determines that
it is something else, people will reassign it.

This one probably calls for bisection.

Regards

Thomas

Segfault when using defined assignment

2023-03-08 Thread Andrew Benson via Fortran

I opened a PR on bugzilla for the following:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066

The following code (compiled using current trunk), when run, causes a 
segfault, and valgrind complains about an invalid read. The code appears 
correct to me, and runs correctly (no segfault, no warnings from valgrind) 
when compiled with ifort.

module Input_Parameters_Bug
  public
  
  type :: resourceManager
 integer   :: counter=0 ! Remove this to resolve segfault
   contains
 procedure :: resourceManagerAssign
 generic   :: assignment(=) => resourceManagerAssign
  end type resourceManager

  type hdf5Object
 private
 type   (resourceManager) :: objectManager
   contains
 procedure :: openGroup =>IO_HDF5_Open_Group
! procedure :: h5Assign  ! Add this defined assignment to avoid segfault.
! generic   :: assignment(=) => h5Assign
  end type hdf5Object

  interface hdf5Object
 module procedure hdf5Constructor
  end interface hdf5Object

  type :: inputParameters
 private
 type(hdf5Object), pointer :: outputParameters => null() ! Make this 
allocatable instead of pointer to resolve segfault
  end type inputParameters

  interface inputParameters
 module procedure inputParametersConstructorNode
  end interface inputParameters

contains

  subroutine resourceManagerAssign(to,from)
implicit none
class(resourceManager), intent(  out) :: to
class(resourceManager), intent(in   ) :: from
to%counter=from%counter+1
write (0,*) "ASSIGN",to%counter
return
  end subroutine resourceManagerAssign

  function hdf5Constructor() result(self)
implicit none
type(hdf5Object) :: self
return
  end function hdf5Constructor
  
  function IO_HDF5_Open_Group(inObject) result (self)
implicit none
type(hdf5Object) :: self
class(hdf5Object), intent(in   ) :: inObject
write (0,*) "OPEN"
return
  end function IO_HDF5_Open_Group
  
  subroutine h5Assign(to,from)
implicit none
class(hdf5Object), intent(  out) :: to
class(hdf5Object), intent(in   ) :: from
write (0,*) "ASSIGN H5"
to%objectManager=from%objectManager
return
  end subroutine h5Assign

  function inputParametersConstructorNode(outputParametersGroup) result(self)
implicit none
type(inputParameters) :: self
type(hdf5Object ), intent(in   ) :: outputParametersGroup
allocate(self%outputParameters)
write (0,*) "START"
self%outputParameters=outputParametersGroup%openGroup()
write (0,*) "STOP"
return
  end function inputParametersConstructorNode

end module Input_Parameters_Bug

program Test_Parameters_Bug
  use :: Input_Parameters_Bug
  implicit none
  type(hdf5Object)  :: outputFile
  type(inputParameters) :: testParameters
  outputFile=hdf5Object()
  write (0,*) "CALL"
  testParameters=inputParameters(outputFile)
end program Test_Parameters_Bug


$ gfortran bug.F90 -g
$ valgrind --track-origins=yes ./a.out 
==19625== Memcheck, a memory error detector
==19625== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19625== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==19625== Command: ./a.out
==19625== 
 ASSIGN   1
 CALL
 START
 OPEN
==19625== Use of uninitialised value of size 8
==19625==at 0x4012DF: 
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==by 0x4017D4: MAIN__ (bug.F90:87)
==19625==by 0x401812: main (bug.F90:81)
==19625==  Uninitialised value was created by a stack allocation
==19625==at 0x401206: 
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:67)
==19625== 

Program received signal SIGSEGV: Segmentation fault - invalid memory 
reference.

Backtrace for this error:
#0  0x4e161ef in ???
#1  0x4012df in __input_parameters_bug_MOD_inputparametersconstructornode
at /data001/abenson/Galacticus/galacticus_gfortranFinalization/
bug.F90:73
#2  0x4017d4 in test_parameters_bug
at /data001/abenson/Galacticus/galacticus_gfortranFinalization/
bug.F90:87
#3  0x401812 in main
at /data001/abenson/Galacticus/galacticus_gfortranFinalization/
bug.F90:81
==19625== 
==19625== Process terminating with default action of signal 11 (SIGSEGV)
==19625==at 0x4E1613E: raise (in /home/abenson/Galacticus/Tools/lib/
libc-2.12.1.so)
==19625==by 0x4E161EF: ??? (in /home/abenson/Galacticus/Tools/lib/
libc-2.12.1.so)
==19625==by 0x4012DE: 
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==by 0x4017D4: MAIN__ (bug.F90:87)
==19625==by 0x401812: main (bug.F90:81)
==19625== 
==19625== HEAP SUMMARY:
==19625== in use at exit: 5,448 bytes in 18 blocks
==19625==   total heap usage: 22 allocs, 4 frees, 13,588 bytes allocated
==19625== 
==19625== LEAK SUMMARY:
==19625==definitely lost: 0 bytes in 0 blocks
==19625==indirectly lost: 0 bytes in 0 blocks
==19625==  possibly lost: 0 bytes in 0 blocks
==19625==still reachable: 5,448 bytes in 18 blocks

Re: [Patch, fortran] PR37336 finalization

Hi Tobias,

I agree completely with all that you are saying. Declaring derived types in
a module is guaranteed to produce vtables and final wrappers, so that they
are available in scopes where they are used. Had we thought more about
class design, we might have added the vtable to the entity, rather than
using a pointer to it. Anyway, the pointer does act as a useful
identification for the type. As an example:
module m
  type t
integer :: i
  end type
  type s
type(t), allocatable :: j
  end type
end module
  use m
  call foo
contains
  subroutine foo
type(s), allocatable :: a
a = s(t(42))
print *, a%j
  end subroutine
end
 generates a final wrapper '__final_m_S', although it is not called on
leaving 'foo' scope because there are no final procedures.

Just to confirm what I said earlier: The unpatched and patched mainlines
both complete the polyhedron tests, including rnflow.f90, with -O2.

Date & Time :  8 Mar 2023 14:45:29
Test Name   : gfor_13
Compile Command : gfc13 -ffast-math -funroll-loops -O2 %n.f90 -o %n
Benchmarks  : ac aermod air capacita channel2 doduc gas_dyn2 fatigue2
induct2 linpk mp_prop_design nf protein rnflow test_fpu2 tfft2
Maximum Times   :1.0
Target Error %  :  0.100
Minimum Repeats : 1
Maximum Repeats : 2

   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.00   51720  7.78   2  0.0386
  aermod  0.00 1079416 10.32   2  0.1599
 air  0.00   87096  3.59   2  0.4316
capacita  0.00   65936 22.81   2  0.1951
channel2  0.00   39832104.15   2  0.7287
   doduc  0.00  182104 14.40   2  0.0035
gas_dyn2  0.00   91784181.61   2  0.1261
fatigue2  0.00   86496 95.34   2  0.2061
 induct2  0.00  183824101.46   2  0.3992
   linpk  0.00   43576  6.16   2  0.4545
mp_prop_desi  0.00   48376 94.77   2  0.2168
  nf  0.00   52192  9.94   2  0.2363
 protein  0.00  128248 22.73   2  1.4098
  rnflow  0.00  136296 26.17   2  0.1051
   test_fpu2  0.00  106232 83.34   2  0.0360
   tfft2  0.00   35608 46.70   2  0.5439

Geometric Mean Execution Time =  28.87 seconds

Paul

Re: [Patch, fortran] PR37336 finalization

2023-03-08 Thread Tobias Burnus


On 08.03.23 16:12, Steve Kargl via Fortran wrote:

For one of my codes, I see
% foreach i (*.o)
foreach? nm $i | grep final
foreach? end
0280 T __beamsm_MOD___final_beamsm_Table_t
0580 T __bsam_MOD___final_bsam_Bsa_info_t
01e0 T __bsam_MOD___final_bsam_Bsa_t
00a0 T __ffn_data_MOD___final_ffn_data_Fe_t

I do not explicitly use finalization nor do I have
subprograms named __final_*.  To me, this re-inforces
Richard's point about not breaking existing code.


I think there are two places where finalization is touched: (a) when
declaring a type, finalization procedures might get generated.(*) — And,
(b) invoking finalization procedures.

(a) happens if you have you explicitly add finalization functions – or
(I believe) when you have allocatable components as GCC may then need to
free them.

I think (b) only happens if you either have polymorphism (as then you
don't know whether the polymorphic function uses finalization) – or when
you invoke explicitly finalization.

I believe you run into (a) – the finalization generation. My
understanding is that Paul's patch is mostly about (b) and for sure not
for the default-generated procedures. But of course, any code one
touches for one purpose can still have side effects, affecting seemingly
unrelated code.

Tobias

PS: I think we should change at some point when the virtual tables and
their default procs (init, copy, finalize) generated.

Namely, instead of generating them for all types – even if not used – it
makes sense to generate them only when a type is used in CLASS(t). This
will lead to the generation in multiple translation units, but weak
symbols come to a rescue – and for a MODULE, it can be stored in the
.mod file that the vtable + funcs has been generated. That way, way
fewer vtables are generated, saving a lot of space and reducing compile
time!

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch, fortran] PR37336 finalization

2023-03-08 Thread Andrew Benson via Fortran

I agree with Steve that the lack of finalization support in gfortran means 
there are not many open-source Fortran projects that rely on it.

I've made extensive use of finalization:

https://github.com/galacticusorg/galacticus

An issue with this is that I had to work-around the missing pieces of 
finalization (e.g. finalization of function results). Now that those are 
implemented, my code breaks with Paul's finalization patch applied. This just 
requires me to go through the code and remove those workarounds (which will 
result in much cleaner code - so I'm very happy that finalization is now fully 
implemented).

So, it's possible that any other projects that have used the previous, 
incomplete finalization implementation might similarly break with the new 
patch. So, maybe some explanation of this in the release notes would be 
helpful so that users are made aware of possible problems.

-Andrew

On Wednesday, March 8, 2023 7:12:04 AM PST Steve Kargl via Fortran wrote:
> On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote:
> > Could you please review the patch on that self same time scale? I would be
> > happy to have feedback one file at a time.
> 
> Yes, I'll commit time to review individual patches.  Smaller
> patches are typically easier to review.
> 
> As to other topics in the thread, I suspect you won't
> find a lot of open-source Fortran project that make heavy
> use of finalization.  This is likely due to gfortran's
> current lack of robust support.  There, however, must
> some implicit finalization already occurring.  For one
> of my codes, I see
> 
> % foreach i (*.o)
> foreach? nm $i | grep final
> foreach? end
> 0280 T __beamsm_MOD___final_beamsm_Table_t
> 0580 T __bsam_MOD___final_bsam_Bsa_info_t
> 01e0 T __bsam_MOD___final_bsam_Bsa_t
> 00a0 T __ffn_data_MOD___final_ffn_data_Fe_t
> 
> I do not explicitly use finalization nor do I have
> subprograms named __final_*.  To me, this re-inforces
> Richard's point about not breaking existing code.

-- 

* Andrew Benson: https://abensonca.github.io

* Galacticus: https://github.com/galacticusorg/galacticus

BrainStorm Conference-2023

2023-03-08 Thread Barbara Melvin

Hi Team,

Hope it all goes well! I am writing to verify if you would like to obtain the 
list of participants/visitors?

BrainStorm Conference-2023

Let us know if you are interested and we will come back with the discount cost 
and other deliverables.

Regards,
Barbara Melvin
Senior Business Analyst

Re: F77 indexed file support

2023-03-08 Thread Roland Hughes via Fortran

That would have been a 360/370 IBM Mini. The 3270 was the "smart" terminal.

https://imgs.search.brave.com/9CW5yhzliePl3PmZJJad0-GoiArzOyOIKkKfa0cntW8/rs:fit:640:540:1/g:ce/aHR0cHM6Ly9pLnBp/bmltZy5jb20vb3Jp/Z2luYWxzLzRlL2Nk/L2JlLzRlY2RiZTBl/YjQ0YmFlNGUzOTQ4/YjVlNDk2MWY1OWMx/LmpwZw

Yes, I use database libraries all the time with C/C++. Given Gnu COBOL 
had utilized the Berkley DB so they could provide full (or at least 
nearly complete) language syntax I had hoped Gnu Fortran did the same.

C/C++ never provided any indexed file or "record" level support. FORTRAN 
always did, so I had hopes.

Thanks,

Roland

On 3/8/23 08:30, Arjen Markus wrote:
Well, that is indeed something completely different.My main frame of 
reference (pun not intentional) of that era was our IBM mini, I am not 
quite sure of the type number, 3270? It had a very specific record 
structure for unformatted files. Normally that was almost completely 
hidden, except in the job control, but when we started exchanging data 
files with the personal computers that were then coming out, I could 
write programs that did the necessary conversions. Jolly good fun. My 
department did not use VAXes, other departments did.

So, in your case these files contain data identifiable via some index. 
Hm, today you would do that via some library instead of via some 
builtin language feature, at least when using Fortran, C, C++, ...

Regards,

Arjen

Op wo 8 mrt 2023 om 14:31 schreef Roland Hughes via Fortran 
:

Thank you!

On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote:
> On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran
 wrote:
>
> [ snip namelist IO ]
>
>> Btw, is there a "search" utility for the archives or do I have
to pull down all of the zip files, unzip into directory, and grep
to look for stuff like this? I'm guessing it has come up before.
> Indeed we have
> https://inbox.sourceware.org/fortran/
>
> along the traditional pipermail ml interface.
>
> thanks,

-- 
Roland Hughes, President

Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

Re: [Patch, fortran] PR37336 finalization

2023-03-08 Thread Steve Kargl via Fortran

On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote:
> 
> Could you please review the patch on that self same time scale? I would be
> happy to have feedback one file at a time.
> 

Yes, I'll commit time to review individual patches.  Smaller
patches are typically easier to review.

As to other topics in the thread, I suspect you won't
find a lot of open-source Fortran project that make heavy
use of finalization.  This is likely due to gfortran's
current lack of robust support.  There, however, must
some implicit finalization already occurring.  For one
of my codes, I see

% foreach i (*.o)
foreach? nm $i | grep final 
foreach? end
0280 T __beamsm_MOD___final_beamsm_Table_t
0580 T __bsam_MOD___final_bsam_Bsa_info_t
01e0 T __bsam_MOD___final_bsam_Bsa_t
00a0 T __ffn_data_MOD___final_ffn_data_Fe_t

I do not explicitly use finalization nor do I have 
subprograms named __final_*.  To me, this re-inforces
Richard's point about not breaking existing code.

-- 
Steve

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Paul Richard Thomas wrote:

> Hi All,
> 
> I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
> used in the posted Linux test). The timings are comparable except for
> rnflow.f90.
> 
> As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
> runs successfully at -O2.
> 
> I presume that this is a serious regression since it involves optimization?

I believe it has undefined behavior (accessing array out of bounds).

> Which component should I post it against?
> 
> Regards
> 
> Paul
> 
> gfortran 13.0.1 with patch
>Benchmark   Compile  Executable   Ave Run  Number   Estim
> Name(secs) (bytes)(secs) Repeats   Err %
>-   ---  --   --- ---  --
>   ac  0.00   55904  7.28   2  0.0550
>   aermod  0.00 1149032 10.32   2  0.0242
>  air  0.00  120224  3.57   2  0.3083
> capacita  0.00  110872 20.27   2  0.0765
> channel2  0.00   43928 98.23   2  0.2703
>doduc  0.00  190296 13.86   2  0.2453
> gas_dyn2  0.00  108176 96.77   2  0.1364
> fatigue2  0.00   90752 61.44   2  0.0618
>  induct2  0.00  224992 57.71   2  0.0572
>linpk  0.00   47672  5.54   2  0.1806
> mp_prop_desi  0.00   52640 94.50   2  0.0079
>   nf  0.00   64480  9.25   2  0.4053
>  protein  0.00  136496 20.83   2  0.9096
>   rnflow  0.00  181320   3417.15   2 99.8270
>test_fpu2  0.00  126752 52.35   2  0.1691
>tfft2  0.00   60280 37.61   2  0.9387
> 
> Geometric Mean Execution Time =  32.72 seconds
> rnflow hangs without patch as well. Seems to be a rather serious
> regression.
> gets stuck with -O3 in the loop starting at line 3566 in subroutine cptrf2
> 
> 
> 
> gfortran7.4
>Benchmark   Compile  Executable   Ave Run  Number   Estim
> Name(secs) (bytes)(secs) Repeats   Err %
>-   ---  --   --- ---  --
>   ac  0.00 3612576  7.30   2  0.0205
>   aermod  0.00 5204760 10.21   2  0.0784
>  air  0.00 3829736  4.05   2  0.0988
> capacita  0.00 3672512 22.25   2  0.1506
> channel2  0.00 3663368 87.22   2  0.5767
>doduc  0.00 3840336 13.60   2  0.0221
> gas_dyn2  0.00 3673920 89.54   2  0.1106
> fatigue2  0.00 3691256 74.34   2  0.0921
>  induct2  0.00 4062312 57.87   2  0.1348
>linpk  0.00 3591984  5.59   2  0.0358
> mp_prop_desi  0.00 3966920 93.99   2  0.0654
>   nf  0.00 3622112  9.27   2  0.0324
>  protein  0.00 3832280 22.10   2  0.1289
>   rnflow  0.00 4129984 23.49   2  0.7449
>test_fpu2  0.00 3940944 53.29   2  0.2561
>tfft2  0.00 3622040 36.56   2  0.1026
> 
> Geometric Mean Execution Time =  24.33 seconds
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [Patch, fortran] PR37336 finalization

Hi All,

I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
used in the posted Linux test). The timings are comparable except for
rnflow.f90.

As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.

I presume that this is a serious regression since it involves optimization?
Which component should I post it against?

Regards

Paul

gfortran 13.0.1 with patch
   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.00   55904  7.28   2  0.0550
  aermod  0.00 1149032 10.32   2  0.0242
 air  0.00  120224  3.57   2  0.3083
capacita  0.00  110872 20.27   2  0.0765
channel2  0.00   43928 98.23   2  0.2703
   doduc  0.00  190296 13.86   2  0.2453
gas_dyn2  0.00  108176 96.77   2  0.1364
fatigue2  0.00   90752 61.44   2  0.0618
 induct2  0.00  224992 57.71   2  0.0572
   linpk  0.00   47672  5.54   2  0.1806
mp_prop_desi  0.00   52640 94.50   2  0.0079
  nf  0.00   64480  9.25   2  0.4053
 protein  0.00  136496 20.83   2  0.9096
  rnflow  0.00  181320   3417.15   2 99.8270
   test_fpu2  0.00  126752 52.35   2  0.1691
   tfft2  0.00   60280 37.61   2  0.9387

Geometric Mean Execution Time =  32.72 seconds
rnflow hangs without patch as well. Seems to be a rather serious
regression.
gets stuck with -O3 in the loop starting at line 3566 in subroutine cptrf2



gfortran7.4
   Benchmark   Compile  Executable   Ave Run  Number   Estim
Name(secs) (bytes)(secs) Repeats   Err %
   -   ---  --   --- ---  --
  ac  0.00 3612576  7.30   2  0.0205
  aermod  0.00 5204760 10.21   2  0.0784
 air  0.00 3829736  4.05   2  0.0988
capacita  0.00 3672512 22.25   2  0.1506
channel2  0.00 3663368 87.22   2  0.5767
   doduc  0.00 3840336 13.60   2  0.0221
gas_dyn2  0.00 3673920 89.54   2  0.1106
fatigue2  0.00 3691256 74.34   2  0.0921
 induct2  0.00 4062312 57.87   2  0.1348
   linpk  0.00 3591984  5.59   2  0.0358
mp_prop_desi  0.00 3966920 93.99   2  0.0654
  nf  0.00 3622112  9.27   2  0.0324
 protein  0.00 3832280 22.10   2  0.1289
  rnflow  0.00 4129984 23.49   2  0.7449
   test_fpu2  0.00 3940944 53.29   2  0.2561
   tfft2  0.00 3622040 36.56   2  0.1026

Geometric Mean Execution Time =  24.33 seconds

Re: F77 indexed file support

2023-03-08 Thread Arjen Markus via Fortran

Well, that is indeed something completely different.My main frame of
reference (pun not intentional) of that era was our IBM mini, I am not
quite sure of the type number, 3270? It had a very specific record
structure for unformatted files. Normally that was almost completely
hidden, except in the job control, but when we started exchanging data
files with the personal computers that were then coming out, I could write
programs that did the necessary conversions. Jolly good fun. My department
did not use VAXes, other departments did.

So, in your case these files contain data identifiable via some index. Hm,
today you would do that via some library instead of via some builtin
language feature, at least when using Fortran, C, C++, ...

Regards,

Arjen

Op wo 8 mrt 2023 om 14:31 schreef Roland Hughes via Fortran <
fortran@gcc.gnu.org>:

> Thank you!
>
>
> On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote:
> > On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran <
> fortran@gcc.gnu.org> wrote:
> >
> > [ snip namelist IO ]
> >
> >> Btw, is there a "search" utility for the archives or do I have to pull
> down all of the zip files, unzip into directory, and grep to look for stuff
> like this? I'm guessing it has come up before.
> > Indeed we have
> > https://inbox.sourceware.org/fortran/
> >
> > along the traditional pipermail ml interface.
> >
> > thanks,
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
>
>

Re: F77 indexed file support

2023-03-08 Thread Roland Hughes via Fortran


Thank you!


On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote:

On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran  
wrote:

[ snip namelist IO ]


Btw, is there a "search" utility for the archives or do I have to pull down all 
of the zip files, unzip into directory, and grep to look for stuff like this? I'm 
guessing it has come up before.

Indeed we have
https://inbox.sourceware.org/fortran/

along the traditional pipermail ml interface.

thanks,


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

Re: F77 indexed file support

2023-03-08 Thread Roland Hughes via Fortran


Hello Arjen,

Thanks for your reply.

You are confusing RMS Files-11 file versioning with Indexing.

Sorry, this got away from me. Once I started I couldn't stop.

Real computers, didn't matter who made them or their OS, all provided at 
least one type of indexed file. These were business class platforms. 
Even scientific users needed a business class platform.


Organization types:

*DIRECT *

This was also called a "Hash File" on many platforms. It was a glorified 
sequential file you accessed via RECORD NUMBER. Sometimes data was 
stored and accessed as an on-disk array. Most had some kind of hash 
algorithm.


On the PC platform a somewhat crippled version of this was the file 
format used by DBase and the other Xbase tools of the day used. Each 
"index" was stored in its own file. The platform could only have one 
"index" open at a time so inserts/additions to the data were only 
reflected in that file. You had to PACK the data file and REINDEX each 
time you opened a different "index" because that was the only way to be 
certain they were in synch.


https://www.theminimumyouneedtoknow.com/xbase_book.html

If you really want to know more, you can download that book from the 
xBaseJ project on SourceForge. I wrote it and donated it to the project.


No matter what platform DIRECT access had the problem of deletions. The 
were only "marked" as deleted within the data. You had to PACK a file to 
remove them. Lazy developers used bad hash algos so you also had to deal 
with collisions and missing data.


Today we have amazing hash algos. Even in commercial relational database 
systems certain indexes/keys are implemented via hash because it is the 
fastest for look-up only data.


DIRECT access files are still popular on the lesser platforms because, 
if you have a logically contiguous sequential file and mandate fixed 
size records, the C/C++ fseek() function lets you basically implement one.


*ISAM*

I had to spend two weeks in COBOL I drawing on paper and chalk board 
until I understood how this worked. While the VAX claimed support for it 
(to make it easier to port IBM software to VAX) I never encountered 
anyone using it. Even this small description will be more than anyone 
wishes to know about it.


Indexed Sequential Access Method was really only used on platforms that 
allocated disk storage in Volumes, Cylinders, and Tracks. A certain 
number of tracks (or cylinders) were allocated to the "index area." This 
was assumed to be at the top of the file. There key values would be 
grouped into partially filled "buckets" along with their data track number.


The Primary Data Area would be allocated a certain number of tracks, 
cylinders, or even volumes (a volume is an entire disk spindle).


The Overflow Data Area got allocated tracks, cylinders, and potentially 
volumes as well.


We will skip the conversation of "bucket splits." Buckets were fixed 
size, you tried to keep them 50% or less full. Finding a record was a 
linear search in the index area reading the first entry of each bucket 
until you found one greater than what you were looking for which meant 
your value existed in the previous bucket if at all.


Assuming your key was in said bucket, you then read the track in the 
data area and chewed through it record by record (they could be packed) 
looking for the record with your key or one greater. (lesser if you were 
using a descending index)


After going through one or more tracks and coming up empty handed your 
search was not over, it had to perform a sequential search on the entire 
overflow area.


All of this pain I just shared with you was handled by the OS. Your 
COBOL, FORTRAN, BASIC, DIBOL, etc. program simply did READ RECORD blah 
KEY EQ more-blah.


If you were coding in Assembly, this pain you had to do yourself, 
especially if your OS didn't provide a system services library to do it 
mostly for you.


Deletions are simply flagged deleted. You have to REORG these files to 
empty out the overflow area, reclaim deleted data space, and clean up 
the buckets.


*VSAM*

Virtual Sequential Access Method.

Has only Index Areas (plural) and Data Areas. Each "bucket" is at least 
one disk block in size. At its end it contains a link to the next area 
bucket. These buckets can be scattered anywhere on disk. If you have 
bound volumes or any other OS ability to group multiple disks into one 
logical disk, they can be on any of those spindles. Data areas are the same.


You have the option of processing this file sequentially by doing a 
keyed hit to the first record of some index and sequentially reading. It 
will read in key sequence until end.


Index buckets are required to have the actual data bucket of the record. 
Records could span blocks/buckets and they could be packed.


Deleted records were actually deleted. If block/bucket spanning was 
enabled you paid a bit of overhead price while things shuffled around.


The file system keeps track of the lowest and highest key

Re: Request for participation in GSoC

2023-03-08 Thread Tobias Burnus

Hello,

welcome to the GCC/gfortran community.

On 08.03.23 14:02, Martin Jambor wrote:

On Sat, Mar 04 2023, Priyabrata Mondal via Gcc wrote:

I want to
participate in Google Summer of Code 2023 by contributing to the *Fortran –
DO CONCURRENT* project, an implementation of loop that executes
concurrently. I have started to learn about parallel programming and
Fortran programming language.
I have good knowledge of C, C++, Javascript, HTML, and CSS.
can you suggest some resources so I can learn the technologies
that are required for this project?
I will be highly grateful to you forever if you allow me to do
this project under your guidance.

I assume you have read through
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply
have you managed to complete the steps outlined there?

I wrote the following the other day regarding 'do concurrent':

I think there are two parts to it: First, to add the changes of newer
Fortran to gfortran and then to actually use them to generate
concurrently running code. (Internally, gfortran currently handles 'do
concurrent' to run mostly like a normal loop – except that it annotates
the loops are independent. – Real parallelization would be useful, however.)

If you want to see examples, see do_concurrent_1.f90 to
do_concurrent_6.f90 in gfortran's testsuite, i.e.
gcc/testsuite/gfortran.dg/ in the GCC sources. That's at
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master
/ But it is best to download GCC yourself via Git as described at
https://gcc.gnu.org/git.html

I want to note that the DO CONCURRENT syntax also permits a mask
argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last
argument selects a subset.

For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards

Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL,
LOCAL_INIT, SHARED and DEFAULT(NONE).

Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n)
reduce(+:a, b, c) reduce(max:d, e, f)'

I think the first step is to add parsing support for those new features,
i.e. store them, check for issues (diagnostic) and then fail with a
'sorry not yet implemented'.

The next step would be to implement LOCAL/LOCAL_INIT for running on the
host.

And then, finally, would be to translate into code which can then be run
concurrently. I was thinking of mapping it internally to OpenMP or
OpenACC, to be toggled via a commandline option like
-fdo-concurrent=.

* * *

And for getting started with GCC, I wrote:

I think the first step would be to download GCC and build it. Something
like "git clone" as described above, then "mkdir build" (some
directory); "cd build" and then "../configure --prefix=where-to-install"
followed by "make -j12" and "make install". The "-j12" runs 12 build
jobs in parallel. How much to use depends on your system.

You probably need to install some development versions of libraries such
as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is
to run ./contrib/download_prerequisites to download those and build them
automatically alongside GCC.

I hope it helps to get started

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955

Re: Request for participation in GSoC

2023-03-08 Thread Martin Jambor

Hello,

I am happy that you found contributing to GCC interesting and doubly so
that you are interested in a Fortran topic.  Let me also CC the Fortran
mailing list.

On Sat, Mar 04 2023, Priyabrata Mondal via Gcc wrote:
>   Respected sir,
>I am Priyabrata Mondal, an M.tech student in Electric
> Transportation at the Indian Institute of Technology(IIT), Mandi. I want to
> participate in Google Summer of Code 2023 by contributing to the *Fortran –
> DO CONCURRENT* project, an implementation of loop that executes
> concurrently. I have started to learn about parallel programming and
> Fortran programming language.
>  I have good knowledge of C, C++, Javascript, HTML, and CSS.
> can you suggest some resources so I can learn the technologies
> that are required for this project?
>  I will be highly grateful to you forever if you allow me to do
> this project under your guidance.

I assume you have read through

  https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply

have you managed to complete the steps outlined there?

If you think you need any help with any specific issue you encounter
while working through any of those, feel free to email the mailing list
again.  And David's guide is also a great resource, of course.

Good luck,

Martin

Re: [Patch, fortran] PR37336 finalization

Hi Richard,

Smart pointer applications really torture finalization. That's why Andrew
and Salvatore's help has been so much appreciated.

I haven't run the polyhedron suite for some little while and so I just
downloaded it. I ran into a significant problem with the harness. The
binary segfaulted before doing anything and the source appeared to be
geared towards Intel but I couldn't get it to compile even with ifort. I
replaced all the offending bits of code with standard calls and put the
tests on to cook. The posted linux tests were done with gcc-7.4 so I will
rerun the suite with that and compare the outcomes. So far I haven't seen
any problems. On the contrary, some invalid code nasties were picked up:
 3586 |  DO ij = 1 , 3
  |  2
 3587 | QUGii(ij) = 0.
 3588 | QCOni(ij) = 0.
  |  1
Warning: Array reference at (1) out of bounds (3 > 2) in loop beginning at
(2)
doduc.f90:3587:26:

 3587 | QUGii(ij) = 0.
  |  ^
Warning: iteration 2 invokes undefined behavior
[-Waggressive-loop-optimizations]
doduc.f90:3586:16:
and
gas_dyn2.f90:435:21:

   59 |   SUBROUTINE KEEL(NODES, DX, RADIUS, RBOUND, VEL, DENS, IENER,
 &
  | 2
..
  435 |   SUBROUTINE KEEL(NODES, DX, RADIUS, RBOUND, VEL, DENS, IENER,
 &
  | 1
Warning: Shape mismatch in dimension 1 of argument 'dx' between (1) and (2)
The IEEE underflow and denormal errors are also flagged.

As soon as the runs are finished, I will post the results.

@Tobias Burnus   Thanks for the pointer to Octopus. I'll
give it a whirl tonight.

Cheers

Paul

On Wed, 8 Mar 2023 at 09:10, Richard Biener  wrote:

> On Wed, 8 Mar 2023, Thomas Koenig wrote:
>
> > On 08.03.23 09:14, Richard Biener wrote:
> > > While Fortran is not considered release critical it would be bad to
> > > break say the build of SPEC CPU 2017 or Polyhedron very late in the
> > > cycle.  I'd lean towards postponing this to early stage1 and eventually
> > > backport it for GCC 13.2 if you would like this feature to be
> implemented
> > > for GCC 13.
> >
> > And now comes the problem - no Fortran maintanier has access to SPEC
> > 2017, as far as I know.  The curse of closed-source benchmarks...
>
> :/
>
> But at least you can watch https://lnt.opensuse.org after-the-fact
>
> > How extensive is SPEC using finalization?  My personal guess would be
> > that it is not used extensively, since gfortran's implementation is
> > pretty broken at the moment.
>
> I'd say it probably doesn't use it.  But I was more worrying about
> unwanted side-effects on code _not_ using finalization.
>
> Do you know of any medium to large size Fortran code base that
> uses finalization?
>
> Richard.
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

2023-03-08 Thread Tobias Burnus


On 08.03.23 09:55, Thomas Koenig via Fortran wrote:

And now comes the problem - no Fortran maintanier has access to SPEC
2017, as far as I know.  The curse of closed-source benchmarks...


We (as in Codesourcery) have access to the older SPEC Accel and the
newer SPEC HPC (but not to SPEC CPU – which SUSE has access to). In SPEC
HPC, I did not see any 'final ::'.

For code using finalization: In the popular non-free
electronic-structure code VASP (used to calculate molecules), I see a
single 'final::'.

A similar less popular program is Octopus,
https://gitlab.com/octopus-code/octopus That would be a real-world code
that uses 45 times 'final', 80 times 'type, extends(...)' and a thousand
times 'class(...)'. Thus, that could be a real-world testcase. (I have
not built it for a longer time.* It includes a regression-test suite.)

Tobias

(*) Octopus: I haven't build it for a longer time, but I think it should
build without too much trouble. That was the program the group
co-developed where I did my master thesis.  / If you want to see what it
does: https://en.wikipedia.org/wiki/Octopus_(software) or
https://octopus-code.org/

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Paul Richard Thomas wrote:

> The alternative is that the patch be reviewed and committed as it is. I
> have been neglecting my daytime job to get to this point and must spend
> some time catching up.

That works for me as well - I understand the work to be done is on
the testsuite side, so we should get more time to test the actual
code changes on the real world.

Richard.

Re: [Patch, fortran] PR37336 finalization

The alternative is that the patch be reviewed and committed as it is. I
have been neglecting my daytime job to get to this point and must spend
some time catching up.

Cheers

Paul


On Wed, 8 Mar 2023 at 08:05, Thomas Koenig  wrote:

> Hi Paul,
>
> > Last night, I scoped out the work required to get the patch ready to
> > commit. Sorting out the testcases will be the main load since they have
> > grown "organically". I propose to change over to one test for each
> > paragraph of F2018 7.5.6.2/7.5.6.3  and to
> > verify them against the other brands. I suspect that this will allow a
> > weeding out of the existing tests. It will take me a couple of weeks.
>
> I am a little bit concerned that this might bring us too close to the
> release date. We are down to 22 P1 regressions as of now.
>
> Richard, what do you think?
>
> Best regards
>
> Thomas
>
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Thomas Koenig wrote:

> On 08.03.23 09:14, Richard Biener wrote:
> > While Fortran is not considered release critical it would be bad to
> > break say the build of SPEC CPU 2017 or Polyhedron very late in the
> > cycle.  I'd lean towards postponing this to early stage1 and eventually
> > backport it for GCC 13.2 if you would like this feature to be implemented
> > for GCC 13.
> 
> And now comes the problem - no Fortran maintanier has access to SPEC
> 2017, as far as I know.  The curse of closed-source benchmarks...

:/

But at least you can watch https://lnt.opensuse.org after-the-fact

> How extensive is SPEC using finalization?  My personal guess would be
> that it is not used extensively, since gfortran's implementation is
> pretty broken at the moment.

I'd say it probably doesn't use it.  But I was more worrying about
unwanted side-effects on code _not_ using finalization.

Do you know of any medium to large size Fortran code base that
uses finalization?

Richard.

Re: [Patch, fortran] PR37336 finalization


On 08.03.23 09:14, Richard Biener wrote:

While Fortran is not considered release critical it would be bad to
break say the build of SPEC CPU 2017 or Polyhedron very late in the
cycle.  I'd lean towards postponing this to early stage1 and eventually
backport it for GCC 13.2 if you would like this feature to be implemented
for GCC 13.


And now comes the problem - no Fortran maintanier has access to SPEC
2017, as far as I know.  The curse of closed-source benchmarks...

How extensive is SPEC using finalization?  My personal guess would be
that it is not used extensively, since gfortran's implementation is
pretty broken at the moment.

Polyhedron we can test, of course, but a grep of the sources shows
that finalization is not used there at all.


But it's of course the Fortran maintainers decision.

Even though Fortran isn't release critical we might ask you to revert
if any such severe problems show up.


Sure.

Best regards

Thomas

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Thomas Koenig wrote:

> Hi Paul,
> 
> > Last night, I scoped out the work required to get the patch ready to commit.
> > Sorting out the testcases will be the main load since they have grown
> > "organically". I propose to change over to one test for each paragraph of
> > F2018 7.5.6.2/7.5.6.3  and to verify them against
> > the other brands. I suspect that this will allow a weeding out of the
> > existing tests. It will take me a couple of weeks.
> 
> I am a little bit concerned that this might bring us too close to the
> release date. We are down to 22 P1 regressions as of now.
> 
> Richard, what do you think?

While Fortran is not considered release critical it would be bad to
break say the build of SPEC CPU 2017 or Polyhedron very late in the
cycle.  I'd lean towards postponing this to early stage1 and eventually
backport it for GCC 13.2 if you would like this feature to be implemented
for GCC 13.

But it's of course the Fortran maintainers decision.

Even though Fortran isn't release critical we might ask you to revert
if any such severe problems show up.

Thanks,
Richard.

Re: [Patch, fortran] PR37336 finalization