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 <ve...@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.tho...@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 <domi...@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.tho...@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 <pa...@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 <pa...@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 * ve...@gmx.de
--
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.
Barack Obama
