[Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Paul Richard Thomas]

Dear All,

Following a discussion on #gfortran with Andre and Dominique the patch
has been committed without char_result_[16,17].f90 as revision 243478.

This has been one of the most ill-starred of any patch that I have
submitted. At the last moment, I found that char_result_14.f90 was
suffering from excess errors due to the introduction of
Wstringop-overflow at -O3. The odd thing is that this warning is not
explicitly available to fortran so it cannot be switched off. I
introduced this chunk to fix it:

*************** gfc_trans_string_copy (stmtblock_t * blo
*** 6484,6493 ****
                    builtin_decl_explicit (BUILT_IN_MEMMOVE),
                    3, dest, src, slen);

    tmp4 = fold_build_pointer_plus_loc (input_location, dest, slen);
!   tmp4 = fill_with_spaces (tmp4, chartype,
!                fold_build2_loc (input_location, MINUS_EXPR,
!                         TREE_TYPE(dlen), dlen, slen));

    gfc_init_block (&tempblock);
    gfc_add_expr_to_block (&tempblock, tmp3);
--- 6494,6511 ----
                    builtin_decl_explicit (BUILT_IN_MEMMOVE),
                    3, dest, src, slen);

+   /* Wstringop-overflow appears at -O3 even though this warning is not
+      explicitly available in fortran nor can it be switched off. If the
+      source length is a constant, its negative appears as a very large
+      postive number and triggers the warning in BUILTIN_MEMSET. Fixing
+      the result of the MINUS_EXPR suppresses this spurious warning.  */
+   tmp = fold_build2_loc (input_location, MINUS_EXPR,
+              TREE_TYPE(dlen), dlen, slen);
+   if (slength && TREE_CONSTANT (slength))
+     tmp = gfc_evaluate_now (tmp, block);
+
    tmp4 = fold_build_pointer_plus_loc (input_location, dest, slen);
!   tmp4 = fill_with_spaces (tmp4, chartype, tmp);

    gfc_init_block (&tempblock);
    gfc_add_expr_to_block (&tempblock, tmp3);

I am changing the PR to reflect the continuing problem with Darwin.

Cheers

Paul


On 7 December 2016 at 22:50, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
> When you can narrow it down to only failing on Darwin, then filter the testcases not to run on that system.
>
> - Andre
>
> Am 7. Dezember 2016 22:44:15 MEZ, schrieb Paul Richard Thomas <paul.richard.thomas@gmail.com>:
>>Dear Dominique,
>>
>>Thanks for the feedback. However, I don't know what to do about it.
>>Perhaps I should commit the patch without char_result_[16,17].f90 and
>>pass it on to somebody who is a bit more conversent with these issues?
>>As far as I am concerned, it is fixed on Linux.
>>
>>Any ideas anybody?
>>
>>Paul
>>
>>On 7 December 2016 at 20:11, Dominique d'Humières <dominiq@lps.ens.fr>
>>wrote:
>>> The tests gfortran.dg/char_result_16.f90 and
>>gfortran.dg/char_result_17.f90 fail with
>>>
>>> lto1: error: two or more sections for
>>.gnu.lto___get_PROC_names.3e3ee55b08747e7c
>>> lto1: internal compiler error: cannot read LTO decls from
>>/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccEJosbA.o
>>>
>>> This may be darwin specific as the linker is more picky than the
>>linux one.
>>>
>>> Dominique
>>>
>>>> Le 7 déc. 2016 à 16:47, Paul Richard Thomas
>><paul.richard.thomas@gmail.com> a écrit :
>>>>
>>>> Dear Dominique,
>>>>
>>>> I will turn to the effect on PR77414 after committing the patch for
>>PR44265.
>>>>
>>>> The attached fixes the -flto problem. The chunk in
>>>> trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious
>>now
>>>> and, in fact, I am a bit surprised that the patch worked at all
>>>> without the DECL_EXTERNAL.
>>>>
>>>> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
>>>>
>>>> Paul
>>>>
>>>> 2016-12-07  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_finish_var_decl): Mark the decls of these symbols
>>>>    appropriately for the case where the function is external.
>>>>    (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-12-07  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.
>>>>    * gfortran.dg/char_result_16.f90: New test.
>>>>    * gfortran.dg/char_result_17.f90: New test.
>>>>
>>>>
>>>
>
> --
> Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
> Tel.: +49 241 929 10 18 * vehre@gmx.de



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama