[RFC] using autogen to audit fortran intrinsics?!

[Daniel Franke]

Bruce,

a recent discussion on fortran-ml [1] sparked the idea to generate testcases 
to throughly check fortran intrinsics. I assume this might be accomplished 
using autogen?!

For Bruce:
In fortran, intrinsics are functions and subroutines that come with the 
language, designed to ease the life of the developers. The point is, these 
functions need to be implemented by either a library or replaced/translated 
by the frontend. Thus, as these are written by humans as well, not all of 
them work as expected under all circumstances. It was agreed upon that we 
should try to fix possible issues (e.g. PR30372).

For Fortran-ML:
Autogen is used in to generate fixes for broken system header files. These 
fixes are run when bootstrapping gcc.


The idea: have one or more files that describe the intrinsic routines, a valid 
set of arguments, possibly run time test cases. Pass these files to autogen 
to create test cases suitable for dejagnu. Run the test harness, fix whatever 
popps up.

Could you please have a look at the prototyped block below and comment whether 
this approach could possibly work?


Example: The BESJ0 intrinsic shall computes the Bessel function of the first 
kind. The argument may be either REAL(4), REAL(8) or REAL(10/16), the return 
type shall be of similar type as the argument.

intrinsic = {
  name = 'besj0';

  # one line per valid argument set 
  # (especially for intrinsics with multiple arguments)
  #
  # Intrinsics may be functions or subroutines (some are available as both).
  # Subroutines do not have a return value, functions do.
  #
  # subroutine_call = { type1, ... }
  # function_call = { result_type = type, argument_type = { type1, ... }; } 

  # real(4) - default real (float)
  function_call = { result_type = 'real_4', argument_type = { 'real_4' }; };
 
  # real(8) - aka double precision
  function_call = { result_type = 'real_8', argument_type = { 'real_8' }; };

  # real(10)/real(16) - large real, system dependent
  function_call = { result_type = 'large_real';
                    argument_type = { 'large_real' }; };

  # possible runtime test(s):
  # function_test = { argument_type  = { type1, ... }; 
  #                   argument_value = { value1, ... };
  #                   result_type    = type;
  #                   result_value   = value;
  #                   tolerance      = value; }
  function_test = { argument_type  = { 'real_4' };
                    argument_value = { '0.0' };
                    result_type    = { 'real_4' };
                    result_value   = { '0.0' };
                    tolerance      = 'epsilon(real_4)';
                  };
};

>From this (or a similar) definition block four or more test files shall be 
generated, two compile time and two runtime checks:
 * compile time checks for all possible argument sets (no arguments, wrong 
type, to many arguments) of which only exact matches to sets described in 
function_call/subroutine_call shall succeed
 * if an intrinsics provides function and subroutine interfaces, both must be 
tested in separate files
 * similar compile time checks for large_real
 * run time checks for real_4/real_8 
 * run time checks for large_real

The partitioning of real_4/real_8 and large_real seems to be necessary as 
dejagnu needs
    { dg-require-effective-target fortran_large_real } 
in the header of any test using large_real -- probably to skip the specific 
tests if the platform does not provide any of these types.


Now, suggestions and comments are highly welcome =)

Thanks
	Daniel


[1] http://gcc.gnu.org/ml/fortran/2007-02/msg00226.html