[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[6 regression] ICE on valid |[6 regression] ICE on valid |with -fcheck=all|with -fcheck=mem --- Comment #4 from janus at gcc dot gnu.org --- The test case can be further condensed into: module utilities implicit none type :: string character(len=:), allocatable :: s end type contains function getCmdLine() type(string),dimension(:),allocatable :: getCmdLine allocate(getCmdLine(command_argument_count())) end function end module In particular the offending check (out of the range of stuff done with -fcheck=all) is -fcheck=mem. With a current trunk build the backtrace is: internal compiler error: in wide_int_to_tree, at tree.c:1488 0xc757a3 wide_int_to_tree(tree_node*, generic_wide_int > const&) /home/janus/gcc/trunk/gcc/tree.c:1488 0xc75899 build_int_cst(tree_node*, long) /home/janus/gcc/trunk/gcc/tree.c:1296 0x6bf425 gfc_trans_assignment_1 /home/janus/gcc/trunk/gcc/fortran/trans-expr.c:9305 0x687ce5 trans_code /home/janus/gcc/trunk/gcc/fortran/trans.c:1704 0x6abeec gfc_generate_function_code(gfc_namespace*) /home/janus/gcc/trunk/gcc/fortran/trans-decl.c:6107 0x68b449 gfc_generate_module_code(gfc_namespace*) /home/janus/gcc/trunk/gcc/fortran/trans.c:2058 0x642ccd translate_all_program_units /home/janus/gcc/trunk/gcc/fortran/parse.c:5599 0x642ccd gfc_parse_file() /home/janus/gcc/trunk/gcc/fortran/parse.c:5818 0x684f32 gfc_be_parse_file /home/janus/gcc/trunk/gcc/fortran/f95-lang.c:201
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #5 from janus at gcc dot gnu.org --- In fact I have hit the same ICE with a slightly different test case: program test implicit none type :: t real, allocatable :: r(:) end type type(t) :: a a%r = 0. end
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #6 from paul.richard.thomas at gmail dot com --- Dear Janus, It's good to hear from you. As you will have seen, I have posted a fix for the first problem and have another fix in the pipeline for the problem in comment #5. I'll post them on the PR but cannot do any more than that until SUnday night. Cheers Paul On 20 January 2016 at 22:32, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 > > --- Comment #5 from janus at gcc dot gnu.org --- > In fact I have hit the same ICE with a slightly different test case: > > > program test > > implicit none > > type :: t > real, allocatable :: r(:) > end type > > type(t) :: a > > a%r = 0. > > end > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 Dominique d'Humieres changed: What|Removed |Added CC||mrestelli at gmail dot com --- Comment #7 from Dominique d'Humieres --- *** Bug 69409 has been marked as a duplicate of this bug. ***
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from janus at gcc dot gnu.org --- Hi Paul, > As you will have seen, I have posted a fix for the first problem you mean the one in comment #3? It sounded like you were not quite happy with it yet, but I will anyway give it a try tonight ... > and > have another fix in the pipeline for the problem in comment #5. > > I'll post them on the PR but cannot do any more than that until SUnday night. Yes, if you have any further patches, please share them here. I will be happy to regtest anything you manage to cook up ... Cheers, Janus
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #9 from janus at gcc dot gnu.org --- So, I can confirm that the modification suggested in comment #3, represented by this patch ... Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(Revision 232631) +++ gcc/fortran/trans-expr.c(Arbeitskopie) @@ -9286,6 +9286,7 @@ { gfc_conv_expr (&lse, expr1); if (gfc_option.rtcheck & GFC_RTCHECK_MEM + && !init_flag && gfc_expr_attr (expr1).allocatable && expr1->rank && !expr2->rank) ... fixes the original problem, but not the one with comment #5. I'm regtesting this now.
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) > I'm regtesting this now. "make check-gfortran" does not report any unexpected failures.
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #11 from Paul Thomas --- Changing the entire block to: { gfc_conv_expr (&lse, expr1); if (gfc_option.rtcheck & GFC_RTCHECK_MEM && !init_flag && gfc_expr_attr (expr1).allocatable && expr1->rank && !expr2->rank) { tree cond; const char* msg; /* We should only get array references here. */ gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR || TREE_CODE (lse.expr) == ARRAY_REF); /* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR) or the array itself(ARRAY_REF). */ tmp = TREE_OPERAND (lse.expr, 0); /* Provide the address of the array. */ if (TREE_CODE (lse.expr) == ARRAY_REF) tmp = gfc_build_addr_expr (NULL_TREE, tmp); cond = fold_build2_loc (input_location, EQ_EXPR, boolean_type_node, tmp, build_int_cst (TREE_TYPE (tmp), 0)); msg = _("Assignment of scalar to unallocated array"); gfc_trans_runtime_check (true, false, cond, &loop.pre, &expr1->where, msg); } } fixes Martin's problem and makes the following work correctly: ! { dg-do run } ! { dg-additional-options "-fcheck=mem" } ! { dg-shouldfail "Fortran runtime error: Assignment of scalar to unallocated array" } ! ! This omission was encountered in the course of fixing PR54070. Whilst this is a ! very specific case, others such as allocatable components have been tested. ! ! Contributed by Tobias Burnus ! function g(a) result (res) real :: a real,allocatable :: res(:) res = a ! Since 'res' is not allocated, a runtime error should occur. end function interface function g(a) result(res) real :: a real,allocatable :: res(:) end function end interface ! print *, g(2.0) ! call foo call foofoo contains subroutine foo type bar real, allocatable, dimension(:) :: r end type type (bar) :: foobar foobar%r = 1.0 end subroutine subroutine foofoo type barfoo character(:), allocatable, dimension(:) :: c end type type (barfoo) :: foobarfoo foobarfoo%c = "1.0" end subroutine end If you want to wrap it up and submit it, please do so. Otherwise, I will attend to it on Sunday. For some reason that I cannot for the life of me understand, my svn+ssh connection from my laptop is failing because of some problem with my public keys. This crept in a couple of weeks ago but hasn't affected my workstations. The consequence is that I haven't been able to update my tree and cannot therefore take the specific diff. sigh Paul
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #12 from Paul Thomas --- By the way, the correction of comment #11 retests OK. Cheers Paul
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > Changing the entire block to: > [...] > fixes Martin's problem and makes the following work correctly: It also cures my problem, i.e. comment 5. Thanks a lot for the fix! > For some reason that I cannot for the life of me understand, my svn+ssh > connection from my laptop is failing because of some problem with my public > keys. I recently got an email from the sourceware admins which said they are currently scanning the ssh keys for continued compatibility. Possibly you need to generate a new key (in case yours is too weak). Mine is apparently still working, luckily.
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #14 from paul.richard.thomas at gmail dot com --- Hi Janus, Would you be so good as to OK this patch to the list? Thanks Paul On 22 January 2016 at 12:50, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 > > --- Comment #13 from janus at gcc dot gnu.org --- > (In reply to Paul Thomas from comment #11) >> Changing the entire block to: >> [...] >> fixes Martin's problem and makes the following work correctly: > > It also cures my problem, i.e. comment 5. Thanks a lot for the fix! > > >> For some reason that I cannot for the life of me understand, my svn+ssh >> connection from my laptop is failing because of some problem with my public >> keys. > > I recently got an email from the sourceware admins which said they are > currently scanning the ssh keys for continued compatibility. Possibly you need > to generate a new key (in case yours is too weak). Mine is apparently still > working, luckily. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #14) > Would you be so good as to OK this patch to the list? Sure, will do ...
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #16 from Paul Thomas --- Author: pault Date: Tue Jan 26 21:57:12 2016 New Revision: 232850 URL: https://gcc.gnu.org/viewcvs?rev=232850&root=gcc&view=rev Log: 2016-01-26 Paul Thomas PR fortran/69385 * trans-expr.c (gfc_trans_assignment_1): Exclude initialization assignments from check on assignment of scalars to unassigned arrays and correct wrong code within the corresponding block. 2015-01-26 Paul Thomas PR fortran/69385 * gfortran.dg/allocate_error_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Paul Thomas --- Hi Martin, Thanks for the report - it's now fixed. Cheers Paul PS Try to interest one of the other maintainers in respect of your proposed patch to switch off the -fcheck options. I have such a backlog of PRs and fixes that yours is very low on my short-term list. PPS Do you have commit rights?
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #18 from Paul Thomas --- Author: pault Date: Wed Jan 27 21:24:01 2016 New Revision: 232904 URL: https://gcc.gnu.org/viewcvs?rev=232904&root=gcc&view=rev Log: 2016-01-27 Paul Thomas PR fortran/69385 * trans-expr.c (is_scalar_reallocatable_lhs): Remove the check for allocatable components, whilst checking if the symbol is a derived or class entity.. 2015-01-27 Paul Thomas PR fortran/69385 * gfortran.dg/alloc_comp_assign_15.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_15.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #19 from Paul Thomas --- (In reply to Paul Thomas from comment #18) > Author: pault > Date: Wed Jan 27 21:24:01 2016 > New Revision: 232904 > > URL: https://gcc.gnu.org/viewcvs?rev=232904&root=gcc&view=rev > Log: > 2016-01-27 Paul Thomas > > PR fortran/69385 > * trans-expr.c (is_scalar_reallocatable_lhs): Remove the check > for allocatable components, whilst checking if the symbol is a > derived or class entity.. > > 2015-01-27 Paul Thomas > > PR fortran/69385 > * gfortran.dg/alloc_comp_assign_15.f03: New test. > > Added: > trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_15.f03 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/trans-expr.c > trunk/gcc/testsuite/ChangeLog Sorry about the finger trouble. The above is the fix for PR69422. Cheers Paul