[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-11-16 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-10-21 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Paul Thomas  ---
Completely resolved on trunk.

Thanks for the report

Paul

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-10-21 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Fri Oct 21 12:50:56 2016
New Revision: 241403

URL: https://gcc.gnu.org/viewcvs?rev=241403=gcc=rev
Log:
2016-10-21  Paul Thomas  

PR fortran/69566
* resolve.c (fixup_array_ref): New function.
(resolve_select_type): Gather up the rank and array reference,
if any, from the selector. Fix up the 'associate name' and the
'associate entities' as necessary.
* trans-expr.c (gfc_conv_class_to_class): If the symbol backend
decl is a FUNCTION_DECL, use the 'fake_result_decl' instead.

2016-10-21  Paul Thomas  

PR fortran/69566
* gfortran.dg/select_type_37.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/select_type_37.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-10-13 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

--- Comment #6 from Dominique d'Humieres  ---
Beware of pr30617 in the test in comment 4! Otherwise the patch seems to work
as expected.

Thanks,

Dominique

> Le 13 oct. 2016 à 16:14, pault at gcc dot gnu.org  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
> 
> --- Comment #5 from Paul Thomas  ---
> Created attachment 39805
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit
> Fix for the PR
> 
> The attached fixes the testcase in the comment and more besides. I think that
> some of the fix is unnecessary. I will do final adjustments once I am back at
> base.
> 
> It bootstraps and regtests on FC23/x87_64
> 
> Paul
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-10-13 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

--- Comment #5 from Paul Thomas  ---
Created attachment 39805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit
Fix for the PR

The attached fixes the testcase in the comment and more besides. I think that
some of the fix is unnecessary. I will do final adjustments once I am back at
base.

It bootstraps and regtests on FC23/x87_64

Paul

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

2016-01-30 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
Summary|[6 Regression] ICE with |Failure of SELECT TYPE with
   |unlimited polymorphic array |unlimited polymorphic
   |pointer function|function result

--- Comment #4 from Paul Thomas  ---
The bug that is uncovered by the above fix is:
  print *, associated(return_pointer()) ! ICE
contains
  function return_pointer()
class(*), pointer :: return_pointer(:)
allocate (return_pointer, source = [1.0,2.0])
select type (return_pointer)
  type is (real(4))
print *, return_pointer
end select
  end function
end

./pr69566/pr69566.f90:7:23:

   type is (real(4))
   1
Error: Associate-name ‘__tmp_REAL_4’ at (1) is used as array

This does not occur if the function has an explicit result.

I have seen this one before :-(

Paul