This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
- From: "burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 May 2010 09:50:41 -0000
- Subject: [Bug fortran/44265] Link error with reference to parameter array in specification expression
- References: <bug-44265-17837@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #1 from burnus at gcc dot gnu dot org 2010-05-25 09:50 -------
CONFIRM
(No regression: GCC 4.1/4.2/4.3 reject the code ["names" invalid in expression]
while 4.4/4.5/4.6 show either the link error or ICE. Other compilers simply
work.)
One has the local parameter:
CHARACTER(*), PARAMETER :: names(3) = ...
And the characteristics of the result variable
INTEGER, INTENT(IN) :: i
CHARACTER(LEN_TRIM(names(i))) :: s
which depend on the argument. (While "len(names(i))" is constant,
"len_trim(names(i))" is not.)
Thus, I see two possibilities: Mark the return length (in .MOD) as unknown
(which g95 and NAG f95 seemingly do) - or to properly handle the PARAMETER.
Looking at gfortran's .mod file, one finds:
4 'names' '' 'names' 6 ((PARAMETER UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN ...
Thus, the symbol is already saved.
* * *
Variant: If one adds a
subroutine test()
print *, get(1)
end subroutine test
in the module itself, one gets an ICE:
foo.f90:18:0: internal compiler error: in gfc_generate_function_code, at
fortran/trans-decl.c:4378
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords| |ice-on-valid-code, rejects-
| |valid
Last reconfirmed|0000-00-00 00:00:00 |2010-05-25 09:50:41
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265