[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||dominiq at lps dot ens.fr Resolution|FIXED | --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2013-01-14 20:32:04 UTC --- ICE noted by Dominique d'Humieres with module m type :: foobar real, pointer :: array(:) procedure (), pointer, nopass :: f end type contains elemental subroutine fooAssgn (a1, a2) type(foobar), intent(out) :: a1 type(foobar), intent(in) :: a2 allocate (a1%array(size(a2%array))) a1%array = a2%array a1%f = a2%f end subroutine end module m Dominique also provided the fix on #gfortran: in gfc_check_pointer_assign of ../../gcc/fortran/expr.c:3540 replacing if (s2-attr.proc_pointer with if (s2 s2-attr.proc_pointer lets the code compile. Will commit as 'obvious' as soon as it has bootstrapped and regtested. Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-14 22:35:20 UTC --- Additional comment from #gfortran: AFAIU this kind of changes, they cannot cause a problem for anything that did not triggered the ICE. So they are basically harmless, excepted that they can trun an ICE into a wrong code, which is worse (IMO). Too bad I cannot remember the origin of the code.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #10 from Paul Thomas pault at gcc dot gnu.org 2013-01-15 05:29:07 UTC --- Author: pault Date: Tue Jan 15 05:29:01 2013 New Revision: 195185 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195185 Log: 2013-01-15 Paul Thomas pa...@gcc.gnu.org PR fortran/54286 * expr.c (gfc_check_pointer_assign): Check for presence of 's2' before using it. 2013-01-15 Paul Thomas pa...@gcc.gnu.org PR fortran/54286 * gfortran.dg/proc_ptr_result_8.f90 : Add module 'm' to check case where interface is null. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_8.f90
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Paul Thomas pault at gcc dot gnu.org 2013-01-15 05:34:25 UTC --- Hopefully, it will stay fixed this time! Thanks Dominique. Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2013-01-13 08:57:51 UTC --- Author: pault Date: Sun Jan 13 08:57:46 2013 New Revision: 195133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195133 Log: 2013-01-13 Paul Thomas pa...@gcc.gnu.org PR fortran/54286 * expr.c (gfc_check_pointer_assign): Ensure that both lvalue and rvalue interfaces are presented to gfc_compare_interfaces. Simplify references to interface names by using the symbols themselves. Call gfc_compare_interfaces with s1 and s2 inter- changed to overcome the asymmetry of this function. Do not repeat the check for the presence of s1 and s2. 2013-01-13 Paul Thomas pa...@gcc.gnu.org PR fortran/54286 * gfortran.dg/proc_ptr_result_8.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2013-01-14 05:52:48 UTC --- Fixed on trunk. Thanks for the report Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #3 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 09:44:07 UTC --- Please find below my interpretation of the validity or not of the testcase for this PR. The following test is probably invalid, but not rejected by recent trunk versions: type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p = a ! ok [A] I believe that this is invalid because the interfaces do not match procedure(iabs), pointer = integer pointer procedure (integer formal) It strikes me as being a moot point as to whetehr or not the processor is required to report it though, on the gorunds that anything goes with pointers! That said, the interface check is easy to implement. x%p = a(1) ! invalid, but not rejected by 4.8 [B] This is valid: procedure(iabs), pointer = pointer to integer procedure(iabs) It has the pleasing property of providing the correct result for print *, x%p(-99) .eq. iabs(-99) pp = a(2) ! ok [B] applies - it also gives the correct result. pp = a ! invalid, but not rejected by 4.8 [A] applies - invalid. contains function a (c) result (b) integer, intent(in) :: c procedure(iabs), pointer :: b b = iabs end function end Interestingly, both invalid lines run and provide results that are consistent with INT (loc (iabs)) :-) Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-01-09 12:06:53 UTC --- (In reply to comment #3) type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p = a ! ok [A] I believe that this is invalid because the interfaces do not match procedure(iabs), pointer = integer pointer procedure (integer formal) [...] x%p = a(1) ! invalid, but not rejected by 4.8 [B] This is valid: procedure(iabs), pointer = pointer to integer procedure(iabs) Huh? the interface of `x%p' is `a', not `iabs'. I think the comments are correct; the former is valid, the latter invalid.
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 --- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2013-01-09 13:07:31 UTC --- (In reply to comment #4) (In reply to comment #3) snip Huh? the interface of `x%p' is `a', not `iabs'. I think the comments are correct; the former is valid, the latter invalid. Quite right - thanks, Mikael. I missed/forgot/ignored the first interface. That makes life a lot easier because the patch does the right thing :-) Cheers Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-08 AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Paul Thomas pault at gcc dot gnu.org 2013-01-08 21:43:46 UTC --- Created attachment 29113 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29113 A patch that recovers the original error Tobias' remarks about the appropriateness of the error are justified. I will look into this tomorrow. Paul
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.0
[Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-19 12:28:50 UTC --- (When you look into this problem: I think the current handling of assumed-rank is also wrong (sorry, my mistake). For array passing, assumed-rank dummies take any rank (including scalar). However, for dummy procedures or proc-pointers, if the dummy/proc-pointer has an assumed rank dummy, the actual/proc/target has to have one too.)
