[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #39 from vehre at gcc dot gnu.org --- No objections so far, seems to be fixed with r223445.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #38 from vehre at gcc dot gnu.org --- Author: vehre Date: Wed May 20 14:56:47 2015 New Revision: 223445 URL: https://gcc.gnu.org/viewcvs?rev=223445root=gccview=rev Log: gcc/fortran/ChangeLog: 2015-05-19 Andre Vehreschild ve...@gmx.de PR fortran/65548 * trans-stmt.c (gfc_trans_allocate): Always retrieve the descriptor or a reference to a source= expression for arrays and non-arrays, respectively. Use a temporary symbol and gfc_trans_assignment for all source= assignments to allocated objects besides for class and derived types. gcc/testsuite/ChangeLog: 2015-05-19 Andre Vehreschild ve...@gmx.de PR fortran/65548 * gfortran.dg/allocate_with_source_5.f90: Extend test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #37 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to vehre from comment #36) I am waiting for an official review of the patch, to be allowed to commit to trunk. So I am not waiting on you. :-) I see. Got it. :D
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #35 from Jürgen Reuter juergen.reuter at desy dot de --- What are u waiting for?^^ already confirmed in comment #34 that rverything in our code works with the patch
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #36 from vehre at gcc dot gnu.org --- I am waiting for an official review of the patch, to be allowed to commit to trunk. So I am not waiting on you. :-)
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #33 from vehre at gcc dot gnu.org --- I can only work on the issue, not do magic. When you have issues with svn checkout try the gitmirror: https://gcc.gnu.org/wiki/GitMirror
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #32 from Jürgen Reuter juergen.reuter at desy dot de --- With gcc-6.0 trunk I cannot test our complete code because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 For gcc 5 trunk I have massive problems in checking out the svn at the moment, always getting timeouts.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #31 from vehre at gcc dot gnu.org --- That should not matter. I have prepared the patch on trunk (aka 6.0), but it should also apply on the 5.x-branch (with automatic offsets).
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #34 from Jürgen Reuter juergen.reuter at desy dot de --- Andre, I checked your patch with r222305 of the gcc 6.0 trunk. Our complete code (without workarounds for the two remaining cases reported) compiles, and our complete testsuite works. Thanks for the patch.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #30 from Jürgen Reuter juergen.reuter at desy dot de --- I can apply this patch on r222550 of https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/ correct?
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Attachment #35318|0 |1 is obsolete|| --- Comment #29 from vehre at gcc dot gnu.org --- Created attachment 35419 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35419action=edit Candidate patch for latest regressions. Juergen, please test.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #27 from Jürgen Reuter juergen.reuter at desy dot de --- And Example #2 is: module foo type :: t integer :: n character(32), dimension(:), allocatable :: md5 contains procedure :: init = t_init end type t contains subroutine t_init (this) class(t), intent(inout) :: this character(32), dimension(:), allocatable :: md5 allocate (md5 (this%n), source=this%md5) end subroutine t_init end module foo $ gfortran -c bar.f90 bar.f90:14:0: allocate (md5 (this%n), source=this%md5) 1 internal compiler error: Segmentation fault: 11 dreck.f90:14:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951)
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr --- And Example #2 is: ... Confirmed too, but no ICE under debugger.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW --- Comment #26 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the test in comment 25 gives the following ICE pr65548_2.f90:17:0: allocate (int (0:this%n-1), source=this%get_int()) 1 internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:5755 even with the patch in comment in comment 13.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #21 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to vehre from comment #20) Juergen, could you meanwhile check, that the patch fixes the issue? Damn, it seems my text didn't get posted. Being in Japan at the moment, and sometimes not having the best connection. NO, it doesn't fix the issue. The one I posted yes, but there are two other cases where it fails.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #22 from Jürgen Reuter juergen.reuter at desy dot de --- One thing is: allocate (foo (0:this%dim-1), source=this%get_integral()) where this is some derived type with integer component dim and TBP get_integral which is a function generic :: get_integral = get_integral_array, get_integral_1 procedure :: get_integral_array procedure :: get_integral_1 subroutine get_integral_array (this, integral) class(t) :: this real, intent(out), dimension(:) :: integral integral = this%integral end subroutine get_integral_array subroutine get_integral_1 (this, integral) class(t) :: this real, intent(out) :: integral integral = this%integral(1) end subroutine get_integral_1
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #23 from Jürgen Reuter juergen.reuter at desy dot de --- The other failure occurs for allocate (foo (this%n), source=this%bar) where n is integer, foo has type character(32), dimension(:), allocatable and bar as well.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #20 from vehre at gcc dot gnu.org --- Juergen, could you meanwhile check, that the patch fixes the issue?
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de --- Example 1: module foo type :: t integer :: n real, dimension(:,:), allocatable :: val contains procedure :: make = t_make generic :: get_int = get_int_array, get_int_element procedure :: get_int_array = t_get_int_array procedure :: get_int_element = t_get_int_element end type t contains subroutine t_make (this) class(t), intent(inout) :: this real, dimension(:), allocatable :: int allocate (int (0:this%n-1), source=this%get_int()) end subroutine t_make pure function t_get_int_array (this) result (array) class(t), intent(in) :: this real, dimension(this%n) :: array array = this%val (0:this%n-1, 4) end function t_get_int_array pure function t_get_int_element (this, set) result (element) class(t), intent(in) :: this integer, intent(in) :: set real :: element element = this%val (set, 4) end function t_get_int_element end module foo
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- Could you please post complete tests: i.e. triggering only the relevant error?
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #17 from Jürgen Reuter juergen.reuter at desy dot de --- I applied the patch, and did a make in the built folder. I still get the ICE. Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely new built of the gcc/gfortran compiler suite?
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr --- I applied the patch, and did a make in the built folder. I still get the ICE. Did you do make install? Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely new built of the gcc/gfortran compiler suite? It is always safer to do a clean bootstrap, but it should not be necessary. When patching gfortran I usually doe touch gcc/fortran/* which forces to rebuild fortran at all stages and rebuild libgfortran.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #15 from vehre at gcc dot gnu.org --- That patch is relative to current trunk, meaning 6.0.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- That patch is relative to current trunk, meaning 6.0. I think it should not matter: the patch should apply on 5.0.1 or 6.0. Applied on a patched 6.0 tree it works as advertised.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #14 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to vehre from comment #13) Created attachment 35318 [details] Follow-up patch fixing latest regression. The attached patch fixes the ICE. Juergen, please check and report back, to prevent closed-reopen-cycle. Will do. Is that relativ also to the 6.0_development trunk? I had an IT-security enforced OS upgrade meaning I have to recompile my compilers. And I wanted to check 6.0, but I can also try 5.1 release (as soon as the tarball is there).
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #13 from vehre at gcc dot gnu.org --- Created attachment 35318 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35318action=edit Follow-up patch fixing latest regression. The attached patch fixes the ICE. Juergen, please check and report back, to prevent closed-reopen-cycle.
