public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Richard Thomas <paul.richard.thomas@gmail.com>
To: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE
Date: Wed, 17 Oct 2018 10:33:00 -0000	[thread overview]
Message-ID: <CAGkQGi+Rq08DYLx8C2yXjUX8m2-3NUuMjtpExrbWdpb3anEF=w@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

This problem concerned associate targets being substrings. It turns
out that they are returned as pointer types (with a different cast for
unity based substrings ***sigh***) and so can be assigned directly to
the associate name. The patch quite simply removed the condition that
such targets be allocatable, pointer or dummy.

I noticed in the course of working up the testcase that
    character (:), pointer :: ptr => NULL()
    character (6), target :: tgt = 'lmnopq'
    ptr => tgt
    print *, len (ptr), ptr
end
ICEs on the NULL initialization of the pointer but works fine if this
is removed. Has this already been posted as a PR?

Bootstrapped and regtested on FC28/x86_64 - OK for trunk?

Paul

2018-10-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58618
    * trans-stmt.c (trans_associate_var): All strings that return
    as pointer types can be assigned directly to the associate
    name so remove 'attr' and the condition that uses it.

2018-10-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/58618
    * gfortran.dg/associate_45.f90 : New test.

[-- Attachment #2: submit.diff --]
[-- Type: text/x-patch, Size: 2616 bytes --]

Index: gcc/fortran/trans-stmt.c
===================================================================
*** gcc/fortran/trans-stmt.c	(revision 265231)
--- gcc/fortran/trans-stmt.c	(working copy)
*************** trans_associate_var (gfc_symbol *sym, gf
*** 1656,1662 ****
    bool need_len_assign;
    bool whole_array = true;
    gfc_ref *ref;
-   symbol_attribute attr;
  
    gcc_assert (sym->assoc);
    e = sym->assoc->target;
--- 1656,1661 ----
*************** trans_associate_var (gfc_symbol *sym, gf
*** 1916,1924 ****
  	    }
  	}
  
-       attr = gfc_expr_attr (e);
        if (sym->ts.type == BT_CHARACTER && e->ts.type == BT_CHARACTER
- 	  && (attr.allocatable || attr.pointer || attr.dummy)
  	  && POINTER_TYPE_P (TREE_TYPE (se.expr)))
  	{
  	  /* These are pointer types already.  */
--- 1915,1921 ----
*************** trans_associate_var (gfc_symbol *sym, gf
*** 1926,1933 ****
  	}
        else
  	{
!           tmp = TREE_TYPE (sym->backend_decl);
!           tmp = gfc_build_addr_expr (tmp, se.expr);
  	}
  
        gfc_add_modify (&se.pre, sym->backend_decl, tmp);
--- 1923,1930 ----
  	}
        else
  	{
! 	  tmp = TREE_TYPE (sym->backend_decl);
! 	  tmp = gfc_build_addr_expr (tmp, se.expr);
  	}
  
        gfc_add_modify (&se.pre, sym->backend_decl, tmp);
Index: gcc/testsuite/gfortran.dg/associate_45.f90
===================================================================
*** gcc/testsuite/gfortran.dg/associate_45.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/associate_45.f90	(working copy)
***************
*** 0 ****
--- 1,38 ----
+ ! { dg-do run }
+ !
+ ! Test the fix for PR58618 by checking that substring associate targets
+ ! work correctly.
+ !
+ ! Contributed by Vladimir Fuka  <vladimir.fuka@gmail.com>
+ !
+     character(5) :: s(2) = ['abcde','fghij']
+     character (6), pointer :: ptr => NULL()
+     character (6), target :: tgt = 'lmnopq'
+ 
+     associate (x=>s(2)(3:4))
+       if (x .ne. 'hi') stop 1
+       x = 'uv'
+     end associate
+     if (any (s .ne. ['abcde','fguvj'])) stop 2
+ 
+ ! Unity based substrings are cast differently.  */
+     associate (x=>s(1)(1:4))
+       if (x .ne. 'abcd') stop 3
+       x(2:3) = 'wx'
+     end associate
+     if (any (s .ne. ['awxde','fguvj'])) stop 4
+ 
+ ! Make sure that possible misidentifications do not occur.
+     ptr => tgt
+     associate (x=>ptr)
+       if (x .ne. 'lmnopq') stop 5
+       x(2:3) = 'wx'
+     end associate
+     if (tgt .ne. 'lwxopq') stop 6
+ 
+     associate (x=>ptr(5:6))
+       if (x .ne. 'pq') stop 7
+       x = 'wx'
+     end associate
+     if (tgt .ne. 'lwxowx') stop 8
+   end

             reply	other threads:[~2018-10-17 10:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17 10:33 Paul Richard Thomas [this message]
2018-10-17 21:17 ` Tobias Burnus
2018-10-18 10:10   ` Paul Richard Thomas
2018-10-18 10:39   ` 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='CAGkQGi+Rq08DYLx8C2yXjUX8m2-3NUuMjtpExrbWdpb3anEF=w@mail.gmail.com' \
    --to=paul.richard.thomas@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /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).