This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression
- From: Dominique d'Humières <dominiq at lps dot ens dot fr>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Ian Harvey <ian_harvey at bigpond dot com>
- Date: Wed, 9 Nov 2016 16:04:13 +0100
- Subject: Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiKhuq2Pw0T8URCD3ZiA-hDpmXZZr4kJvg8PZQdCoORSWw@mail.gmail.com>
Sorry for the bad news, but while gfortran regtests with regression with the patch I still get a link error with the original test:
% gfc pr44265.f90
Undefined symbols for architecture x86_64:
"___fruits_MOD_names", referenced from:
_MAIN__ in ccyeNqa1.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
and its variants.
Thanks for working on this issue
Dominique
> Le 9 nov. 2016 à 13:47, Paul Richard Thomas <paul.richard.thomas@gmail.com> a écrit :
>
> Dear All,
>
> The title of this PR says what this is all about, except that it
> applies uniquely applicable to character function result string
> lengths.
>
> Ian Harvey wrote the first patch for this PR for which many thanks.
> However, two issues came up that took some little while to understand;
> (i) In comment #1, it was found that calls from sibling procedures
> could generate streams of undefined references at the link stage; and
> (ii) An entity of the same name as the contained procedure entity in
> module scope caused similar problems.
>
> The relationship with Ian's patch is still obvious. The fundamental
> difference is that the parameter arrays are automatically promoted to
> module scope using a unique symtree. This fixes both the issues above.
>
> Dominique, could you please check that the -m32 issue has gone away?
>
> Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
>
> Paul
>
> 2016-11-09 Paul Thomas <pault@gcc.gnu.org>
>
> PR fortran/44265
> * gfortran.h : Add fn_result_spec bitfield to gfc_symbol.
> * resolve.c (flag_fn_result_spec): New function.
> (resolve_fntype): Call it for character result lengths.
> * symbol.c (gfc_new_symbol): Set fn_result_spec to zero.
> * trans-decl.c (gfc_sym_mangled_identifier): Include the
> procedure name in the mangled name for symbols with the
> fn_result_spec bit set.
> (gfc_get_symbol_decl): Mangle the name of these symbols.
> (gfc_create_module_variable): Allow them through the assert.
> (gfc_generate_function_code): Remove the assert before the
> initialization of sym->tlink because the frontend no longer
> uses this field.
> * trans-expr.c (gfc_map_intrinsic_function): Add a case to
> treat the LEN_TRIM intrinsic.
>
> 2016-11-09 Paul Thomas <pault@gcc.gnu.org>
>
> PR fortran/44265
> * gfortran.dg/char_result_14.f90: New test.
> * gfortran.dg/char_result_15.f90: New test.
>
>
> --
> The difference between genius and stupidity is; genius has its limits.
>
> Albert Einstein
> <submit.diff>