This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] PR 46974: Handle C_(FUN)PTR variables in TRANSFER
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Sat, 18 Dec 2010 12:10:50 -0800
- Subject: Re: [Patch, Fortran] PR 46974: Handle C_(FUN)PTR variables in TRANSFER
- References: <4D0D0D27.6080103@net-b.de>
On Sat, Dec 18, 2010 at 08:36:07PM +0100, Tobias Burnus wrote:
> The patch adds compile-time simplification support for C_PTR/C_FUNPTR
> variables. Those are special beasts as they are derived types in Fortran
> (gfc_expr/gfc_symbol) but for the middle end (tree) they are simple
> (function) pointers.
>
> The patch add special treatment to the <transfer bits> ->
> C_(FUN)PTR-type conversion in target-memory.c - and it handles them
> explicitly in assignment. I removed the bits about C_NULL_PTR which
> seems to be dead code. I believe the function is never called for
> C_NULL_PTR as the conversion to an c_intptr_t-like integer happens
> earlier. Additionally, even if for C_NULL_PTR the code block would be
> entered, there were a segfault as the component->backend_decl is NULL.
> -- At least that's how I read gfc_get_derived_type.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>
> PS: I wrote in the PR that one should try to avoid the special handling
> - obviously, I failed. However, the patch at least fixes the PR and
> allows compile-time simplification.
OK.
Thanks for jumping in on the PR. I think I was heading down the
wrong road. In fact, it was becoming "a long and winding road"
(in honor of J. Lennon).
--
Steve