public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/102708] New: Improve ''array temporary was created for argument" diagnostic
@ 2021-10-12 15:00 burnus at gcc dot gnu.org
  2021-10-14  9:49 ` [Bug fortran/102708] " burnus at gcc dot gnu.org
  2022-01-06  1:21 ` sandra at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-10-12 15:00 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708

            Bug ID: 102708
           Summary: Improve ''array temporary was created for argument"
                    diagnostic
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The message is produced by gfc_conv_subref_array_arg when called with:

      if (fsym && proc_name)
        msg = xasprintf ("An array temporary was created for argument "
                             "'%s' of procedure '%s'", fsym->name, proc_name);
      else
        msg = xasprintf ("An array temporary was created");

obviously the message is clearer when fsym + proc_name is available. However,
in gfc_conv_procedure_call those aren't passed.


Probably, it would be useful to have additionally the name of the calling
procedure, e.g.

"An array temporary was created in procedure '%s' for argument '%s' of
procedure '%s'"


Note: I also use it in my gfc_conv_gfc_desc_to_cfi_desc (submitted but
unreviewed patch); thus that one should then also have the better diagnostic.
(It already has the %s of proc %s diagnostic.)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic
  2021-10-12 15:00 [Bug fortran/102708] New: Improve ''array temporary was created for argument" diagnostic burnus at gcc dot gnu.org
@ 2021-10-14  9:49 ` burnus at gcc dot gnu.org
  2022-01-06  1:21 ` sandra at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-10-14  9:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Actually, it prints the line number at the call site. Thus, there is probably
no need for adding the name of callee.

However, related to the fsym/proc_name passing:

Currently, the callers in gfc_conv_procedure_call do not make use of the
avoid-copy-in feature by not passing the (add) contiguous (check) = true flag
to gfc_conv_subref_array_arg.

There are some testcase which check that the copyin does not happen when being
contiguous, but I think those are not used for dummy arguments that are
(CONTIGUOUS) assumed-shape/assumed-rank arrays.

Side note: To get that working, it requires the gfc_conv_subref_array_arg
changes of the patch at
  https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.html
which might be the reason for not doing it currently.

 * * *

Another observation, which might be unrelated or related: TRANSFORM can be
implemented by just swapping the first and second dimension (see
trans-intrinsic.s + trans-array.c, search for ISYM_TRANSFORM).

Currently, GCC for a call makes it contiguous – which it could be also
transferred as is (noncontiguous). I am not sure what's better, though.

Testcase: gfortran.dg/c-interop/fc-descriptor-7.f90 also part of the patch 
  https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.html
Search for the comments regarding the implementation choice.

As testing shows, calling a Fortran procedure does the copy in (as mentioned)
but with my patch, calling a BIND(C) procedure passes the array as
noncontiguous array.
Thus, I wonder whether it is also related to the gfc_conv_subref_array_arg.

 * * *

gfc_conv_subref_array_arg: While the above mentioned patch adds support for a
contiguous check with descriptors, I lack an optional + contiguous check
testcase.

However, that can only be added once gfc_conv_subref_array_arg is called with
contiguous=true - or in any other way with type = descriptor type.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic
  2021-10-12 15:00 [Bug fortran/102708] New: Improve ''array temporary was created for argument" diagnostic burnus at gcc dot gnu.org
  2021-10-14  9:49 ` [Bug fortran/102708] " burnus at gcc dot gnu.org
@ 2022-01-06  1:21 ` sandra at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: sandra at gcc dot gnu.org @ 2022-01-06  1:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708

sandra at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I fixed a lot of bugs with creating excessive temporaries for calls to bind(c)
functions in my fix for PR 103390 (commit
6447f6f983ffeaecb8753ef685d702bf2594968b).  I'm not sure if there is more to do
there or not, but it seems unrelated to the original problem.  If there's a
bug, it ought to be in its own issue.

IIUC what needs to be done for the original problem is fixing (all?) the calls
to gfc_conv_subref_array_arg to pass the fsym and proc_name arguments.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-01-06  1:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-12 15:00 [Bug fortran/102708] New: Improve ''array temporary was created for argument" diagnostic burnus at gcc dot gnu.org
2021-10-14  9:49 ` [Bug fortran/102708] " burnus at gcc dot gnu.org
2022-01-06  1:21 ` sandra at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).