This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[gfortran,patch] Fix RANDOM_SEED: optional arguments and -fdefault-integer-8
- From: FX Coudert <fxcoudert at gmail dot com>
- To: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches list <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 12 Aug 2007 17:39:16 +0100
- Subject: [gfortran,patch] Fix RANDOM_SEED: optional arguments and -fdefault-integer-8
Hi all,
This patch fixes various aspects of RANDOM_SEED: its handling of
optional arguments and its use with -fdefault-integer-8, as well as a
more generic problem with optional args to intrinsic subroutines.
* Optional dummies used as optional args to subroutine where not
checked for presence. This is probably rarely a problem, except when
the dummy in question is an array (and there aren't so many intrinsic
subroutines with option array arguments). The trans-expr.c part of
this patch fixes this, fixing a wrong-code problem that could be seen
on RANDOM_SEED (second part of PR30964).
* RANDOM_SEED wrongly rejected calls where more than one argument
is passed, even though some of these might be missing arguments. The
real limitation is that no more than one argument be *present*. I
removed the check from check.c (I still check for cases where more
than one non-optional arg is passed), and installed instead a run-
time check in the library. (This fixes the first part of PR30964.)
* While I was looking at RANDOM_SEED, it noticed that it might not
work nicely with -fdefault-integer-8. Indeed, in this case, the
integer(kind=4) library routine was used and passed integer(kind=8)
arguments! So, I've made two versions of the library routine (which
are resolved in iresolve.c). When the default integer kind is 8, the
seed has half the size of the int4 seed, in terms of array size, so
that the byte-size of the seed is indeed constant. I couldn't think
of any other choice that made sense (ignoring bytes from the seed to
keep it a constant array size seemed... gross!)
Bootstrapped and regtested on x86_64-linux, including 4 new testcases
(one of them tests the behaviour with -fdefault-integer-8); I also
checked the code generated with -fdefault-integer-8. OK to commit?
:ADDPATCH fortran:
Attachment:
random_seed.ChangeLog
Description: Binary data
Attachment:
random_seed.diff
Description: Binary data