public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch, fortran] PR69834 - Collision in derived type hashes
Date: Sun, 23 Oct 2016 18:14:00 -0000	[thread overview]
Message-ID: <20161023144553.61c78130@vepi2> (raw)
In-Reply-To: <CAGkQGi+S-4qf+ifgVvKHRu=TEj4pRmMCCJrLxBJOLoZDZ1QP2Q@mail.gmail.com>

Hi Paul,

here are my comments to your patch:

> Index: gcc/fortran/class.c
> ===================================================================
> *** gcc/fortran/class.c (revision 241439)
> --- gcc/fortran/class.c (working copy)
> *************** add_procs_to_declared_vtab (gfc_symbol *
> --- 2187,2219 ----
>   gfc_symbol *
>   gfc_find_derived_vtab (gfc_symbol *derived)
>   {
> !   gfc_namespace *ns = NULL;

Setting this to NULL for consistency?

> Index: gcc/fortran/dump-parse-tree.c
> ===================================================================
> *** gcc/fortran/dump-parse-tree.c       (revision 241439)
> --- gcc/fortran/dump-parse-tree.c       (working copy)
> *************** show_code_node (int level, gfc_code *c)
> *** 1843,1848 ****
> --- 1843,1877 ----

Well, the code in this chunk is identical to the one of EXEC_SELECT, besides
two lines where the statement's name is printed. I propose to do something like:

case EXEC_SELECT:
case EXEC_SELECT_TYPE:
  d= ..
  fputs ("SELECT", dumpfile);
  if (c->op == EXEC_SELECT_TYPE)
    fputs (" TYPE", dumpfile);
 ...
  // and the same for "END SELECT..."

This would reduce the amount of copied code. An improvement in one
EXEC_SELECT-dump-handler would then automagically available in the other, too.

> Index: gcc/fortran/resolve.c
> ===================================================================
> *** gcc/fortran/resolve.c       (revision 241439)
> --- gcc/fortran/resolve.c       (working copy)
<snipp>
> *************** resolve_select_type (gfc_code *code, gfc
<snipp>
> --- 8595,8641 ----
>     else
>       ns->code->next = new_st;
>     code = new_st;
> !   code->op = EXEC_SELECT_TYPE;
> 
> +   /* Use the intrinsic LOC function to generate the an integer expression
> +      for the vtable of the selector.  Note that the rank of the selector
> +      expression has to be set to zero.  */

double article:                                    _the an_  !!!

> Index: gcc/fortran/trans-stmt.c
> ===================================================================
> *** gcc/fortran/trans-stmt.c    (revision 241439)
> --- gcc/fortran/trans-stmt.c    (working copy)
> *************** gfc_trans_do_while (gfc_code * code)
> *** 2331,2336 ****
> --- 2331,2455 ----
<snipp>
> +
> +   /* Translate an assignment to a CLASS object
> +      (pointer or ordinary assignment).  */
> +
> +

Here is no routine the above comment could document. Left over from prior
version?

>   /* End of prototype trans-class.c  */


> Index: gcc/fortran/trans-stmt.c
> ===================================================================
> *** gcc/fortran/trans-stmt.c    (revision 241439)
> --- gcc/fortran/trans-stmt.c    (working copy)
> *************** gfc_trans_do_while (gfc_code * code)
> *** 2331,2336 ****
> --- 2331,2455 ----

Can one optimize this by using the "old style" for intrinsic types, i.e. a
computed goto (switch-case) for them? And in the default case the if-chain on
the derived types/classes? Would we gain any speed by this? What is your
opinion on this?

> Please find attached a revised version of the patch that corrects one
> or two tiny wrinkles. I have removed the tidy up of vtable retrieval

I haven't understood yet, what you need to do for this. Looking forward to that
patch.

With the above small changes the patch is ok for trunk given that Dominique
doesn't find any issues.

Beware, that my big patch on polymorphic assignment will *not* be backported
to gcc-6. I.e., this version of your patch will most probably not be applyable.
You rather will need to apply the old version.

Thanks for the work.

Regards,
	Andre

> Functionally, the patch is as described in the original submission.
> 
> As attached, it bootstraps and regtests on FC21/x86_64.  OK for trunk
> and, after a decent interval for 6-branch?
> 
> Cheers
> 
> Paul
> 
> 2016-10-22  Paul Thomas  <pault@gcc.gnu.org>
> 
>     PR fortran/69834
>     * class.c (gfc_find_derived_vtab): Obtain the gsymbol for the
>     derived type's module. If the gsymbol is present and the top
>     level namespace corresponds to a module, use the gsymbol name
>     space. In the search to see if the vtable exists, try the gsym
>     namespace first.
>     * dump-parse-tree (show_code_node): Add explicit dump for the
>     select type construct.
>     * resolve.c (build_loc_call): New function.
>     (resolve_select_type): Add check for repeated type is cases.
>     Retain selector expression and use it later instead of expr1.
>     Exclude deferred length TYPE IS cases and emit error message.
>     Store the address for the vtable in the 'low' expression and
>     the hash value in the 'high' expression, for each case. Do not
>     call resolve_select.
>     * trans.c(trans_code) : Call gfc_trans_select_type.
>     * trans-stmt.c (gfc_trans_select_type_cases): New function.
>     (gfc_trans_select_type): New function.
>     * trans-stmt.h : Add prototype for gfc_trans_select_type.
> 
> 2016-10-22  Paul Thomas  <pault@gcc.gnu.org>
> 
>     PR fortran/69834
>     * gfortran.dg/select_type_1.f03: Change error for overlapping
>     TYPE IS cases.
>     * gfortran.dg/select_type_36.f03: New test.


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

       reply	other threads:[~2016-10-23 12:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGkQGi+S-4qf+ifgVvKHRu=TEj4pRmMCCJrLxBJOLoZDZ1QP2Q@mail.gmail.com>
2016-10-23 18:14 ` Andre Vehreschild [this message]
2016-10-23 21:30   ` Paul Richard Thomas
2016-10-24 10:18     ` Andre Vehreschild
2016-10-24 11:53       ` Paul Richard Thomas
2016-11-05 10:51         ` Paul Richard Thomas
2016-11-05 14:24 Dominique d'Humières
2016-11-05 14:55 ` Janus Weil
     [not found] <F8D03D98-0E54-4994-B7D4-23E757BE9A08@lps.ens.fr>
2016-10-22  8:21 ` Paul Richard Thomas
2016-10-22  8:51   ` Dominique d'Humières
2016-10-22 10:41     ` Paul Richard Thomas
  -- strict thread matches above, loose matches on Subject: below --
2016-10-21 12:52 Paul Richard Thomas
2016-09-27  8:27 Paul Richard Thomas
2016-09-27 12:42 ` Paul Richard Thomas
2016-03-03 15:59 Paul Richard Thomas
2016-03-03 20:31 ` Jerry DeLisle
2016-03-13 17:31   ` Paul Richard Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161023144553.61c78130@vepi2 \
    --to=vehre@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=paul.richard.thomas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).