[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
