[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #16 from Jos de Kloe 2011-02-14 14:12:15 UTC --- (In reply to comment #15) > FIXED on the 4.4 and 4.5 branches and on the 4.6 trunk. > > Thanks Jos and Eric for the reports! Hi Tobias, thanks a lot for looking into this issue and fixing it!
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3/4.4 Regression]|[4.3/4.4/4.5/4.6 |gfortran does not detect|Regression] gfortran does |that the parameters for |not detect that the |passing a partial string to |parameters for passing a |a subroutine are incorrect |partial string to a ||subroutine are incorrect --- Comment #15 from Tobias Burnus 2011-02-14 14:07:59 UTC --- FIXED on the 4.4 and 4.5 branches and on the 4.6 trunk. Thanks Jos and Eric for the reports!
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #12 from Tobias Burnus 2011-02-13 19:26:27 UTC --- Author: burnus Date: Sun Feb 13 19:26:24 2011 New Revision: 170110 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170110 Log: 2011-02-13 Tobias Burnus PR fortran/47569 * interface.c (compare_parameter): Avoid ICE with character components. 2011-02-13 Tobias Burnus * gfortran.dg/argument_checking_13.f90: Update dg-error. * gfortran.dg/argument_checking_17.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/argument_checking_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/argument_checking_13.f90
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #11 from Tobias Burnus 2011-02-13 10:11:44 UTC --- (In reply to comment #8) > Submitted patch (with some modifications): > http://gcc.gnu.org/ml/fortran/2011-02/msg00087.html Mikael pointed out that I have probably misread the standard with regards to restrictions for pointer character actual arguments. As the text is a bit confusing (first part seems to allow all scalar character actual arguments, second part implies the restrictions also apply to elements of character arrays), I have asked at J3: http://j3-fortran.org/pipermail/j3/2011-February/004191.html
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus changed: What|Removed |Added CC||Eric.Zurcher at csiro dot ||au --- Comment #10 from Tobias Burnus 2011-02-12 19:28:14 UTC --- *** Bug 45244 has been marked as a duplicate of this bug. ***
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #9 from Dominique d'Humieres 2011-02-12 19:07:43 UTC --- The patch in comment #8 fixes this pr but also pr45244.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #8 from Tobias Burnus 2011-02-11 23:27:35 UTC --- Submitted patch (with some modifications): http://gcc.gnu.org/ml/fortran/2011-02/msg00087.html
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #7 from Tobias Burnus 2011-02-10 15:18:09 UTC --- (In reply to comment #0) > The example uses s(i) in stead of s(i:j) to pass the string, and this was a > common usage pattern in the old fortran77 days, so this may bother more users. Side remark: While this usage is common in Fortran 77 (or rather Fortran IV and Fortran 66), it is not commonly found together with derived types. * * * (In reply to comment #6) > Full patch, currently regtesting; needs a cross check and can then be > submitted. Fails for argument_checking_11.f90, argument_checking_12.f90, argument_checking_13.f90, and argument_checking_14.f90 ... to be fixed later.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
Tobias Burnus changed:
What|Removed |Added
Attachment #23230|0 |1
is obsolete||
Status|NEW |ASSIGNED
AssignedTo|pault at gcc dot gnu.org|burnus at gcc dot gnu.org
--- Comment #6 from Tobias Burnus 2011-02-10
15:10:35 UTC ---
Created attachment 23295
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23295
Updated patch with test case
Full patch, currently regtesting; needs a cross check and can then be
submitted.
Polymorphic test case (disabled) fails due to an earlier ICE, cf. PR 47680.
F2008 quote ("12.5.2.4 Ordinary dummy variables"):
"If the actual argument is a noncoindexed scalar, the corresponding dummy
argument shall be scalar unless the actual argument is default character, of
type character with the C character kind (15.2.2), or is an element or
substring of an element of an array that is not an assumed-shape, pointer, or
polymorphic array."
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #5 from Tobias Burnus 2011-02-03
07:46:17 UTC ---
(In reply to comment #4)
> I am guessing but I suppose ultimate pointer components should be included
> too?
Yes, however, "gfc_expr_attr (actual).pointer" does not work as "foo(1)" is
never a pointer (even if "foo" is one). Thus, one needs to do something like:
pointer = sym->n.sym->attr.pointer
and update it every time one accesses a component ref. (I have not thought
about pointer-returning functions, but one should not confuse them with
proc-pointer functions.)
> This raises a point, however. Relative to the message, the error seems to do a
> lot more :-) I feel a lunchtime peruse of the F2003 standard coming on.
I have in my incomplete draft patch also the following bits, which should be
included in the final patch:
- is valid (cf. F95 12.4.1.1; F2003 12.4.1.2),
+ is valid (cf. F95 12.4.1.1, F2003 12.4.1.2, F2008 12.5.2.4),
and
- gfc_error ("Element of assumed-shaped array passed to dummy "
- "argument '%s' at %L", formal->name, &actual->where);
+ gfc_error ("Element of assumed-shaped or pointer array passed to "
+ "dummy argument '%s' at %L", formal->name, &actual->where);
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.03 05:27:37 AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Paul Thomas 2011-02-03 05:27:37 UTC --- Created attachment 23230 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23230 Patchfor the problem The attached corrects the ICE, retains the existing functionality and extends it to include array components. I am guessing but I suppose ultimate pointer components should be included too? This raises a point, however. Relative to the message, the error seems to do a lot more :-) I feel a lunchtime peruse of the F2003 standard coming on. Cheers Paul
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.5.3
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 --- Comment #3 from Tobias Burnus 2011-02-01 14:54:10 UTC --- (In reply to comment #2) > Draft patch: > + || gfc_expr_attr (actual).pointer That check won't work as "foo(1)" is never a pointer while "foo" might be a pointer; thus, one has to save the last REF_COMPONENT and handle it manually. The following check at a few lines later also needs to be modified (both the AS_ASSUMED and the pointer check). if (actual->expr_type == EXPR_VARIABLE && ref && (ref->u.ar.as->type == AS_ASSUMED_SHAPE || gfc_expr_attr (actual).pointer)) And the check: for (ref = actual->ref; ref; ref = ref->next) if (ref->type == REF_ARRAY && ref->u.ar.type == AR_ELEMENT && ref->u.ar.dimen > 0) break; seems to mishandle "foo(1)%bar(1)%foo" by looking only at the first AR_ELEMENT.
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #2 from Tobias Burnus 2011-02-01
11:33:33 UTC ---
A bit unrelated to the reported problem, but I wonder whether the
coarray/coindexed part is already correctly checked for:
"If the actual argument is a coindexed scalar, the corresponding dummy argument
shall be scalar. If the actual argument is a noncoindexed scalar, the
corresponding dummy argument shall be scalar unless the actual argument
is default character, of type character with the C character kind (15.2.2), or
is an element or substring of an element of an array that is not an
assumed-shape, pointer, or polymorphic array." (F2008)
* * *
Draft patch:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 1e5df61..28daf8a 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1672,7 +1672,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return 1;
/* At this point, we are considering a scalar passed to an array. This
- is valid (cf. F95 12.4.1.1; F2003 12.4.1.2),
+ is valid (cf. F95 12.4.1.1 and F2008 12.5.2.4; F2003 12.4.1.2),
- if the actual argument is (a substring of) an element of a
non-assumed-shape/non-pointer array;
- (F2003) if the actual argument is of type character. */
@@ -1686,8 +1686,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
if (formal->ts.type == BT_CHARACTER
&& (ref == NULL
|| (actual->expr_type == EXPR_VARIABLE
- && (actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE
- || actual->symtree->n.sym->attr.pointer
+ && (ref->u.ar.as->type == AS_ASSUMED_SHAPE
+ || gfc_expr_attr (actual).pointer
{
if (where && (gfc_option.allow_std & GFC_STD_F2003) == 0)
{
[Bug fortran/47569] [4.3/4.4/4.5/4.6 Regression] gfortran does not detect that the parameters for passing a partial string to a subroutine are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org Summary|gfortran does not detect|[4.3/4.4/4.5/4.6 |that the parameters for |Regression] gfortran does |passing a partial string to |not detect that the |a subroutine are incorrect. |parameters for passing a ||partial string to a ||subroutine are incorrect Known to fail||4.4.4, 4.6.0 --- Comment #1 from Tobias Burnus 2011-02-01 11:03:57 UTC --- ICE with gfortran 4.3 to 4.6; compiled with gfortran 4.1. Other compilers (NAG, g95, ifort) do not show any compile-time warning/error. ==21718== Invalid read of size 4 ==21718==at 0x4F29A5: compare_actual_formal (interface.c:1689) ==21718==by 0x4F2D5D: gfc_procedure_use (interface.c:2727) ==21718==by 0x53A825: resolve_call (resolve.c:3508) /* Not an array element. */ if (formal->ts.type == BT_CHARACTER && (ref == NULL || (actual->expr_type == EXPR_VARIABLE && (actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE || actual->symtree->n.sym->attr.pointer The check does not make sense: For "ref->NULL" one cannot assume that it is an array ref - it could also be character ref or a component ref.
