This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, Fortran] PR fortran/60289 First try on: Fixing character array allocation for class(*) type variable


Hello,

Le 10/08/2014 13:55, Andre Vehreschild a écrit :
> Hi,
> 
> I am proposing another patch, this time to resolve PR60289. The issue in the bug
> reported is, that a code like:
> 
> 	class(*), pointer :: P
> 	allocate(character(20)::P)
> 
> is rejected by trunk's gfortran compiler. janus@gcc.gnu.org proposed a first
> patch in the PR, which my patch extends. 
> 
> Motivation: Previously parsing of the type association to the unlimited
> polymorphic variable P was not allowed and reported the error "Error:
> Allocating p at (1) with type-spec requires the same character-length parameter
> as in the declaration", after the errorneous error report was fixed by
> janus' patch, an ICE occured in trans-stmt.c's gfc_trans_allocate()-routine.
> The ICE reported in PR60289 is something different and does not occur in trunk
> anymore. The ICE reported now boils down to line 5056 in trans-stmt.c:
> 
> 	tmp= al->expr->ts.u.cl->backend_decl;
> 
> The dereferencing of ts.u's cl member is valid only, when ts.type is of
> BT_CHARACTER. With al->expr being an unlimited polymorphic type, the
> backend_decl is not available in cl.
> 
> Although there is a backend_decl available in ts.u.derived, I was not able to
> get it compatible for the fold_convert in the line following the assignment to
> tmp:
> 
> 	gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE(tmp),
> 						              se_sz.expr));
> 
> My current solution therefore is to execute those two statements only, when
> ts.type is of BT_CHARACTER.

My knowledge of unlimited polymorphic types is limited, but I think that
this is not correct.
The new length of the string has to be stored somewhere.  If you don't
do that, for example the intrinsic len() function won't work.

> 
> Can someone explain what the fold_convert is doing in that specific place? I
> assume that it is checking for and ensuring some type compatibility. Is there
> some documentation available, explaining this? Is something similar needed for
> the unlimited polymorphic variable?

Well, I didn't find any documentation for fold_convert - except the
code.  In general, the fold_foo functions try to do foo, simplifying
away useless operations.  So fold_convert adds a type conversion, unless
that is unnecessary (if the types are already the same for example).


Mikael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]