From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>,
Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] Fix expand_assignment with complex modes with the same size but different inner mode (PR middle-end/82253)
Date: Wed, 22 Nov 2017 21:05:00 -0000 [thread overview]
Message-ID: <20171122210148.GD14653@tucnak> (raw)
Hi!
store_expr which is called if to_rtx is a CONCAT and from has complex mode
covering the whole to_rtx can handle the case when from expands to a CONCAT
or if it has the same complex mode, but if e.g. one mode is CTImode and
the other mode is TCmode and from expands to something other than a CONCAT
(e.g. a MEM, not sure if anything else is possible, perhaps a constant),
then convert_mode can't deal with it. We already have code to handle the
case when to_rtx is CONCAT and from covers all its bits, so this patch
just uses that code if the complex modes are different.
simplify_gen_subreg doesn't work properly if from would expand as a CONCAT
though, so I'm subregging the individual parts instead in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-11-22 Jakub Jelinek <jakub@redhat.com>
PR middle-end/82253
* expr.c (expand_assignment): For CONCAT to_rtx, complex type from and
bitpos/bitsize covering the whole destination, use store_expr only if
the complex mode is the same. Otherwise, use expand_normal and if
it returns CONCAT, subreg each part separately instead of trying to
subreg the whole result.
* gfortran.dg/pr82253.f90: New test.
--- gcc/expr.c.jj 2017-11-21 20:23:02.000000000 +0100
+++ gcc/expr.c 2017-11-22 18:31:57.513726153 +0100
@@ -5107,7 +5107,8 @@ expand_assignment (tree to, tree from, b
else if (GET_CODE (to_rtx) == CONCAT)
{
unsigned short mode_bitsize = GET_MODE_BITSIZE (GET_MODE (to_rtx));
- if (COMPLEX_MODE_P (TYPE_MODE (TREE_TYPE (from)))
+ if (TYPE_MODE (TREE_TYPE (from)) == GET_MODE (to_rtx)
+ && COMPLEX_MODE_P (GET_MODE (to_rtx))
&& bitpos == 0
&& bitsize == mode_bitsize)
result = store_expr (from, to_rtx, false, nontemporal, reversep);
@@ -5128,14 +5129,30 @@ expand_assignment (tree to, tree from, b
nontemporal, reversep);
else if (bitpos == 0 && bitsize == mode_bitsize)
{
- rtx from_rtx;
result = expand_normal (from);
- from_rtx = simplify_gen_subreg (GET_MODE (to_rtx), result,
- TYPE_MODE (TREE_TYPE (from)), 0);
- emit_move_insn (XEXP (to_rtx, 0),
- read_complex_part (from_rtx, false));
- emit_move_insn (XEXP (to_rtx, 1),
- read_complex_part (from_rtx, true));
+ if (GET_CODE (result) == CONCAT)
+ {
+ machine_mode to_mode = GET_MODE_INNER (GET_MODE (to_rtx));
+ machine_mode from_mode = GET_MODE_INNER (GET_MODE (result));
+ rtx from_real
+ = simplify_gen_subreg (to_mode, XEXP (result, 0),
+ from_mode, 0);
+ rtx from_imag
+ = simplify_gen_subreg (to_mode, XEXP (result, 1),
+ from_mode, 1);
+ emit_move_insn (XEXP (to_rtx, 0), from_real);
+ emit_move_insn (XEXP (to_rtx, 1), from_imag);
+ }
+ else
+ {
+ rtx from_rtx
+ = simplify_gen_subreg (GET_MODE (to_rtx), result,
+ TYPE_MODE (TREE_TYPE (from)), 0);
+ emit_move_insn (XEXP (to_rtx, 0),
+ read_complex_part (from_rtx, false));
+ emit_move_insn (XEXP (to_rtx, 1),
+ read_complex_part (from_rtx, true));
+ }
}
else
{
--- gcc/testsuite/gfortran.dg/pr82253.f90.jj 2017-11-22 18:41:33.421850619 +0100
+++ gcc/testsuite/gfortran.dg/pr82253.f90 2017-11-22 18:41:18.000000000 +0100
@@ -0,0 +1,40 @@
+! PR middle-end/82253
+! { dg-do compile { target fortran_real_16 } }
+! { dg-options "-Og" }
+
+module pr82253
+ implicit none
+ private
+ public :: static_type
+ type, public :: T
+ procedure(), nopass, pointer :: testProc => null()
+ end type
+ type, public :: S
+ complex(kind=16), pointer :: ptr
+ end type
+ type(T), target :: type_complex32
+ interface static_type
+ module procedure foo
+ end interface
+ interface
+ subroutine bar (testProc)
+ procedure(), optional :: testProc
+ end subroutine
+ end interface
+ contains
+ function foo (self) result(res)
+ complex(kind=16) :: self
+ type(T), pointer :: res
+ call bar (testProc = baz)
+ end function
+ subroutine baz (buffer, status)
+ character(len=*) :: buffer
+ integer(kind=4) :: status
+ complex(kind=16), target :: obj
+ type(S) :: self
+ integer(kind=1), parameter :: zero(storage_size(obj)/8) = 0
+ obj = transfer (zero, obj)
+ self%ptr => obj
+ write (buffer, *, iostat=status) self%ptr, '#'
+ end subroutine
+end module pr82253
Jakub
next reply other threads:[~2017-11-22 21:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-22 21:05 Jakub Jelinek [this message]
2017-11-23 9:03 ` Richard Biener
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=20171122210148.GD14653@tucnak \
--to=jakub@redhat.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).