https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> if (sym->formal_ns
> + && sym->attr.proc != PROC_INTRINSIC // temporary hack
I am afraid that this might break
/usr/include/finclude/math-vector-fortran.h
which contains lines like:
!GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')
!GCC$ builtin (cosf) attributes simd (notinbranch) if('x86_64')
albeit I don't know whether this code is reached for such builtins or not.
* * *
In general, I think gfortran doesn't do the best job in creating
good/consistent declarations. - Thus, create_function_arglist doesn't really
sound wrong,
but I have to think about whether it is needed for gfc_get_extern_function_decl
and, if it should be added, how it should be fixed.
* * *
The function decl itself looks fine. For a string, in create_function_arglist,
there is:
2677 if (sym->ts.type == BT_CHARACTER)
2678 {
2679 /* Length of character result. */
2680 tree len_type = TREE_VALUE (TREE_CHAIN (typelist));
2681
2682 length = build_decl (input_location,
2683 PARM_DECL,
2684 get_identifier (".__result"),
2685 len_type);
…
2693 sym->ts.u.cl->backend_decl = length;
where the LHS has the value:
<parm_decl 0x7ffff720dbb0 _s
and the RHS is
<parm_decl 0x7ffff720de58 .__result
That is: the LHS is the the charcter-length hidden dummy argument '_s' of 'sub'
while the RHS defines a new function-result dummy argument '.result' for the
function '_gfortran_pack_char'.
So far that looks good - but my feeling is that sub's
'_s'->ts.u.cl->backend_decl and '.__result'->ts.u.cl->backend_decl. - And,
indeed,
when looking in gfc_conv_procedure_call for the call:
_gfortran_pack_char[[((sub:s(:)) (mask = __convert_l4_l1[[(((parens (/=
sub:s(:) ''))))]]) ((arg not-present)))]]
NOTE: '_gfortran_pack_char' is an actual libgfortran library routine!
We have as first argument:
sub:s(:)
with:
(gdb) p debug_tree(expr->value.function->actual->expr->ts.u.cl->backend_decl)
<parm_decl 0x7ffff720de58 .__result
The call itself looks fine:
_gfortran_pack_char (&atmp.10, _s, D.4852, D.4870, 0B, _s, 0)
But after the call, we get the wrong string length in the scalarization loop:
D.4897 = .__result;
* * *
Thus, the question is why is 'ts.u.cl' shared - and whether it should be shared
(and then shouldn't be overwritten) or not.
