public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: acsawdey--- via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: acsawdey@linux.ibm.com, jakub@redhat.com,
	segher@kernel.crashing.org, wschmidt@linux.ibm.com
Subject: Re: [PATCH] Additional small changes to support opaque modes
Date: Fri, 20 Nov 2020 09:55:12 +0000	[thread overview]
Message-ID: <mpt5z60mjy7.fsf@arm.com> (raw)
In-Reply-To: <20201120005758.1769223-1-acsawdey@linux.ibm.com> (acsawdey's message of "Thu, 19 Nov 2020 18:57:58 -0600")

acsawdey--- via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> diff --git a/gcc/c/c-aux-info.c b/gcc/c/c-aux-info.c
> index ffc8099856d..41f5598de38 100644
> --- a/gcc/c/c-aux-info.c
> +++ b/gcc/c/c-aux-info.c
> @@ -413,6 +413,10 @@ gen_type (const char *ret_val, tree t, formals_style style)
>  	  data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t)));
>  	  break;
>  
> +	case OPAQUE_TYPE:
> +	  data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t)));
> +	  break;
> +

Might as well just add this case to the REAL_TYPE one.

>  	case VOID_TYPE:
>  	  data_type = "void";
>  	  break;
> […]
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 54eb445665c..d6d12efff34 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -13037,6 +13037,7 @@ is_base_type (tree type)
>        return 1;
>  
>      case VOID_TYPE:
> +    case OPAQUE_TYPE:
>      case ARRAY_TYPE:
>      case RECORD_TYPE:
>      case UNION_TYPE:
> @@ -16767,7 +16768,7 @@ loc_descriptor (rtx rtl, machine_mode mode,
>        break;
>  
>      case CONST_INT:
> -      if (mode != VOIDmode && mode != BLKmode)
> +      if (mode != VOIDmode && mode != BLKmode && !OPAQUE_MODE_P (mode))
>  	{
>  	  int_mode = as_a <scalar_int_mode> (mode);
>  	  loc_result = address_of_int_loc_descriptor (GET_MODE_SIZE (int_mode),

I realise I'm asking this about something that already appears to handle
BLKmode CONST_INTs (?!), but this is the one change in the patch I
struggled with.  Why do we see a CONST_INT that allegedly has an
opaque mode?  It feels like something has gone wrong further up the
call chain.

This might still be the expedient fix for whatever is happening,
but I think it deserves a comment at least.

The rest looks good to me FWIW.

Richard

  reply	other threads:[~2020-11-20  9:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20  0:57 acsawdey
2020-11-20  9:55 ` Richard Sandiford [this message]
2020-11-20 10:57   ` Aaron Sawdey
2020-11-20 21:49     ` Aaron Sawdey
2020-11-23  9:19       ` Richard Sandiford
2020-11-20  1:04 acsawdey

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=mpt5z60mjy7.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=acsawdey@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=segher@kernel.crashing.org \
    --cc=wschmidt@linux.ibm.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).