[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 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #20) > return true;; > > should be > > return true; Corrected - thanks. Many thanks to Jakub for doing the analysis. I haven't had the time these last weeks and so must apologise for the delay in picking this up. 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 #20 from Dominique d'Humieres --- return true;; should be return true;
[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 #19 from Paul Thomas --- Author: pault Date: Fri Dec 21 19:09:42 2018 New Revision: 267337 URL: https://gcc.gnu.org/viewcvs?rev=267337=gcc=rev Log: 2018-12-21 Paul Thomas PR fortran/87881 * expr.c (find_inquiry_ref): Loop through the inquiry refs in case there are two of them. (simplify_ref_chain): Return true after a successful call to find_inquiry_ref. 2018-12-21 Paul Thomas PR fortran/87881 * gfortran.dg/inquiry_part_ref_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inquiry_type_ref_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[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 #18 from paul.richard.thomas at gmail dot com --- Exactly On Wed, 19 Dec 2018 at 09:17, jakub at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 > > --- Comment #17 from Jakub Jelinek --- > The multiple REF_INQUIRY allowed is just whatever%re%kind or whatever%im%kind, > right (because %re/%im must apply to complex and makes a scalar out of it and > %len needs a character type designator)? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[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 #17 from Jakub Jelinek --- The multiple REF_INQUIRY allowed is just whatever%re%kind or whatever%im%kind, right (because %re/%im must apply to complex and makes a scalar out of it and %len needs a character type designator)?
[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 #16 from paul.richard.thomas at gmail dot com --- Hi Jakub, I don't have access to the source until this evening. You, I think, must be right. I need to use gfc_replace_expr. I'm trying to do many things at once - this PR has been on my conscience (together with others) and so I was a bit too eager to get shot of it. Cheers Paul On Tue, 18 Dec 2018 at 17:57, jakub at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 > > --- Comment #14 from Jakub Jelinek --- > Comment on attachment 45258 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258 > A slightly more elaborate version of Jakub's patch > > So, what will happen if there is more than one INQUIRY reference? The first > iteration will set *newp to some expression and the next iteration will > overwrite (memory leak) it with something different, so the last one wins? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[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 #15 from Dominique d'Humieres --- > Does this do it for you? Jakub's patch regtested cleanly. I'll test yours later this evening.
[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 #14 from Jakub Jelinek --- Comment on attachment 45258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258 A slightly more elaborate version of Jakub's patch So, what will happen if there is more than one INQUIRY reference? The first iteration will set *newp to some expression and the next iteration will overwrite (memory leak) it with something different, so the last one wins?
[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 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #13 from Paul Thomas --- Created attachment 45258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258=edit A slightly more elaborate version of Jakub's patch Dominique, Does this do it for you? Cheers 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 #12 from Paul Thomas --- (In reply to Jakub Jelinek from comment #11) > Created attachment 45257 [details] > gcc9-pr87881.patch > > Untested fix. simplify_const_ref is similar, but actually iterates p->ref > and thus properly stops immediately after handling the REF_INQUIRY, > returning true, > because it has no further refs. simplify_ref_chain is weird in that it is > passed two arguments, one ref and one p, where in all callers do pass p->ref > and to those arguments, so if for REF_INQUIRY we replace *p with > something different, all the references are freed and we need to stop > iterating. Hi Jakub, That's absolutely right - thanks! I have modified find_inquiry_ref to allow for the possibility of there being two inquiry part references and return true in simplify ref_chain. It's just now regtesting. Cheers 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 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- Created attachment 45257 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45257=edit gcc9-pr87881.patch Untested fix. simplify_const_ref is similar, but actually iterates p->ref and thus properly stops immediately after handling the REF_INQUIRY, returning true, because it has no further refs. simplify_ref_chain is weird in that it is passed two arguments, one ref and one p, where in all callers do pass p->ref and to those arguments, so if for REF_INQUIRY we replace *p with something different, all the references are freed and we need to stop iterating.
[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 Dominique d'Humieres changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #10 from Dominique d'Humieres --- *** Bug 88536 has been marked as a duplicate of this bug. ***
[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 #9 from Dominique d'Humieres --- Hi Paul, > I am getting nowhere with this. ... Did you try to run gfortran under valgrind? I think there is a latent bug in gfortran that triggers the ==82437==ERROR: AddressSanitizer: heap-use-after-free on address 0x617053d8 at pc 0x0001001565a9 bp 0x7ffeefbfcb60 sp 0x7ffeefbfcb58 READ of size 8 at 0x617053d8 thread T0 ... pr52622 gcc fortran unassig...@gcc.gnu.org NEW --- heap-use-after-free with instrumented compiler 2018-07-24 pr78746 gcc fortran unassig...@gcc.gnu.org NEW --- charlen_03, charlen_10 ICE 2018-07-24 pr81531 gcc fortran unassig...@gcc.gnu.org NEW --- Multiple Invalid reads seen by valgrind on an invalid test-case 2018-07-24 pr87881 gcc fortran unassig...@gcc.gnu.org NEW --- gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin Sat 18:32 pr87908 gcc fortran unassig...@gcc.gnu.org NEW --- ICE in check_interface0, at fortran/interface.c:18412018-11-06 pr79524 gcc fortran unassig...@gcc.gnu.org NEW --- [7/8/9 Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90 2018-10-26 pr82721 gcc fortran unassig...@gcc.gnu.org NEW --- [7/8/9 Regression] Error message with corrupted text, sometimes ICE 2018-07-24 pr84245 gcc fortran unassig...@gcc.gnu.org NEW --- [7/8/9 Regression] ICE in delete_root, at fortran/bbt.c:150 2018-02-07 pr86657 gcc fortran unassig...@gcc.gnu.org NEW --- ASAN error: heap-use-after-free gcc/fortran/symbol.c:1762 in gfc_add_flavor 2018-07-24 pr87994 gcc fortran unassig...@gcc.gnu.org NEW --- ICE in match_data_constant, at fortran/decl.c:399 19:01:42 > Have you joined the 'gilets jaunes' today ;-) I hate the people behind it!-(
[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/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 Dominique d'Humieres changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from Dominique d'Humieres --- *** Bug 88068 has been marked as a duplicate of this bug. ***
[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 #6 from Dominique d'Humieres --- Related to/duplicate of pr87993 and pr87994.
[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 #5 from Dominique d'Humieres --- Related to/duplicate of pr87945?
[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 #3 from Dominique d'Humieres --- > First, I have tested the patch at > https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892 > with the test in pr40196 comment 9 without seeing any problem. > So it seems that the problem has been introduced/uncovered by the subsequent > changes. Confirmed for the first test in comment 2 for which the ICE appears with the patch at https://gcc.gnu.org/ml/fortran/2018-10/msg00115.html. The ICE for the second test in comment 2 was already present with the first patch.
[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 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-06 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- First, I have tested the patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892 with the test in pr40196 comment 9 without seeing any problem. So it seems that the problem has been introduced/uncovered by the subsequent changes. Second, I see the ICE for two quite different reduced tests: module m character (:), allocatable :: str type :: mytype character(6) :: str end type end module use m type(mytype) :: der str = "abcd" ! if (str%kind .ne. kind (str)) stop 6 if (der%str%len .ne. len (der%str)) stop 7 end for which the ICE is also seen for the commented line, and complex, parameter :: zc = ( 99.0, 199.0 ) REAL, parameter :: rc = zc%re REAL, parameter :: ic = zc%im end for which the two lines 'REAL, parameter' are needed to trigger the ICE. Compiling these tests with an instrumented compiler gives: = ==75699==ERROR: AddressSanitizer: heap-use-after-free on address 0x617045d8 at pc 0x00010015620e bp 0x7ffeefbfccf0 sp 0x7ffeefbfcce8 READ of size 8 at 0x617045d8 thread T0 #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 #3 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429 #4 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157 #5 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211 #6 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264 #7 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351 #8 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480 #9 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547 #10 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593 #11 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693 #12 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718 #13 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761 #14 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806 #15 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865 #16 0x10015adb1 in gfc_match_init_expr(gfc_expr**) expr.c:2987 #17 0x1000f6516 in variable_decl(int) decl.c:2715 #18 0x1000f77f3 in gfc_match_data_decl() decl.c:5926 #19 0x100330018 in match_word(char const*, match (*)(), locus*) parse.c:65 #20 0x10033c950 in decode_statement() parse.c:376 #21 0x10033eef6 in next_free() parse.c:1234 #22 0x10033f8cb in next_statement() parse.c:1466 #23 0x100345fab in parse_spec(gfc_statement) parse.c:3858 #24 0x10034cbfa in parse_progunit(gfc_statement) parse.c:5671 #25 0x10034f8de in gfc_parse_file() parse.c:6259 #26 0x100522fbf in gfc_be_parse_file() f95-lang.c:204 #27 0x10611cde8 in compile_file() toplev.c:455 #28 0x1061284a3 in do_compile() toplev.c:2172 #29 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307 #30 0x1095b359c in main main.c:39 #31 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c) 0x617045d8 is located 728 bytes inside of 736-byte region [0x61704300,0x617045e0) freed by thread T0 here: #0 0x158cb18e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121 #1 0x10012e5f7 in gfc_free_ref_list(gfc_ref*) expr.c:599 #2 0x10012ecef in free_expr0(gfc_expr*) expr.c:505 #3 0x10012f0d0 in gfc_replace_expr(gfc_expr*, gfc_expr*) expr.c:616 #4 0x10015601c in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1970 #5 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064 #6 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool) primary.c:2287 #7 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429 #8 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157 #9 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211 #10 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264 #11 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351 #12 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480 #13 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547 #14 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593 #15 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693 #16 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718 #17 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761 #18 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806 #19 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865 #20
[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
