Type parameter inquiry: str%len is equivalent to len(str) a%kind is equivalent to kind(a) The real fun part starts with user-defined kinds, e.g. type tp(dim) integer, KIND :: dim real :: dist(dim) end type tp type(tp) :: t(5) print *, t%dist%dim Quote from F2008 but F2003 should be the same: "A type parameter inquiry is used to inquire about a type parameter of a data object. It applies to both intrinsic and derived types. R616 type-param-inquiry is designator % type-param-name C622 (R616) The type-param-name shall be the name of a type parameter of the declared type of the object designated by the designator. A deferred type parameter of a pointer that is not associated or of an unallocated allocatable variable shall not be inquired about."
Another related item are complex parts; contrary to the type parameter inquiry above, those are lvalues and can be assigned to. (Again a F2003 feature, quote is however from F2008.) "R615 complex-part-designator is designator % RE or designator % IM C621 (R615) The designator shall be of complex type. If complex-part-designator is designator%RE it designates the real part of designator. If it is designator%IM it designates the imaginary part of designator. The type of a complex-part-designator is real, and its kind and shape are those of the designator. NOTE 6.6 The following are examples of complex part designators: impedance%re !-- Same value as REAL(impedance) fft%im !-- Same value as AIMAG(fft) x%im = 0.0 !-- Sets the imaginary part of X to zero"
Type parameter inquiries are also mentioned in PR29962, comment #10.
Real/imaginary parts seem to be Fortran 2008 only. Len/kind are still Fortran 2003.
*** Bug 81707 has been marked as a duplicate of this bug. ***
I think originally this was an enhancement becasue we were focused on F95 back in 2009, now we are going for 2015 stuff so this one is higher interest. Taking.
This works: type tp(dim) integer, KIND :: dim = 3 real :: dist(dim) end type tp type(tp) :: t(5) print *, t%dist(2) print *, t end
*** Bug 82709 has been marked as a duplicate of this bug. ***
I dont think I will have time for this one.
Created attachment 44892 [details] Patch for the PR With the attached patch, the test below works fine. The patch needs a bit more work to prevent LEN and KIND part_exprs being assigned to, to assert the relevant standards and to prevent inquiries about unallocated or unassociated deferred length expressions. Paul module m complex, target :: z character (:), allocatable :: str real, pointer :: r => z%re real, pointer :: i => z%im type :: mytype complex :: z = ( 10.0, 11.0 ) character(6) :: str end type end module use m type(mytype) :: der integer :: j z = (2.0,4.0) str = "abcd" if (r .ne. real (z)) stop 1 if (i .ne. imag (z)) stop 2 z%im = 4.0 * z%re if (z%re .ne. real (z)) stop 3 if (abs (z*im - 4.0 * real (z)) .lt. 1e-6) stop 4 if (z%im%kind .ne. kind (z)) stop 5 if (str%kind .ne. kind (str)) stop 6 if (str%len .ne. len (str)) stop 6 if (der%str%len .ne. len (der%str)) stop 7 if (der%z%im .ne. imag (der%z)) stop 8 end
Comment on attachment 44892 [details] Patch for the PR As for things to be done: I forgot the placeholder in simplify_const_ref and the need for some modifications to simplify.c. A more elaborate testcase would be in order as well! Paul
Author: pault Date: Thu Nov 1 19:36:08 2018 New Revision: 265729 URL: https://gcc.gnu.org/viewcvs?rev=265729&root=gcc&view=rev Log: 2018-11-01 Paul Thomas <pault@gcc.gnu.org> PR fortran/40196 * dependency.c (are_identical_variables): Return false if the inquiry refs are not the same. (gfc_ref_needs_temporary_p): Break on an inquiry ref. * dump_parse_tree.c (show_ref): Show the inquiry ref type. * expr.c (gfc_free_ref_list): Break on an inquiry ref. (gfc_copy_ref): Copy the inquiry ref types. (find_inquiry_ref): New function. (simplify_const_ref, simplify_ref_chain): Call it. Add new arg to simplify_ref_chain. (gfc_simplify_expr): Use the new arg in call to simplify_ref_chain. (gfc_get_full_arrayspec_from_expr, gfc_is_coarray): Break on inquiry ref. (gfc_traverse_expr): Return true for inquiry ref. * frontend-passes.c (gfc_expr_walker): Break on inquiry ref. * gfortran.h : Add enums and union member in gfc_ref to implement inquiry refs. * intrinsic.c : Fix white nois. * match.c (gfc_match_assignment): A constant lavlue is an error. * module.c : Add DECL_MIO_NAME for inquiry_type and the mstring for inquiry_types. (mio_ref): Handle inquiry refs. * primary.c (is_inquiry_ref): New function. (gfc_match_varspec): Handle inquiry refs calling new function. (gfc_variable_attr): Detect inquiry ref for disambiguation with components. (caf_variable_attr): Treat inquiry and substring refs in the same way. * resolve.c (find_array_spec): ditto. (gfc_resolve_substring_charlen): If there is neither a charlen ref not an inquiry ref, return. (resolve_ref): Handle inqiry refs as appropriate. (resolve_allocate_expr): Entities with an inquiry ref cannot be allocated. * simplify.c (simplify_bound, simplify_cobound): Punt on inquiry refs. * trans-array.c (get_array_ctor_var_strlen): Break on inquiry ref. *trans-expr.c (conv_inquiry): New function. (gfc_conv_variable): Retain the last typespec to pass to conv_inquiry on detecting an inquiry ref. 2018-11-01 Paul Thomas <pault@gcc.gnu.org> PR fortran/40196 * gfortran.dg/inquiry_part_ref_1.f08: New test. * gfortran.dg/inquiry_part_ref_2.f90: New test. * gfortran.dg/inquiry_part_ref_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inquiry_type_ref_1.f08 trunk/gcc/testsuite/gfortran.dg/inquiry_type_ref_2.f90 trunk/gcc/testsuite/gfortran.dg/inquiry_type_ref_3.f90 trunk/libgfortran/generated/findloc0_c16.c trunk/libgfortran/generated/findloc0_c4.c trunk/libgfortran/generated/findloc0_c8.c trunk/libgfortran/generated/findloc0_i1.c trunk/libgfortran/generated/findloc0_i16.c trunk/libgfortran/generated/findloc0_i2.c trunk/libgfortran/generated/findloc0_i4.c trunk/libgfortran/generated/findloc0_i8.c trunk/libgfortran/generated/findloc0_r16.c trunk/libgfortran/generated/findloc0_r4.c trunk/libgfortran/generated/findloc0_r8.c trunk/libgfortran/generated/findloc0_s1.c trunk/libgfortran/generated/findloc0_s4.c trunk/libgfortran/generated/findloc1_c16.c trunk/libgfortran/generated/findloc1_c4.c trunk/libgfortran/generated/findloc1_c8.c trunk/libgfortran/generated/findloc1_i1.c trunk/libgfortran/generated/findloc1_i16.c trunk/libgfortran/generated/findloc1_i2.c trunk/libgfortran/generated/findloc1_i4.c trunk/libgfortran/generated/findloc1_i8.c trunk/libgfortran/generated/findloc1_r16.c trunk/libgfortran/generated/findloc1_r4.c trunk/libgfortran/generated/findloc1_r8.c trunk/libgfortran/generated/findloc1_s1.c trunk/libgfortran/generated/findloc1_s4.c trunk/libgfortran/m4/findloc0.m4 trunk/libgfortran/m4/findloc0s.m4 trunk/libgfortran/m4/findloc1.m4 trunk/libgfortran/m4/findloc1s.m4 trunk/libgfortran/m4/findloc2s.m4 trunk/libgfortran/m4/ifindloc0.m4 trunk/libgfortran/m4/ifindloc1.m4 trunk/libgfortran/m4/ifindloc2.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
Can the bug be marked as resolved?
OK On Mon, 19 Nov 2018, marxin at gcc dot gnu.org wrote: > Date: Mon, 19 Nov 2018 11:51:27 +0000 > From: marxin at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> > To: John Harper <john.harper@vuw.ac.nz> > Subject: [Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, > a%kind) and Complex parts (z%re, z%im) > Resent-Date: Tue, 20 Nov 2018 00:51:55 +1300 (NZDT) > Resent-From: <john.harper@vuw.ac.nz> > > https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D40196&data=02%7C01%7Cjohn.harper%40vuw.ac.nz%7Cb5d00c897cbb4ce5b3f608d64e1559dc%7Ccfe63e236951427e8683bb84dcf1d20c%7C0%7C0%7C636782250968185848&sdata=MZE8e3vkP6E2081IHpNXIV7yZ1%2FmC3He%2FUYLOF57nAQ%3D&reserved=0 > > Martin Liška <marxin at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |marxin at gcc dot gnu.org > > --- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> --- > Can the bug be marked as resolved? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
Fixed then.
Paul, these three tests fail for me on x86 (32bit) since you introduced them (x86_64 is OK). Unfortunately, the error message is not really helpful: f951: internal compiler error: Segmentation fault 0x838c18c ??? ../sysdeps/i386/elf/start.S:119 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The compiler barfs at all of the following lines, in the very same way: inquiry_type_ref_1.f08: REAL, parameter :: rc = zc%re REAL, parameter :: ic = zc%im if (str%kind .ne. kind (str)) stop 6 inquiry_type_ref_2.f90: a%len = 2 ! { dg-error "Fortran 2003: LEN part_ref" } i = a%kind ! { dg-error "Fortran 2003: KIND part_ref" } inquiry_type_ref_3.f90: a%kind = 2 ! { dg-error "Assignment to a constant expression" } As already told, x86_64 is OK. No idea if this is specific to my compile setting. The rest of the test-suite passes more or less OK for me, so ...