This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
[RFC] using autogen to audit fortran intrinsics?!
- From: Daniel Franke <franke dot daniel at gmail dot com>
- To: Bruce Korb <bkorb at gnu dot org>
- Cc: fortran at gcc dot gnu dot org
- Date: Mon, 12 Feb 2007 23:18:43 +0100
- Subject: [RFC] using autogen to audit fortran intrinsics?!
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=ZRNKdfogKdoadc9BKG36BqvVtGRVg71scPGdln9PkY20xdoO4Bon2Sf+quKcWBXsnINfWClYUTJb0rI1oi/tRD6/mezFqoIFyf3kaZ0phqQsT72NhppIOpJwGANTnhKPiBsLcIB2mmfLvGsefuMDLwNrYqQ9hxejcjKgtw3jYZ8=
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