| Message ID | 4F509446.3010007@net-b.de |
|---|---|
| State | New |
| Headers | show |
OK for trunk with RM agreement. Obviously, 4.5 & 4.6 are OK too. Thanks Paul On Fri, Mar 2, 2012 at 10:35 AM, Tobias Burnus <burnus@net-b.de> wrote: > There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures, > which can exists as both subroutine and as function. Example: > > INTRINSIC :: etime > CALL etime(tarray, result) > > Here, the "etime" gets marked as attr.subroutine, but later in > resolve_intrinsics, it is mapped to the intrinsic function "etime". But then > the compiler complains: > > Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at > (1) > > > Solution: Don't search for the function, if we have a subroutine. (For some > reasons, it works without "INTRINSIC :: etime".) > > Build and regtested on x86-64-linux. > OK for the trunk - and the 4.5 to 4.6 branches? > > Tobias > > PS: I will ask for RM approval if this patch gets approved after (today's?) > RC1 release.
On Fri, Mar 2, 2012 at 11:12 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote: > OK for trunk with RM agreement. Obviously, 4.5 & 4.6 are OK too. Ok for trunk. Richard. > Thanks > > Paul > > On Fri, Mar 2, 2012 at 10:35 AM, Tobias Burnus <burnus@net-b.de> wrote: >> There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures, >> which can exists as both subroutine and as function. Example: >> >> INTRINSIC :: etime >> CALL etime(tarray, result) >> >> Here, the "etime" gets marked as attr.subroutine, but later in >> resolve_intrinsics, it is mapped to the intrinsic function "etime". But then >> the compiler complains: >> >> Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at >> (1) >> >> >> Solution: Don't search for the function, if we have a subroutine. (For some >> reasons, it works without "INTRINSIC :: etime".) >> >> Build and regtested on x86-64-linux. >> OK for the trunk - and the 4.5 to 4.6 branches? >> >> Tobias >> >> PS: I will ask for RM approval if this patch gets approved after (today's?) >> RC1 release. > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. > --Hitchhikers Guide to the Galaxy
2012-03-02 Tobias Burnus <burnus@net-b.de> PR fortran/52452 * resolve.c (resolve_intrinsic): Don't search for a function if we know that it is a subroutine. 2012-03-02 Tobias Burnus <burnus@net-b.de> PR fortran/52452 * gfortran.dg/intrinsic_8.f90: New. diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 4dcf9b1..049a926 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -1496,7 +1498,7 @@ resolve_intrinsic (gfc_symbol *sym, locus *loc) if (sym->intmod_sym_id) isym = gfc_intrinsic_function_by_id ((gfc_isym_id) sym->intmod_sym_id); - else + else if (!sym->attr.subroutine) isym = gfc_find_function (sym->name); if (isym) --- /dev/null 2012-03-02 07:37:33.883806634 +0100 +++ gcc/gcc/testsuite/gfortran.dg/intrinsic_8.f90 2012-03-02 08:59:51.000000000 +0100 @@ -0,0 +1,23 @@ +! { dg-do compile } +! +! PR fortran/52452 +! +! Contributed by Roger Ferrer Ibanez +! +PROGRAM test_etime + IMPLICIT NONE + INTRINSIC :: etime + REAL(4) :: tarray(1:2) + REAL(4) :: result + + CALL etime(tarray, result) +END PROGRAM test_etime + +subroutine test_etime2 + IMPLICIT NONE + INTRINSIC :: etime + REAL(4) :: tarray(1:2) + REAL(4) :: result + + result = etime(tarray) +END subroutine test_etime2
There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures, which can exists as both subroutine and as function. Example: INTRINSIC :: etime CALL etime(tarray, result) Here, the "etime" gets marked as attr.subroutine, but later in resolve_intrinsics, it is mapped to the intrinsic function "etime". But then the compiler complains: Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at (1) Solution: Don't search for the function, if we have a subroutine. (For some reasons, it works without "INTRINSIC :: etime".) Build and regtested on x86-64-linux. OK for the trunk - and the 4.5 to 4.6 branches? Tobias PS: I will ask for RM approval if this patch gets approved after (today's?) RC1 release.