[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #29 from Paul Thomas --- Author: pault Date: Fri Jan 15 20:33:58 2016 New Revision: 232450 URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev Log: 2016-01-15 Paul Thomas PR fortran/64324 * resolve.c (check_uop_procedure): Prevent deferred length characters from being trapped by assumed length error. PR fortran/49630 PR fortran/54070 PR fortran/60593 PR fortran/60795 PR fortran/61147 PR fortran/64324 * trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for function as well as variable expressions. (gfc_array_init_size): Add 'expr' as an argument. Use this to correctly set the descriptor dtype for deferred characters. (gfc_array_allocate): Add 'expr' to the call to 'gfc_array_init_size'. * trans.c (gfc_build_array_ref): Expand logic for setting span to include indirect references to character lengths. * trans-decl.c (gfc_get_symbol_decl): Ensure that deferred result char lengths that are PARM_DECLs are indirectly referenced both for directly passed and by reference. (create_function_arglist): If the length type is a pointer type then store the length as the 'passed_length' and make the char length an indirect reference to it. (gfc_trans_deferred_vars): If a character length has escaped being set as an indirect reference, return it via the 'passed length'. * trans-expr.c (gfc_conv_procedure_call): The length of deferred character length results is set TREE_STATIC and set to zero. (gfc_trans_assignment_1): Do not fix the rse string_length if it is a variable, a parameter or an indirect reference. Add the code to trap assignment of scalars to unallocated arrays. * trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and all references to it. Instead, replicate the code to obtain a explicitly defined string length and provide a value before array allocation so that the dtype is correctly set. trans-types.c (gfc_get_character_type): If the character length is a pointer, use the indirect reference. 2016-01-15 Paul Thomas PR fortran/49630 * gfortran.dg/deferred_character_13.f90: New test for the fix of comment 3 of the PR. PR fortran/54070 * gfortran.dg/deferred_character_8.f90: New test * gfortran.dg/allocate_error_5.f90: New test PR fortran/60593 * gfortran.dg/deferred_character_10.f90: New test PR fortran/60795 * gfortran.dg/deferred_character_14.f90: New test PR fortran/61147 * gfortran.dg/deferred_character_11.f90: New test PR fortran/64324 * gfortran.dg/deferred_character_9.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_10.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_11.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_12.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_13.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_14.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_8.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #28 from Paul Thomas --- (In reply to paul.richard.tho...@gmail.com from comment #27) > ...so ragged in fact that it fails at all levels of optimization I > have not had time these last days to come back to it and understand > why. Something for the holidays! > > Paul > > On 28 November 2015 at 11:19, pault at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 > > > > Paul Thomas changed: > > > >What|Removed |Added > > > >Assignee|unassigned at gcc dot gnu.org |pault at gcc dot > > gnu.org > > > > --- Comment #26 from Paul Thomas --- > > I have a somewhat ragged patch that does the job. I will be cleaning it up > > in > > the next 24 hours for submission. > > > > Paul > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > You are the assignee for the bug. OK - I found the problem with correct code; ie. the three cases in comment #0 with an allocation. However, not for the first time, I have failed to make the -fcheck=mem test work for the unallocated result. I suspect that there is some trivial problem and that I will crack it in the next 24 hours. Paul
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #27 from paul.richard.thomas at gmail dot com --- ...so ragged in fact that it fails at all levels of optimization I have not had time these last days to come back to it and understand why. Something for the holidays! Paul On 28 November 2015 at 11:19, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 > > Paul Thomas changed: > >What|Removed |Added > >Assignee|unassigned at gcc dot gnu.org |pault at gcc dot > gnu.org > > --- Comment #26 from Paul Thomas --- > I have a somewhat ragged patch that does the job. I will be cleaning it up in > the next 24 hours for submission. > > Paul > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #26 from Paul Thomas --- I have a somewhat ragged patch that does the job. I will be cleaning it up in the next 24 hours for submission. Paul
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #25 from Dominique d'Humieres --- The regression (ICE) is caused by revision r188692 (pr53642). If I apply the following patch --- ../_clean/gcc/fortran/trans-expr.c 2015-10-29 17:11:18.0 +0100 +++ gcc/fortran/trans-expr.c2015-11-02 23:44:18.0 +0100 @@ -9288,7 +9354,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1 otherwise the character length of the result is not known. NOTE: This relies on having the exact dependence of the length type parameter available to the caller; gfortran saves it in the .mod files. */ - if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred) + if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred && expr2->expr_type != EXPR_VARIABLE) gfc_add_block_to_block (&block, &rse.pre); /* Nullify the allocatable components corresponding to those of the lhs the ICEs are gone (it does not mean that the generated code is correct!) but the test gfortran.dg/deferred_type_param_8.f90 aborts at run time.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #24 from Dominique d'Humieres --- The test in comment 23 looks like a duplicate of pr50221.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #23 from neil.n.carlson at gmail dot com --- Here's an even simpler example with the deferred length character array as a local variable -- not a function result or dummy argument. Sure seems as though the allocate statement itself is what is being mishandled: program main character(:), pointer :: s(:) allocate(character(3)::s(2)) s(1) = 'foo'; s(2) = 'bar' print *, s, ' (expect "foobar")' end program Compiles with both 5.2 and 6.0 20151025, but both return the wrong result: barbar (expect "foobar")
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #22 from Dominique d'Humieres ---
> What is the status of this issue? It would appear from comment 18
> to be "fixed" insofar as the the provided examples compile, but is
> the compiled code correct?
This a wrong interpretation: most of the tests used to compile (with r188654,
hence the regression), at some point compiling most of them gave an ICE, now
two of them compiles. I never said that the compiled codes were correct, they
are all missing a test for that. In top of that this PR is still opened.
Now the following variant of 'b' ('a' being the original test, i.e., the third
in comment 0):
print *, "'", f(), "'"
contains
function f()
character(len=:),allocatable :: f
f ="ABC"
end function
end
compiles and outputs
'ABC'
Now tha problem is that there are several PRs opened for deferred-length (at
least nine, eight now!-) and so far nobody care to check for duplicates.
Note that comment 18 was an answer to comment 17
> I found it fixed in 5.2.0
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #21 from Dominique d'Humieres --- *** Bug 66065 has been marked as a duplicate of this bug. ***
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #20 from kargl at gcc dot gnu.org --- (In reply to neil.n.carlson from comment #19) > What is the status of this issue? It appears to not be completely fixed.
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 neil.n.carlson at gmail dot com changed: What|Removed |Added CC||neil.n.carlson at gmail dot com --- Comment #19 from neil.n.carlson at gmail dot com --- What is the status of this issue? It would appear from comment 18 to be "fixed" insofar as the the provided examples compile, but is the compiled code correct? I'd report the following example as a new bug, but I know it would be immediately dismissed as a duplicate of this bug. This dumb little example compiles with 5.2 and the 20151025 snapshot of 6.0, but in both cases the generated code is bad as it segfaults on a clearly valid assignment statement. program main character(:), allocatable :: string(:) call fubar (string) contains subroutine fubar (string) character(:), allocatable, intent(out) :: string(:) allocate(character(5) :: string(2)) print *, 'len(string)=', len(string), ', size(string)=', size(string) string = 'fubar' ! <== SEGMENTATION FAULT HERE end subroutine end program Produces this output: len(string)= 5 , size(string)= 2 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FFB05C4E517 #1 0x7FFB05C4EB5E #2 0x7FFB0514F95F #3 0x7FFB051B6EC8 #4 0x400D23 in fubar.3417 at fubar.f90:? #5 0x400DC9 in MAIN__ at fubar.f90:? Segmentation fault (core dumped)
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Dominique d'Humieres changed: What|Removed |Added Known to work||4.8.0 Blocks||20585 Known to fail||4.8.1 --- Comment #18 from Dominique d'Humieres --- > I found it fixed in 5.2.0 This PR contains 5 tests. Let me label them a, b, and c for the ones in comment 0, d for the one in comment 4 and e for the one in comment 7. As for today I find that a, c, and e are still giving an ICE with 4.9 up to trunk (6.0), b compiles with 4.9 up to trunk, and d compiles with 5.2 and trunk, but still gives an ICE with 4.9.4. I confirm that revision r188654 compiles a, c, d, and e, but not b. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 [Bug 20585] [meta-bug] Fortran 2003 support
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #17 from Vittorio Zecca --- I found it fixed in 5.2.0
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.9.3 |4.9.4
[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 --- Comment #16 from Jakub Jelinek --- GCC 4.9.3 has been released.
