[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #7 from Paul Thomas --- (In reply to Paul Thomas from comment #6) > Author: pault > Date: Sat Nov 24 09:10:00 2018 > New Revision: 266428 > > URL: https://gcc.gnu.org/viewcvs?rev=266428=gcc=rev > Log: > 2018-11-24 Paul Thomas > > PR fortran/88143 > * resolve.c (resolve_variable): Check for associate names with > NULL target. > > 2018-11-24 Paul Thomas > > PR fortran/88143 > * gfortran.dg/associate_46.f90: New test. > > > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/testsuite/ChangeLog I erroneously checked in the patch as PR888143 - the patch is that of comment #5. Paul
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #6 from Paul Thomas --- Author: pault Date: Sat Nov 24 09:10:00 2018 New Revision: 266428 URL: https://gcc.gnu.org/viewcvs?rev=266428=gcc=rev Log: 2018-11-24 Paul Thomas PR fortran/88143 * resolve.c (resolve_variable): Check for associate names with NULL target. 2018-11-24 Paul Thomas PR fortran/88143 * gfortran.dg/associate_46.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 --- Comment #5 from Paul Thomas --- Created attachment 45073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45073=edit Patch for the PR The attached bootstraps and regtests OK. I will apply as obvious in the next 24 hours. Paul
[Bug fortran/88143] [8/9 Regression] ICE in resolve_variable at gcc/fortran/resolve.c:5413 since r253077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Fortunately, this has a completely trivial fix. In the condition, where the seg fault occurs, sym->assoc->target is NULL for this case. The condition should be: if (sym->assoc && e->rank == 0 && e->ref && sym->ts.type == BT_CLASS && sym->assoc->target && sym->assoc->target->ts.type == BT_CLASS && CLASS_DATA (sym->assoc->target)->as) This then works correctly: MODULE m IMPLICIT NONE TYPE t INTEGER, DIMENSION(:), ALLOCATABLE :: i END TYPE CONTAINS SUBROUTINE s(x, idx1, idx2, k) CLASS(*), DIMENSION(:), INTENT(IN), OPTIONAL :: x INTEGER :: idx1, idx2, k SELECT TYPE ( x ) CLASS IS ( t ) ASSOCIATE ( j => x(idx1)%i ) k = j(idx2) END ASSOCIATE END SELECT END END use m class (t), allocatable :: c(:) integer :: k allocate (c(2)) allocate (c(1)%i, source = [3,2,1]) allocate (c(2)%i, source = [6,5,4]) call s(c, 1, 3, k) if (k .ne. 1) stop 1 call s(c, 2, 1, k) if (k .ne. 6) stop 2 end Paul
[Bug fortran/88076] Shared Memory implementation for Coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 --- Comment #1 from Paul Thomas --- > I have opened this bug to track the progress and provide a forum for > discussion :) Nicolas, Once you are done on this, you might consider implementing a -parallel as in ifort. This could conveniently be triggered in frontend-passes.c, I suspect. ie. this would be a good place to check for dependencies within a do loop and signal, if there are none, that the loop can be parallelised. Then, with everything that you have learned about trans-*.c in dealing with coarrays, you should be able to do what is needed for do loops (and scalarization loops). Just a thought. Paul PS I am just going to look at your last email to have a stab at answering your question.
[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 --- Comment #8 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #7) > *** Bug 88068 has been marked as a duplicate of this bug. *** Hi Dominique, I am getting nowhere with this. I have tested everything that I can think of around the lines: #0 0x10015620d in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1943 #1 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064 #2 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool) primary.c:2287 I'll have another stab tomorrow. Have you joined the 'gilets jaunes' today ;-) Regards Paul
[Bug fortran/83522] ICE on allocatable string reference, string(:)(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- I am closing this as fixed, since Tobias has gone off radar again. Thanks for the report. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 83522, which changed state. Bug 83522 Summary: ICE on allocatable string reference, string(:)(:) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 --- Comment #4 from Paul Thomas --- Hi Dominique, I am just back from a business trip to the US. I will attend to this bug asap. Thanks Paul
[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 --- Comment #1 from Paul Thomas --- Hi Dominique, When you have a moment, could you do a bit of diagnosis for me please? I presume that the ICE is caused by the neglect of a pointer that is sometimes null but which FC28 passes over. A debug session to find out what the problem is would be much appreciated. Thanks Paul
[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196 --- Comment #11 from Paul Thomas --- Author: pault Date: Thu Nov 1 19:36:08 2018 New Revision: 265729 URL: https://gcc.gnu.org/viewcvs?rev=265729=gcc=rev Log: 2018-11-01 Paul Thomas 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 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
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #8) > The test in comment 2 looks like a duplicate of pr70149. It is fixed at > revision r265266. This indeed is fixed on trunk. I am trying to build up the intestinal fortitude to go back through some of the recent fixes and apply them to 8-branch. However, I will close this one now. Thanks for the report. Paul
[Bug fortran/77703] [7/8/9 Regression] ICE on assignment to pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- Created attachment 44907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44907=edit Patch for the PR This does the job. I am working on something else right now and will come back to this in a week or so. Paul
[Bug fortran/68226] [7/8/9 Regression] [OOP] ICE on assignment of pointer-valued function to allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Paul Thomas --- (In reply to Jakub Jelinek from comment #7) > GCC 6 branch is being closed Actually, for all the current branch versions, including 6.4.1 20180703, the testcase compiles and runs correctly. Closing as fixed. Paul
[Bug fortran/87734] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #2) > The ICE appeared between revisions r258235 (2018-03-04, OK) and r258362 > (2018-03-08, ICE), likely r258347 (pr64124 and pr70409). For me the test > compiles with 6.4.0 and 7.3.0, but not for 6.4.1 or 7.3.1. > > > Confirmed with current trunk. Could this be a duplicate of PR87644 ? > > Rather a duplicate of pr87673. Hi Bernhard and Dominique, This is indeed a duplicate of pr87673. Swapping around the contained procedures makes the ice go away in both cases. I will put my thinking cap on. There are two places that could be touched to deal with this. Paul
[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196 --- Comment #10 from Paul Thomas --- Comment on attachment 44892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892 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
[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 44892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892=edit 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
[Bug fortran/85603] ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue Oct 23 08:27:14 2018 New Revision: 265412 URL: https://gcc.gnu.org/viewcvs?rev=265412=gcc=rev Log: 2018-10-23 Paul Thomas PR fortran/85603 * frontend-passes.c (get_len_call): New function to generate a call to intrinsic LEN. (create_var): Use this to make length expressions for variable rhs string lengths. Clean up some white space issues. 2018-10-23 Paul Thomas PR fortran/85603 * gfortran.dg/deferred_character_23.f90 : Check reallocation is occurring as it should and a regression caused by version 1 of this patch. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/deferred_character_23.f90
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #10 from Paul Thomas --- Author: pault Date: Sun Oct 21 17:32:06 2018 New Revision: 265353 URL: https://gcc.gnu.org/viewcvs?rev=265353=gcc=rev Log: 2018-10-21 Paul Thomas PR fortran/71880 * trans-expr.c (gfc_trans_pointer_assignment): Set the string length for array valued deferred length lhs. 2018-10-21 Paul Thomas PR fortran/71880 * gfortran.dg/deferred_character_31.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_31.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87673] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #1 from Paul Thomas --- I Have just noticed that the problem goes away for 6-branch through trunk is the order of the contained procedures is changed. This points a finger at parse.c/primary.c or the resolution of contained functions. Paul
[Bug fortran/87673] New: Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Bug ID: 87673 Summary: Errors caused by using function for character length in allocate with typespec Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 44873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44873=edit Reduced source for the problem The attached causes a variety of failures, ranging from a segfault in resolve.c to the following message: [pault@pc30 pr85603]$ ~/irun/bin/gfortran -static-libgfortran -fdump-tree-original ~/prs/pr85603/f*.f90 -g /home/pault/prs/pr85603/fragment.f90:46:24: 46 | ALLOCATE( CHARACTER(get_char_result_length(len(string%chars), length)) :: & |1 Error: Reference to impure function ‘_chars_length’ at (1) within a PURE procedure /home/pault/prs/pr85603/fragment.f90:75:10: 75 | end module | 1 Warning: _chars_length at (1) is not a procedure If the assignment to 'klen' is included, the function identified changes to '__vtab_v_Varying_string'. Using 'klen' in the typespec, instead of the function call works fine. I have to drop the search for the source of the problem right now and so I am posting it. Paul
[Bug fortran/86052] ICE with parameterized derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86052 --- Comment #4 from Paul Thomas --- (In reply to Jürgen Reuter from comment #3) > Paul, it is not my example, it was posted by Alberto Fco. Martín-Huertas in > December 2015 on c.l.f., and you commented at that time that you were > contemplating on how to implement PDTs together with recursive allocatables > :P > I am just playing a little bit around and following the (older) entries on > c.l.f. Aaah! Thanks Juergen. As you can see, my hoped for PDTfest has not yet occurred. In fact, my ownership of non-PDT bugs has actually increased following a bit a quality of implementation drive on deferred length characters, select type and associate. I will find the time soon Paul
[Bug fortran/86148] parameterized type compile time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86148 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I had better take this as the PDT "owner". I have some fairly fundamental work to do on PDT's and so I am not sure when I attend to this. Please be patient. Thanks for the report paul
[Bug fortran/86268] [9.0] Error on correct code with PDTs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86268 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I had better take it. Thanks for the report. Paul
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #9 from Paul Thomas --- If I don't take it, I will lose it! Cheers Paul
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 --- Comment #13 from Paul Thomas --- (In reply to Paul Thomas from comment #11) > Author: pault > Date: Thu Oct 18 10:33:25 2018 > New Revision: 265263 > > URL: https://gcc.gnu.org/viewcvs?rev=265263=gcc=rev > Log: > 2018-10-18 Paul Thomas > > PR fortran/58618 > * trans-decl.c (gfc_get_symbol_decl): Deal correctly with the > initialization with NULL() of a deferred length pointer. > > 2018-10-18 Paul Thomas > > PR fortran/58618 > * gfortran.dg/deferred_character_30.f90 : New test. > > > Added: > trunk/gcc/testsuite/gfortran.dg/deferred_character_30.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/trans-decl.c > trunk/gcc/testsuite/ChangeLog This bug was found during the fix of this PR but is a regression caused by the fix for PR70149. Paul
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 --- Comment #12 from Paul Thomas --- Author: pault Date: Thu Oct 18 10:37:39 2018 New Revision: 265264 URL: https://gcc.gnu.org/viewcvs?rev=265264=gcc=rev Log: 2018-10-18 Paul Thomas PR fortran/58618 * trans-stmt.c (trans_associate_var): All strings that return as pointer types can be assigned directly to the associate name so remove 'attr' and the condition that uses it. 2018-10-18 Paul Thomas PR fortran/58618 * gfortran.dg/associate_45.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_45.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 --- Comment #11 from Paul Thomas --- Author: pault Date: Thu Oct 18 10:33:25 2018 New Revision: 265263 URL: https://gcc.gnu.org/viewcvs?rev=265263=gcc=rev Log: 2018-10-18 Paul Thomas PR fortran/58618 * trans-decl.c (gfc_get_symbol_decl): Deal correctly with the initialization with NULL() of a deferred length pointer. 2018-10-18 Paul Thomas PR fortran/58618 * gfortran.dg/deferred_character_30.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87632] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87632 --- Comment #2 from Paul Thomas --- (In reply to Jürgen Reuter from comment #0) > There is a new ICE, most likely introduced by r265232, r265134 was still > working. I will add a reproducer after lunch. Why most likely :-) ? There is also: r265171 & r265175 50:50 me and Tobias - I look forward to your reduction. Thanks Paul
[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906 --- Comment #4 from Paul Thomas --- Author: pault Date: Wed Oct 17 07:16:16 2018 New Revision: 265232 URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev Log: 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 PR fortran/80260 PR fortran/82077 * resolve.c (resolve_variable): Fix up expressions with array associate names, where the parser did not detect that this is array and there was no array part_ref in the expression. 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 * gfortran.dg/associate_44.f90 : New test. PR fortran/80260 * gfortran.dg/select_type_45.f90 : New test. PR fortran/82077 * gfortran.dg/select_type_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_44.f90 trunk/gcc/testsuite/gfortran.dg/select_type_45.f90 trunk/gcc/testsuite/gfortran.dg/select_type_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077 --- Comment #5 from Paul Thomas --- Author: pault Date: Wed Oct 17 07:16:16 2018 New Revision: 265232 URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev Log: 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 PR fortran/80260 PR fortran/82077 * resolve.c (resolve_variable): Fix up expressions with array associate names, where the parser did not detect that this is array and there was no array part_ref in the expression. 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 * gfortran.dg/associate_44.f90 : New test. PR fortran/80260 * gfortran.dg/select_type_45.f90 : New test. PR fortran/82077 * gfortran.dg/select_type_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_44.f90 trunk/gcc/testsuite/gfortran.dg/select_type_45.f90 trunk/gcc/testsuite/gfortran.dg/select_type_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260 --- Comment #6 from Paul Thomas --- Author: pault Date: Wed Oct 17 07:16:16 2018 New Revision: 265232 URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev Log: 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 PR fortran/80260 PR fortran/82077 * resolve.c (resolve_variable): Fix up expressions with array associate names, where the parser did not detect that this is array and there was no array part_ref in the expression. 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 * gfortran.dg/associate_44.f90 : New test. PR fortran/80260 * gfortran.dg/select_type_45.f90 : New test. PR fortran/82077 * gfortran.dg/select_type_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_44.f90 trunk/gcc/testsuite/gfortran.dg/select_type_45.f90 trunk/gcc/testsuite/gfortran.dg/select_type_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 --- Comment #9 from Paul Thomas --- Author: pault Date: Wed Oct 17 07:16:16 2018 New Revision: 265232 URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev Log: 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 PR fortran/80260 PR fortran/82077 * resolve.c (resolve_variable): Fix up expressions with array associate names, where the parser did not detect that this is array and there was no array part_ref in the expression. 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 * gfortran.dg/associate_44.f90 : New test. PR fortran/80260 * gfortran.dg/select_type_45.f90 : New test. PR fortran/82077 * gfortran.dg/select_type_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_44.f90 trunk/gcc/testsuite/gfortran.dg/select_type_45.f90 trunk/gcc/testsuite/gfortran.dg/select_type_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77385] "Unclassifiable statement" from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77385 --- Comment #4 from Paul Thomas --- Author: pault Date: Wed Oct 17 07:16:16 2018 New Revision: 265232 URL: https://gcc.gnu.org/viewcvs?rev=265232=gcc=rev Log: 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 PR fortran/80260 PR fortran/82077 * resolve.c (resolve_variable): Fix up expressions with array associate names, where the parser did not detect that this is array and there was no array part_ref in the expression. 2018-10-17 Paul Thomas PR fortran/56386 PR fortran/58906 PR fortran/77385 * gfortran.dg/associate_44.f90 : New test. PR fortran/80260 * gfortran.dg/select_type_45.f90 : New test. PR fortran/82077 * gfortran.dg/select_type_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_44.f90 trunk/gcc/testsuite/gfortran.dg/select_type_45.f90 trunk/gcc/testsuite/gfortran.dg/select_type_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77385] "Unclassifiable statement" from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77385 --- Comment #3 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > Confirmed from 4.7 up to trunk (7.0), Polymorphic arrays are not yet > supported on 4.6. > > Note that the following variant > > MODULE a >IMPLICIT NONE >TYPE :: b > CONTAINS > PROCEDURE :: e >END TYPE b >TYPE :: c > CLASS(b), POINTER :: i(:) => NULL() >END TYPE c >CONTAINS > FUNCTION e(this ) RESULT (s) > CLASS(b) :: this > TYPE(b) :: s > s = b() > END FUNCTION e > END MODULE a > MODULE m >USE a >IMPLICIT NONE >TYPE d > CLASS(b), DIMENSION(:), POINTER :: f => NULL() >END TYPE d >CONTAINS > FUNCTION g() RESULT (h) > TYPE(d) :: j > TYPE(c) :: h > allocate(j%f(1)) > print *, shape(j%f) > ASSOCIATE( k => j%f ) > END ASSOCIATE > END FUNCTION g > END MODULE m >use m >type(c) :: res >res = g() > end > > gives > > ASSOCIATE( k => j%f ) > > internal compiler error: Segmentation fault: 11 > > and > > MODULE a >IMPLICIT NONE >TYPE :: b > CONTAINS > PROCEDURE :: e >END TYPE b >TYPE :: c > CLASS(b), POINTER :: i(:) => NULL() >END TYPE c >CONTAINS > FUNCTION e(this ) RESULT (s) > CLASS(b) :: this > TYPE(b) :: s > s = b() > END FUNCTION e > END MODULE a > MODULE m >USE a >IMPLICIT NONE >TYPE d > CLASS(b), DIMENSION(:), POINTER :: f => NULL() >END TYPE d >CONTAINS > FUNCTION g() RESULT (h) > TYPE(d) :: j > TYPE(c) :: h > ALLOCATE(h%i(1)) > allocate(j%f(1)) > SELECT TYPE ( l => h%i ) > TYPE IS ( b ) >l(1) = j*f(1)%e() > END SELECT > END FUNCTION g > END MODULE m > > gives > > l(1) = j*f(1)%e() > 1 > Error: Symbol 'f' at (1) has no IMPLICIT type I am not surprised at the error in the second variant. Replace the offending statement by l(1) = j%f(1)%e() and all is well. Paul
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #8 from Paul Thomas --- Fixed on trunk. I am going back on my original intention to backport the recent patches to 8-branch. Or, rather, I will do them one at a time if at all. The trouble is that an omnibus patch doesn't work for all the new testcases because of some earlier patches applied to trunk. I will keep this open in the hope that a backport will work but do not hold your breath. Best regards Paul
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #7 from Paul Thomas --- Author: pault Date: Mon Oct 15 16:31:15 2018 New Revision: 265171 URL: https://gcc.gnu.org/viewcvs?rev=265171=gcc=rev Log: 2018-10-15 Paul Thomas Tobias Burnus PR fortran/87566 * resolve.c (resolve_assoc_var): Add missing array spec for class associate names. (resolve_select_type): Handle case where last typed component of the selector has a different type to the expression. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Replace call to gfc_expr_to_initialize with call to gfc_copy_expr. (gfc_conv_class_to_class): Guard assignment to 'len' field against case where zero constant is supplied. 2018-10-15 Paul Thomas Tobias Burnus PR fortran/87566 * gfortran.dg/select_type_44.f90: New test. * gfortran.dg/associate_42.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_42.f90 trunk/gcc/testsuite/gfortran.dg/select_type_44.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 --- Comment #10 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #9) > With the patch in comment 8, the wrong-code is replaced with an ICE > > pr58618.f90:2:0: > > 2 | associate (x=>s(1)(1:1)) > | > internal compiler error: in fold_convert_loc, at fold-const.c:2425 > > (configured with --enable-checking=yes). That's weird - I am even more puzzled then :-( Thanks Paul
[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- According to Dominique's message to the list this morning, I have fixed this one and so I had better take it. Paul
[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- According to Dominique's message to the list this morning, I have fixed this one and so I had better take it. Paul
[Bug fortran/77385] "Unclassifiable statement" from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77385 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- According to Dominique's message to the list this morning, I have fixed the variant in comment#1 and so I had better take it. Paul
[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- According to Dominique's message to the list this morning, I have fixed this one and so I had better take it. Paul
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- Created attachment 44839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44839=edit A fix for the PR I haven't entirely convinced myself that I understand why this works. I'll figure it out tomorrow. That said, it regtests OK on trunk. Paul
[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- Created attachment 44838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44838=edit A patch for the original problem The attached does the job on the original problem. I will wait until the fix for PR87566 is committed before submitting this one. With respect to the problem in comment #2: This one is really tough because the type of the function f() has not been determined since it is contained. Either we have to change the parsing sequence such that a CONTAINS statement is searched for and the the contained procedures parsed or we look for a derived type with the component name and set the symbol type accordingly. Even if it is a bit desperate, the latter is certainly doable. Paul
[Bug fortran/83146] [6/7/8/9 Regression] ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Indeed, Dominique this has been fixed. I have added a testcase to trunk to make sure that it remains nailed to the floor. I do not think that this is necessary for 8-branch. Thanks for the report. Paul
[Bug fortran/83146] [6/7/8/9 Regression] ICE on SELECT CASE statement with associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 --- Comment #5 from Paul Thomas --- Author: pault Date: Sun Oct 14 09:25:13 2018 New Revision: 265148 URL: https://gcc.gnu.org/viewcvs?rev=265148=gcc=rev Log: 2018-10-14 Paul Thomas PR fortran/83146 * gfortran.dg/associate_43.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_43.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #6 from Paul Thomas --- Created attachment 44835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44835=edit Fix for the PR Hi Tobias, The problem that you found occurs in trans-expr.c (gfc_conv_class_to_class). Once found, the fix was trivial (See the attachment) and the testcase below compiles and executes correctly. The call to gfc_conv_class_to_class is made at trans-stmt.c:1822. The argument 'copy_back' is set true. However, the copyback is made to the select type temporary, rather than to 'Pt'. Therefore, the assignment works but pointing to a new target does not. Setting 'copy_back' to false regtests OK but I suspect that it should break the associate construct for some cases. That said, to my surprise, this causes an ICE: call AddArray contains subroutine AddArray() type Object_array_pointer class(*), pointer :: p(:) => null() end type Object_array_pointer type (Object_array_pointer) :: obj character(3), target :: tgt1(2) = ['one','two'] character(5), target :: tgt2(2) = ['three','four '] obj%p => tgt1 associate (point => obj%p) end associate end subroutine AddArray end However, your patch in resolve.c caused a good number of regressions and so I put that right too. Over to you! Paul call AddArray contains subroutine AddArray() type Object_array_pointer class(*), pointer :: p(:) => null() end type Object_array_pointer class(*), pointer :: Pt => null() character(3), target :: tgt1(2) = ['one','two'] allocate (Pt, source = Object_array_pointer ()) select type (Pt) type is (object_array_pointer) Pt%p => tgt1 end select select type (Pt) class is (object_array_pointer) select type (Point=> Pt%P) type is (character(*)) if (any (Point .ne. tgt1)) stop 1 Point = ['abc','efg'] end select end select select type (Pt) class is (object_array_pointer) select type (Point=> Pt%P) type is (character(*)) if (any (Point .ne. ['abc','efg'])) stop 2 end select end select end subroutine AddArray end
[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 --- Comment #13 from Paul Thomas --- > Thus the patch is contrary to the standard and must be removed as soon > as possible. > > Paul By the way, the original problem is fixed on trunk by one of my recent deferred length character patches. You will note that some of the failing testcases (eg. deferred_character_2[2,3].f90 test this explicitly. Cheers Paul
[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #12 from Paul Thomas --- (In reply to Jakub Jelinek from comment #11) > I admit I'm not a Fortran language lawyer, but I actually don't see why > (:)(:) is invalid. > It is not a substring non-terminal in that case, sure, because R908/R909 > require parent-string to be array-element or some scalar. > But, R918 then has: > array-section is data-ref [ ( substring-range ) ] >or complex-part-designator > and if C925/C296 conditions are met, it is a valid array section, for which > then 9.5.3.1/1 says what it means (everything from > https://j3-fortran.org/doc/year/18/18-007.pdf > ). So, IMNSHO the patch needs to be reverted. Hi Jakub, I have just seen your comment having written an email to the list to the same effect: The section from the standard in comment #2 is being misinterpreted. R609 and R610 concern substrings in the context of section 6.4, which concerns SCALARS! Section 6.5 concerns arrays and you will find there: R618 array-section is data-ref [ ( substring-range ) ] or complex-part-designator C624 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have a section- subscript-list with nonzero rank, another part-ref shall have nonzero rank, or the complex-part-designator shall be an array. Further lines appear later in which in which substrings of array sections are explicitly mentioned: eg. If a substring-range appears in an array-section, each element is the designated substring of the corresponding element of the array section. The value of a subscript in an array element shall be within the bounds for its dimension. Thus the patch is contrary to the standard and must be removed as soon as possible. Paul
[Bug fortran/86576] [F03][OOP] Sourced allocation of object array fails with SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576 --- Comment #4 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #3) > AFAICT the test in comment 2 has been fixed between revisions r264451 > (2018-09-20) and r264486 (2018-09-21), may be r264485 (pr87359). Unfortunately, the original still segfaults. Tobias's finalization wrapper is rather sensitive for reasons that I am unable to understand. If any attempt is made to deallocate the target, even if it is nulled correctly, the finalization wrapper segfaults. I'll take it although it will be some time before I can turn to it. Cheers Paul
[Bug fortran/55735] ICE with deferred-length strings in COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #9 from Paul Thomas --- (In reply to Jürgen Reuter from comment #7) > Ah sorry, I think I moved around the block data and then it wasn't valid > Fortran anymore. I think, both the block data and the subroutine are > external to the main program. I do not understand how the processor is expected to lay out the common blocks unless the string length appears after the pointer. subroutine bar() character(len=:), pointer :: str(:) common /foo/ str ! print *, len(str), '"'//str//'"' !ICE in gfc_conv_intrinsic_len print '(3a)', '"',str(1:6),'"' ! ICE in gfc_conv_variable end is unable to get the string length from anywhere otherwise. As it happens, even character(len=:), pointer :: str(:) common /foo/ str allocate (character(len=6) :: str(1)) str = "ABCDEF" call bar() end ICEs unless the common statement is excised. My original inclination was to close this as a WONTFIX but I will have a look. Cheers Paul
[Bug fortran/55735] ICE with deferred-length strings in COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #8 from Paul Thomas --- (In reply to Jürgen Reuter from comment #7) > Ah sorry, I think I moved around the block data and then it wasn't valid > Fortran anymore. I think, both the block data and the subroutine are > external to the main program. I do not understand how the processor is expected to lay out the common blocks unless the string length appears after the pointer. subroutine bar() character(len=:), pointer :: str(:) common /foo/ str ! print *, len(str), '"'//str//'"' !ICE in gfc_conv_intrinsic_len print '(3a)', '"',str(1:6),'"' ! ICE in gfc_conv_variable end is unable to get the string length from anywhere otherwise. As it happens, even character(len=:), pointer :: str(:) common /foo/ str allocate (character(len=6) :: str(1)) str = "ABCDEF" call bar() end ICEs unless the common statement is excised. My original inclination was to close this as a WONTFIX but I will have a look. Cheers Paul
[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 --- Comment #9 from Paul Thomas --- Author: pault Date: Tue Oct 9 07:46:48 2018 New Revision: 264949 URL: https://gcc.gnu.org/viewcvs?rev=264949=gcc=rev Log: 2018-10-09 Paul Thomas PR fortran/87151 * trans-array.c (gfc_get_array_span): Deal with deferred char array components having a TYPE_MAX_VALUE of zero. (gfc_array_init_size): Use the hidden string length component to build the descriptor dtype. (gfc_array_allocate): Remove the erroneous replacement of the charlen backend decl with a temporary. (gfc_conv_expr_descriptor): Use the ss_info string length in the case of deferred character components. (gfc_alloc_allocatable_for_assignment): Actually compare the string lengths for deferred characters. Make sure that kind > 1 is handled correctly. Set the span field of the descriptor. * trans-intrinsic.c (gfc_conv_intrinsic_len): Remove the stupid comment. PR fortran/80931 * trans-array.c (gfc_array_allocate): Set the span field for variable length character arrays. 2018-10-09 Paul Thomas PR fortran/87151 * gfortran.dg/deferred_type_component_3.f90: New test. PR fortran/80931 * gfortran.dg/deferred_character_28.f90: New test. * gfortran.dg/deferred_character_29.f90: New test (note that this test appears in PR83196 comment #4 by mistake). Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_28.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_29.f90 trunk/gcc/testsuite/gfortran.dg/deferred_type_component_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87151] allocating array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue Oct 9 07:46:48 2018 New Revision: 264949 URL: https://gcc.gnu.org/viewcvs?rev=264949=gcc=rev Log: 2018-10-09 Paul Thomas PR fortran/87151 * trans-array.c (gfc_get_array_span): Deal with deferred char array components having a TYPE_MAX_VALUE of zero. (gfc_array_init_size): Use the hidden string length component to build the descriptor dtype. (gfc_array_allocate): Remove the erroneous replacement of the charlen backend decl with a temporary. (gfc_conv_expr_descriptor): Use the ss_info string length in the case of deferred character components. (gfc_alloc_allocatable_for_assignment): Actually compare the string lengths for deferred characters. Make sure that kind > 1 is handled correctly. Set the span field of the descriptor. * trans-intrinsic.c (gfc_conv_intrinsic_len): Remove the stupid comment. PR fortran/80931 * trans-array.c (gfc_array_allocate): Set the span field for variable length character arrays. 2018-10-09 Paul Thomas PR fortran/87151 * gfortran.dg/deferred_type_component_3.f90: New test. PR fortran/80931 * gfortran.dg/deferred_character_28.f90: New test. * gfortran.dg/deferred_character_29.f90: New test (note that this test appears in PR83196 comment #4 by mistake). Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_28.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_29.f90 trunk/gcc/testsuite/gfortran.dg/deferred_type_component_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Paul Thomas --- Fixed on both branches. Thanks for the report. Paul
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #11 from Paul Thomas --- Author: pault Date: Mon Oct 8 14:20:40 2018 New Revision: 264931 URL: https://gcc.gnu.org/viewcvs?rev=264931=gcc=rev Log: 2018-10-08 Paul Thomas PR fortran/83999 Backport from trunk * resolve.c (resolve_fl_procedure): Include class functions in the test that elemental function results be scalar. 2018-10-08 Paul Thomas PR fortran/83999 Backport from trunk * gfortran.dg/elemental_function_4.f90 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/elemental_function_4.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on 8-branch and trunk. Thanks for the report. Paul
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 86372, which changed state. Bug 86372 Summary: [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 86372, which changed state. Bug 86372 Summary: [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 --- Comment #9 from Paul Thomas --- Author: pault Date: Mon Oct 8 13:02:36 2018 New Revision: 264925 URL: https://gcc.gnu.org/viewcvs?rev=264925=gcc=rev Log: 2018-10-08 Paul Thomas Backport from trunk PR fortran/86372 * trans-stmt.c (trans_associate_var): Character associate names with variable string length do not have to be deferred length for the string length to be set, if variable. 2018-10-08 Paul Thomas Backport from trunk PR fortran/86372 * gfortran.dg/associate_41.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_41.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-stmt.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 --- Comment #8 from Paul Thomas --- Author: pault Date: Mon Oct 8 11:17:10 2018 New Revision: 264919 URL: https://gcc.gnu.org/viewcvs?rev=264919=gcc=rev Log: 2018-10-08 Paul Thomas PR fortran/86372 * trans-stmt.c (trans_associate_var): Character associate names with variable string length do not have to be deferred length for the string length to be set, if variable. 2018-10-08 Paul Thomas PR fortran/86372 * gfortran.dg/associate_41.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/87151] allocating array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 --- Comment #4 from Paul Thomas --- (In reply to Jürgen Reuter from comment #3) > This now works with the actual trunk (r264898), and gives the anticipated > result > 2 3. So either it was fixed by one of Paul's other fixes, or he just didn't > comment on this one here. But of course it needs to be backported to 8- and > 7-branches. Juergen, It turns out that if you try to do anything with the 'a' outside the subroutine 'create', all hell breaks loose with the gimplifier. I posted a proper fix to this one yesterday and Dominique signalled to the list that it works as intended. Cheers Paul
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 44804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44804=edit Patch for the PR Since this is a regression and the patch is rather simple, I will commit right away. Paul --- Comment #7 from Paul Thomas --- Author: pault Date: Mon Oct 8 09:11:03 2018 New Revision: 264915 URL: https://gcc.gnu.org/viewcvs?rev=264915=gcc=rev Log: 2018-10-08 Paul Thomas PR fortran/86372 * trans-stmt.c (trans_associate_var): Character associate names with variable string length do not have to be deferred length for the string length to be set, if variable. 2018-10-08 Paul Thomas PR fortran/86372 * gfortran.dg/associate_41.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_41.f90 Modified: trunk/gcc/fortran/trans-stmt.c
[Bug fortran/86372] [8/9 Regression] Segfault on ASSOCIATE statement with CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86372 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 44804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44804=edit Patch for the PR Since this is a regression and the patch is rather simple, I will commit right away. Paul
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 --- Comment #11 from Paul Thomas --- (In reply to Jürgen Reuter from comment #10) > I think inside the logical function (in the local scope) the length of s has > to be printed as the value of the argument x, so 1 and 2, with or without > the 'save' attribute. That's the way it works. However, it is an odd one because the length for the testcase exceeds the allocated memory for the second call. I guess that what should be done is to introduce a static variable to save the string length and then to do a memory check, if checking is set, on subsequent calls. Thanks for the feedback. Paul
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #10 from Paul Thomas --- Author: pault Date: Sat Oct 6 15:14:29 2018 New Revision: 264899 URL: https://gcc.gnu.org/viewcvs?rev=264899=gcc=rev Log: 2018-10-06 Paul Thomas PR fortran/83999 * resolve.c (resolve_fl_procedure): Include class functions in the test that elemental function results be scalar. 2018-10-06 Paul Thomas PR fortran/83999 * gfortran.dg/elemental_function_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 44799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44799=edit Patch for the PR For some reason, I do not see the problem on the current 8-branch. In fact, it comes up with the correct error, even though this patch has not been applied! I will apply to both branches as a belt-and-braces fix :-) Cheers Paul
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Thanks for flagging the problem up and confirming the fix so promptly. Fixed. Paul
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 --- Comment #6 from Paul Thomas --- Author: pault Date: Fri Oct 5 07:01:57 2018 New Revision: 264862 URL: https://gcc.gnu.org/viewcvs?rev=264862=gcc=rev Log: 2018-10-05 Paul Thomas PR fortran/87487 * trans-decl.c (gfc_get_symbol_decl): Make sure that deferred character length pointer initializer has the right type to fix problem with deferred_character_24.f90 on big endian. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #17 from Paul Thomas --- Created attachment 44782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44782=edit "fix" for the PR Ignoring the niceties of the standard for the moment, this "fixes" the problem; or, at least, it runs as intended. Cheers Paul
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 44781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44781=edit Possible fix Does this do it for you? I am very surprised to run into an endian problem with this. Cheers Paul
[Bug fortran/56789] Wrong code with contiguous dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #12 from Paul Thomas --- (In reply to Harald Anlauf from comment #11) > (In reply to paul.richard.tho...@gmail.com from comment #10) > > Even if that were allowed, the standard explicitly disallows the > > argument association in the testcase: See 5.3.7 of the F2008 standard. > > The wording has changed in F2018 DIS, 8.5.7, paragraph 1: > > The CONTIGUOUS attribute specifies that an assumed-shape array is contiguous, > that an array pointer can only be pointer associated with a contiguous > target, > or that an assumed-rank dummy data object is contiguous. > > > In my interpretation, the testcase is valid under F2018, but invalid in > F2008. Hmmm! The F2018 standard is almost obfusticating about argument association with contiguous dummies. I will wade through the pertinent sections tonight. Paul
[Bug fortran/56789] Wrong code with contiguous dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #9 from Paul Thomas --- (In reply to Thomas Koenig from comment #8) > Paul, I'm adding you to the CC in the hope that the analysis > in comment#7 might help you towards a solution that is > glaringly obvious to you (but not to me :-) Coo! A Golden Oldie - I can hear Elvis in the background... I'll take a look. Tschuess Paul
[Bug fortran/65677] Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 --- Comment #6 from Paul Thomas --- Author: pault Date: Mon Oct 1 14:27:17 2018 New Revision: 264759 URL: https://gcc.gnu.org/viewcvs?rev=264759=gcc=rev Log: 2018-10-01 Paul Thomas PR fortran/65677 * trans-expr.c (gfc_trans_assignment_1): Set the 'identical' flag in the call to gfc_check_dependency. 2018-10-01 Paul Thomas PR fortran/65677 * gfortran.dg/dependency_52.f90 : Expand the test to check both the call to adjustl and direct assignment of the substring. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_52.f90
[Bug c++/65667] [5 Regression] FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65667 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to Paul Thomas from comment #4) > Author: pault > Date: Sat Sep 29 17:17:09 2018 > New Revision: 264715 > > URL: https://gcc.gnu.org/viewcvs?rev=264715=gcc=rev > Log: > 2018-09-29 Paul Thomas > > PR fortran/65667 > * trans-expr.c (gfc_trans_assignment_1): If there is dependency > fix the rse stringlength. > > 2018-09-29 Paul Thomas > > PR fortran/65667 > * gfortran.dg/dependency_52.f90 : New test. > > > Added: > trunk/gcc/testsuite/gfortran.dg/dependency_52.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/trans-expr.c > trunk/gcc/testsuite/ChangeLog Sorry for the noise - this should have been PR65677. Paul
[Bug fortran/38936] [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Paul Thomas --- Now replaced with the meta-bug set up by Janus. Paul
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 38936, which changed state. Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 38936, which changed state. Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044 Bug 44044 depends on bug 38936, which changed state. Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/41599] [OOP] SELECT TYPE with associate-name => exp: Use (sometimes) a restricted pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41599 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #4) > I still get an ICE when compiling the second test in comment 3 with r228594. From 7.3.1 onwards, this now gives the correct error: Error: Component ‘bar’ with CLASS at (1) must be allocatable or pointer 6.4.1 ICEs still. It seems to me that this should be closed. Paul
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 --- Comment #45 from Paul Thomas --- Author: pault Date: Sun Sep 30 13:52:55 2018 New Revision: 264725 URL: https://gcc.gnu.org/viewcvs?rev=264725=gcc=rev Log: 2018-09-30 Paul Thomas PR fortran/87359 * trans-array.c (gfc_is_reallocatable_lhs): Correct the problem introduced by r264358, which prevented components of associate names from being reallocated on assignment. 2018-09-30 Paul Thomas PR fortran/87359 * gfortran.dg/associate_40.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_40.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70752] Incorrect LEN for ALLOCATABLE CHARACTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70752 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Sep 30 12:22:07 2018 New Revision: 264724 URL: https://gcc.gnu.org/viewcvs?rev=264724=gcc=rev Log: 2018-09-30 Paul Thomas PR fortran/70752 PR fortran/72709 * trans-array.c (gfc_conv_scalarized_array_ref): If this is a deferred type and the info->descriptor is present, use the info->descriptor (gfc_conv_array_ref): Is the se expr is a descriptor type, pass it as 'decl' rather than the symbol backend_decl. (gfc_array_allocate): If the se string_length is a component reference, fix it and use it for the expression string length if the latter is not a variable type. If it is a variable do an assignment. Make use of component ref string lengths to set the descriptor 'span'. (gfc_conv_expr_descriptor): For pointer assignment, do not set the span field if gfc_get_array_span returns zero. * trans.c (get_array_span): If the upper bound a character type is zero, use the descriptor span if available. 2018-09-30 Paul Thomas PR fortran/70752 PR fortran/72709 * gfortran.dg/deferred_character_25.f90 : New test. * gfortran.dg/deferred_character_26.f90 : New test. * gfortran.dg/deferred_character_27.f90 : New test to verify that PR82617 remains fixed. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_25.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_26.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 --- Comment #9 from Paul Thomas --- Author: pault Date: Sun Sep 30 12:22:07 2018 New Revision: 264724 URL: https://gcc.gnu.org/viewcvs?rev=264724=gcc=rev Log: 2018-09-30 Paul Thomas PR fortran/70752 PR fortran/72709 * trans-array.c (gfc_conv_scalarized_array_ref): If this is a deferred type and the info->descriptor is present, use the info->descriptor (gfc_conv_array_ref): Is the se expr is a descriptor type, pass it as 'decl' rather than the symbol backend_decl. (gfc_array_allocate): If the se string_length is a component reference, fix it and use it for the expression string length if the latter is not a variable type. If it is a variable do an assignment. Make use of component ref string lengths to set the descriptor 'span'. (gfc_conv_expr_descriptor): For pointer assignment, do not set the span field if gfc_get_array_span returns zero. * trans.c (get_array_span): If the upper bound a character type is zero, use the descriptor span if available. 2018-09-30 Paul Thomas PR fortran/70752 PR fortran/72709 * gfortran.dg/deferred_character_25.f90 : New test. * gfortran.dg/deferred_character_26.f90 : New test. * gfortran.dg/deferred_character_27.f90 : New test to verify that PR82617 remains fixed. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_25.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_26.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 --- Comment #8 from Paul Thomas --- Author: pault Date: Sun Sep 30 07:02:49 2018 New Revision: 264721 URL: https://gcc.gnu.org/viewcvs?rev=264721=gcc=rev Log: 2018-09-30 Paul Thomas PR fortran/70149 * trans-decl.c (gfc_get_symbol_decl): A deferred character length pointer that is initialized needs the string length to be initialized as well. 2018-09-30 Paul Thomas PR fortran/70149 * gfortran.dg/deferred_character_24.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_24.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65667] [5 Regression] FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65667 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Sep 29 17:17:09 2018 New Revision: 264715 URL: https://gcc.gnu.org/viewcvs?rev=264715=gcc=rev Log: 2018-09-29 Paul Thomas PR fortran/65667 * trans-expr.c (gfc_trans_assignment_1): If there is dependency fix the rse stringlength. 2018-09-29 Paul Thomas PR fortran/65667 * gfortran.dg/dependency_52.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_52.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 --- Comment #9 from Paul Thomas --- (In reply to Francois-Xavier Coudert from comment #0) > The following code shows allocatable character does not work as it should: > >call g(1) > contains > subroutine g(x) > integer :: x > character(len=x), allocatable :: s > allocate(s) > write(*,*) x, len(s) > end subroutine > end > > > It should output "1 1" but outputs "1 0". The tree dump shows that the > argument x is never used in the string allocation. > > > A longer testcase, including SAVE (which seems also mishandled, but it is > probably linked to this issue): > > program test >logical :: L >L = g(1) >write(*,*) L >L = g(2) >write(*,*) L > contains > logical function g(x) > integer :: x > character(len=x), allocatable :: s > save > if(.NOT.allocated(s)) then > allocate(s) > g = .FALSE. > else > g = .TRUE. > end if > write(*,*) len(s) > end function g > end What is the expected result in the second case? That both the allocation and the string length be saved? Or should the string length be updated to 'x' with every call? At the moment, the latter is implemented but the former would be no problem. Paul
[Bug fortran/70752] Incorrect LEN for ALLOCATABLE CHARACTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70752 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I had better take it :-) Paul
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- I had better take it!
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 44747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44747=edit A fix for the PR This regtests OK and even fixes the PR :-) Submitting to the list in a few minutes. Paul
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #42 from Paul Thomas ---
Created attachment 44746
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44746=edit
Patch for the PR
Many thanks Juergen for the reduced test. This is now DEJA-GNUified (see
below).
The patch regtests OK. Note that I cannot commit this until next week.
(Thomas or Dominique, are you in a position to do the honours?)
Best regards
Paul
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! Test the fix for the second part of PR87359 in which the reallocation on
! assignment for components of associate names was disallowed by r264358.
! -fcheck-all exposed the mismatch in array shapes.
!
! Contributed by Juergen Reuter
!
module phs_fks
implicit none
private
public :: phs_identifier_t
public :: phs_fks_t
type :: phs_identifier_t
integer, dimension(:), allocatable :: contributors
contains
procedure :: init => phs_identifier_init
end type phs_identifier_t
type :: phs_fks_t
type(phs_identifier_t), dimension(:), allocatable :: phs_identifiers
end type phs_fks_t
contains
subroutine phs_identifier_init &
(phs_id, contributors)
class(phs_identifier_t), intent(out) :: phs_id
integer, intent(in), dimension(:) :: contributors
allocate (phs_id%contributors (size (contributors)))
phs_id%contributors = contributors
end subroutine phs_identifier_init
end module phs_fks
!
module instances
use phs_fks
implicit none
private
public :: process_instance_t
type :: nlo_event_deps_t
type(phs_identifier_t), dimension(:), allocatable :: phs_identifiers
end type nlo_event_deps_t
type :: process_instance_t
type(phs_fks_t), pointer :: phs => null ()
type(nlo_event_deps_t) :: event_deps
contains
procedure :: init => process_instance_init
procedure :: setup_real_event_kinematics => pi_setup_real_event_kinematics
end type process_instance_t
contains
subroutine process_instance_init (instance)
class(process_instance_t), intent(out), target :: instance
integer :: i
integer :: i_born, i_real
print *, "Process instance init"
allocate (instance%phs)
end subroutine process_instance_init
subroutine pi_setup_real_event_kinematics (process_instance)
class(process_instance_t), intent(inout) :: process_instance
integer :: i_real, i
associate (event_deps => process_instance%event_deps)
i_real = 2
associate (phs => process_instance%phs)
print *, "Type is phs_fks_t"
allocate (phs%phs_identifiers (3))
call phs%phs_identifiers(1)%init ([1])
call phs%phs_identifiers(2)%init ([1,2])
call phs%phs_identifiers(3)%init ([1,2,3])
event_deps%phs_identifiers = phs%phs_identifiers ! Error: mismatch
in array shapes.
end associate
end associate
end subroutine pi_setup_real_event_kinematics
end module instances
!
program main
use instances, only: process_instance_t
implicit none
type(process_instance_t), allocatable, target :: process_instance
allocate (process_instance)
call process_instance%init ()
call process_instance%setup_real_event_kinematics ()
end program main
! { dg-final { scan-tree-dump-times "__builtin_realloc" 2 "original" } }
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 --- Comment #41 from Paul Thomas --- (In reply to Jürgen Reuter from comment #40) > (In reply to Dominique d'Humieres from comment #39) > > The culprit for the second problem is r264358, exposed only once the > > original problem is fixed, i.e. with the patch of r264485 (tested on both > > reproducers). > > > > It would have been better to open a new PR for it, but it's probably too > > late!-( > > Yes, I left this open to Paul. You could still disentangle, you have my > blessings. The problem is caused by my being too brutal in gfc_is_reallocatable_lhs. I have a patch which is just now regtesting. I will post it here once it is done. Paul
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- This fixed by the patch for PR70752, which I will be submitting tomorrow. I am not sure that it is a duplicate even though it is fixed by the referred to patch. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 67883, which changed state. Bug 67883 Summary: ICE on empty array constructor of character function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/67883] ICE on empty array constructor of character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Ha! I should have read to the end of the PR. It was never closed. Doing so now. Thanks for the report. Paul
[Bug fortran/67883] ICE on empty array constructor of character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 --- Comment #9 from Paul Thomas --- (In reply to Gerhard Steinmetz from comment #2) > Another group of examples. > First case is working in a sufficient manner. > Concatenating two empty hulls (zero len and size, respectivly) > gives an empty hull as result again. > > > $ cat zz1.f90 > program p >character(*), parameter :: c1(*) = [character(*) :: 'a'] // [character(*) > :: 'z'] >character(*), parameter :: c2(*) = [character(0) ::] // [character(0) ::] >character(*), parameter :: c3(*) = [character(0) ::] // [character(*) ::] >character(*), parameter :: c4(*) = [character(0) ::] >print *, 'c1: ', len(c1), size(c1), c1 >print *, 'c2: ', len(c2), size(c2), c2 >print *, 'c3: ', len(c3), size(c3), c3 >print *, 'c4: ', len(c4), size(c4), c4 > end > > > $ gfortran-6 -g -O0 -Wall -fcheck=all zz1.f90 > $ a.out > c1:2 1 az > c2:0 0 > c3:0 0 > c4:0 0 > > --- > > > Next case is questionable : no error, unexpected results. > > > $ cat zz2.f90 > program p >character(*), parameter :: c5(*) = [character(*) :: 'a'] // [character(0) > ::] >character(*), parameter :: c6(*) = [character(0) ::] // [character(*) :: > 'z'] >print *, 'c5: ', len(c5), size(c5), c5 >print *, 'c6: ', len(c6), size(c6), c6 > end > > > $ gfortran-6 -g -O0 -Wall -fcheck=all zz2.f90 > $ a.out > c5:0 0 > c6:0 0 > > > > Errors detected with alternative code : > > $ cat zz3.f90 > program p >character(*), parameter :: b1(*) = [character(*) :: 'a'] >character(*), parameter :: b2(*) = [character(0) ::] >character(*), parameter :: b3(*) = b1 // b2 > ! character(*), parameter :: b4(*) = b2 // b1 >print *, 'b1: ', len(b1), size(b1), b2 >print *, 'b2: ', len(b2), size(b2), b2 >print *, 'b3: ', len(b3), size(b3), b3 > ! print *, 'b4: ', len(b4), size(b4), b4 > end > > > $ gfortran-6 -g -O0 -Wall -fcheck=all zz3.f90 > zz3.f90:4:37-43: > > character(*), parameter :: b3(*) = b1 // b2 > 1 2 > Error: Shapes for operands at (1) and (2) are not conformable > zz3.f90:8:24: > > print *, 'b3: ', len(b3), size(b3), b3 > 1 > Error: 'string' argument of 'len' intrinsic at (1) must be CHARACTER > zz3.f90:8:34: > > print *, 'b3: ', len(b3), size(b3), b3 > 1 > Error: 'array' argument of 'size' intrinsic at (1) must be an array All these yield the error: "Type-spec at (1) cannot contain an asterisk for a type parameter" on trunk. Again, I will check previous branches in a week or so. Paul
[Bug fortran/67883] ICE on empty array constructor of character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 --- Comment #8 from Paul Thomas --- (In reply to Gerhard Steinmetz from comment #0) > With an effectively empty (i=m,n and m>n) array constructor : > > > $ cat z1.f90 > program p >integer i >print *, [(f(i), i=2,1)] > contains >function f(n) > integer :: n > character(:), allocatable :: f > character(3) :: c = 'abc' > f = c(n:n) >end > end > > > $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90 > z1.f90:3:25: > > print *, [(f(i), i=2,1)] > 1 > Warning: DO loop at (1) will be executed zero times [-Wzerotrip] > f951: internal compiler error: in gfc_resolve_character_array_constructor, > at fortran/array.c:1955 The ICE has been fixed on trunk, at least. I will check other branches when I am back at base in a week's time. Paul
[Bug fortran/65677] Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 --- Comment #5 from Paul Thomas --- Created attachment 44738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44738=edit A fix for the PR I have no idea at all why I didn't manage to fix this previously. It is almost obvious. Paul
[Bug fortran/65677] Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Hi John, I appreciate that it is probably three and a half years too late but here is a workaround: replace text = string text = ADJUSTL(text(2:))!*** with allocate (text, source = ADJUSTL(string(2:))) I am working on deferred string problems and so hope to have this one fixed in the next few days. Thank you for submitting this problem. I have poked at it several times since submission but didn't find a solution. This time I am rather more determined. Paul
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- The first test now works fine on trunk. The second does if the 'save' is commented out. Paul
[Bug fortran/85603] ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 --- Comment #3 from Paul Thomas --- Author: pault Date: Sat Sep 22 10:21:25 2018 New Revision: 264502 URL: https://gcc.gnu.org/viewcvs?rev=264502=gcc=rev Log: 2018-09-22 Paul Thomas PR fortran/85603 * trans-array.c (gfc_alloc_allocatable_for_assignment): Test the charlen backend_decl before using the VAR_P macro. 2018-09-22 Paul Thomas PR fortran/85603 * gfortran.dg/deferred_character_23.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
