public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Antoni Boucher <bouanto@zoho.com>
To: jit@gcc.gnu.org, gcc-patches@gcc.gnu.org
Cc: David Malcolm <dmalcolm@redhat.com>
Subject: [PATCH] libgccjit: Fix get_size of size_t
Date: Thu, 07 Dec 2023 17:26:01 -0500	[thread overview]
Message-ID: <295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com> (raw)

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

Hi.
This patch fixes getting the size of size_t (bug 112910).

There's one issue with this patch: like every other feature that checks
for target-specific stuff, it requires a compilation before actually
fetching the size of the type.
Which means that getting the size before a compilation might be wrong
(and I actually believe is wrong on x86-64).

I was wondering if we should always implicitely do the first
compilation to gather the correct info: this would fix this issue and
all the others that we have due to that.
I'm not sure what would be the performance implication.

Another solution that I have been thinking about for a while now would
be to have another frontend libgccaot (I don't like that name), which
is like libgccjit but removes the JIT part so that we get access to the
target stuff directly and would remove the need for having a seperation
between recording and playback as far as I understand.
That's a long-term solution, but I wanted to share the idea now and
gather your thoughts on that.

Thanks for the review.

[-- Attachment #2: 0001-libgccjit-Fix-get_size-of-size_t.patch --]
[-- Type: text/x-patch, Size: 1911 bytes --]

From 37d25e55a0c79893c7ea7f4cb9f0842b8a9b4906 Mon Sep 17 00:00:00 2001
From: Antoni Boucher <bouanto@zoho.com>
Date: Fri, 3 Nov 2023 17:49:18 -0400
Subject: [PATCH] libgccjit: Fix get_size of size_t

gcc/jit/ChangeLog:
	PR jit/112910
	* jit-recording.cc (recording::memento_of_get_type::get_size):
	Correctly compute the size of size_t.
---
 gcc/jit/jit-recording.cc | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..ea1f76d4415 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -2392,7 +2392,34 @@ recording::memento_of_get_type::get_size ()
       size = LONG_DOUBLE_TYPE_SIZE;
       break;
     case GCC_JIT_TYPE_SIZE_T:
-      size = MAX_BITS_PER_WORD;
+      /* Compare with tree.cc's build_common_tree_nodes.  */
+      if (strcmp (SIZE_TYPE, "unsigned int") == 0)
+        size = INT_TYPE_SIZE;
+      else if (strcmp (SIZE_TYPE, "long unsigned int") == 0)
+        size = LONG_TYPE_SIZE;
+      else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0)
+        size = LONG_LONG_TYPE_SIZE;
+      else if (strcmp (SIZE_TYPE, "short unsigned int") == 0)
+        size = SHORT_TYPE_SIZE;
+      else
+      {
+        int i;
+
+        for (i = 0; i < NUM_INT_N_ENTS; i++)
+          if (int_n_enabled_p[i])
+          {
+            fprintf (stderr, "%d\n", i);
+            char name[50], altname[50];
+            sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
+            sprintf (altname, "__int%d__ unsigned", int_n_data[i].bitsize);
+
+            if (strcmp (name, SIZE_TYPE) == 0 || strcmp (altname, SIZE_TYPE) == 0)
+            {
+              return int_n_data[i].bitsize / BITS_PER_UNIT;
+            }
+          }
+        gcc_unreachable ();
+      }
       break;
     default:
       /* As this function is called by
-- 
2.43.0


             reply	other threads:[~2023-12-07 22:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 22:26 Antoni Boucher [this message]
2023-12-08  0:57 ` David Malcolm
2024-02-21 19:16   ` Antoni Boucher
2024-06-26 22:01     ` David Malcolm
2024-06-28  0:49       ` Antoni Boucher

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=295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com \
    --to=bouanto@zoho.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@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).