Message ID | ZcX0CqFApBBo4zwD@tucnak |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp736775dyd; Fri, 9 Feb 2024 01:45:38 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUFeH7v4gt2Tq0w6Vb+RecZThvCrdZj+40UNtHxX0enFTRFoQfhIufTOMw8BZICtavO6OegR1VHEw9qkX29KtiN1YNJjw== X-Google-Smtp-Source: AGHT+IGF8aVSVWFK10LVwNoHe+/BZhiYR1+SqhIp6zKNYsxQ9esTqE69N0pvNTli98u1HJDePhEQ X-Received: by 2002:a0c:f305:0:b0:68c:a6ab:19ba with SMTP id j5-20020a0cf305000000b0068ca6ab19bamr944257qvl.16.1707471938613; Fri, 09 Feb 2024 01:45:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707471938; cv=pass; d=google.com; s=arc-20160816; b=qKGiy08Ma9icf+T0pxPu09L4oT0rp9vjBfX4FK689Yj/sMrBjvjkL2rWUElVWmDAzR ABJE43WeXclNwh35rwD1jOYLNZVv/v1WAr5GaWXDKjDXpslWwWO10ss/pEfBWYLXMAiu Kp/Ss+/quQfxlih5kDpSqgZBOo2NAB9EP5/uQcTRL+4Vxc5irkFUoeBkL6i0j6Ud69QX sR5LeQ7HUusk+/lVJENeVUaKm73SSf+uTGQtTblBJshbWEBWzYVfCV5CohsWrJRjOWQw vswFmIcS8GpzzzU/ubdTopPyvWjrOHd0Qo6y9P7PxnmHI26hsG9an+FnJOFCicPMoTAf Go3w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:reply-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :arc-filter:dmarc-filter:delivered-to; bh=KTownOenqXEvA7GNrc3HzzgyUYyIRCc22QmtTn5AAFw=; fh=CnxHOjW28NgmvdLggyjS0r+cV4HofFTmsKufRsOWxwU=; b=Y35E1TEG/8JG8nL0pk4N301INNhgj0Ze+UAW4wha/3JHT3uArmJVzh0bJ/U88F/qwK bXLDClJjUsUHfiF3SB+9QjAnE4HNm93qm4BSO5QKsAUlTNO4Pwr0UjuUhj/H0gpIuRXi 3eI8KumQ9uXFoISFqgTOdK6PxMY/qVAM6v7Q3G126iSiAdpiIzkyD34Mkl9h3J0a1lHR gnBapBfQW/Bh01rYZdxC6OnGabuNE5lOrmLYXoV3LD68yVeoUy+fklh0zSx4xK+j5N72 ZpkPiiwCuA3s5MqHEYRwEmaxdnayL5ArGGeu/1/qW46Brt+EN/cCTaLQ40YsfE95B48m NsqQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hNbozL51; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Forwarded-Encrypted: i=2; AJvYcCU0gu2u1C1URkuTxSSMjtWFeUP5L4vOfKdZpVpzBYMSog5iUcCCJ0v8RUsHtxLMFZPKAW52P3Av+5VZ57D3AU2ZT4c9hg== Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id iy8-20020a0562140f6800b006852904842csi1724731qvb.276.2024.02.09.01.45.38 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 01:45:38 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hNbozL51; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4BF383858404 for <ouuuleilei@gmail.com>; Fri, 9 Feb 2024 09:45:38 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B50913858C35 for <gcc-patches@gcc.gnu.org>; Fri, 9 Feb 2024 09:44:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B50913858C35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B50913858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707471890; cv=none; b=uB5xZjGcwkiKucQLM+IlAgvnQBuGy8NI7OFPiY2aYvqpCCr0NARVT2lJJmwi4JeJ1//09RFCjGiUPGNhuViWGtwFBzY2jAsZ1pNx/CyccHnDO/pRGdgX3KzBtasikfy5U6FNL8G/HHy4r0zf0TKSAE/wnJKbm7vL+zA+gbQ1GkM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707471890; c=relaxed/simple; bh=K931pRjNF0PbVcVKBdViZ99qEXiTZsHAOT0dEZEcg0M=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=kc1X8zP0EpCMdOUAshd6PKqSEQDKCC+EMJetmNsmdA5POXZ6VqeJD7/2oXMKtrV+dq8X9+RHtdnye5ZEt6cXMK4e91f50AeK9SZ7YC6LaDAnlNtkQc9T5AVdmlCi6TDV9xstUxC5wnl8WIKDAaJivEEDUkrKF49xy2DwRB5JMlg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707471888; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=KTownOenqXEvA7GNrc3HzzgyUYyIRCc22QmtTn5AAFw=; b=hNbozL51QwpsHhOnprv1sFUcMm6fVHqSeC7aD/TpbbR0ODsQ9M3s29/66tTk3szNUIYmzI CAKsCHcT6a43YcLsCMiwZ7bLP9aucFUKPioGgM19nezo8TXTGrdBz0uxxGpA8b3aX9X5X6 XBZrIeHTwxQA1hUxrmzu34AkVuhJtJk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-300-mD92JSQSOCO88eXyB4vrtA-1; Fri, 09 Feb 2024 04:44:46 -0500 X-MC-Unique: mD92JSQSOCO88eXyB4vrtA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 27E9A85A58C; Fri, 9 Feb 2024 09:44:46 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DFAAD2166B31; Fri, 9 Feb 2024 09:44:45 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4199ihFw640138 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 9 Feb 2024 10:44:43 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4199ig5x640137; Fri, 9 Feb 2024 10:44:42 +0100 Date: Fri, 9 Feb 2024 10:44:42 +0100 From: Jakub Jelinek <jakub@redhat.com> To: Richard Biener <rguenther@suse.de>, Jeff Law <jeffreyalaw@gmail.com>, Vladimir Makarov <vmakarov@redhat.com> Cc: gcc-patches@gcc.gnu.org Subject: Patch ping Message-ID: <ZcX0CqFApBBo4zwD@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790414095454432139 X-GMAIL-MSGID: 1790414095454432139 |
Series |
Patch ping
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Jakub Jelinek
Feb. 9, 2024, 9:44 a.m. UTC
Hi! I'd like to ping 2 patches: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html PR113617 P1 - Handle private COMDAT function symbol reference in readonly data section More details in the https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644121 and https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644486 threads. and https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue Both have been successfully bootstrapped/regtested on x86_64-linux and i686-linux, the latter has been tested by Jonathan on Windows too. The alternative is start using %zu (AFAIK we only do that in libgccjit which isn't supported everywhere and while it is C99, not sure if all supported host C libraries support it), or change ira-conflicts.cc to Note, we have many more cases where we use %ld or %lu to print size_t values (ideally %zd/%zu if we can assume it on all hosts, or with the above introduced HOST_SIZE_T_PRINT*, the problem with the %ld/%lu and casts is that it truncates the values on LLP64 hosts (aka %Windows). Jakub
Comments
On 2/9/24 02:44, Jakub Jelinek wrote: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html > Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue > > Both have been successfully bootstrapped/regtested on x86_64-linux and > i686-linux, the latter has been tested by Jonathan on Windows too. > The alternative is start using %zu (AFAIK we only do that in libgccjit which > isn't supported everywhere and while it is C99, not sure if all supported > host C libraries support it), or change ira-conflicts.cc to > --- gcc/ira-conflicts.cc 2024-02-01 21:03:57.339193085 +0100 > +++ gcc/ira-conflicts.cc 2024-02-09 10:41:39.201150644 +0100 > @@ -151,8 +151,8 @@ build_conflict_bit_table (void) > fprintf > (ira_dump_file, > "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", > - (long) allocated_words_num * sizeof (IRA_INT_TYPE), > - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); > + (long) (allocated_words_num * sizeof (IRA_INT_TYPE)), > + (long) (object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); > > objects_live = sparseset_alloc (ira_objects_num); > for (i = 0; i < ira_max_point; i++) > Note, we have many more cases where we use %ld or %lu to print > size_t values (ideally %zd/%zu if we can assume it on all hosts, or > with the above introduced HOST_SIZE_T_PRINT*, the problem with the > %ld/%lu and casts is that it truncates the values on LLP64 hosts (aka > %Windows). While I'd love to be able to use %z, I suspect it's going to be problematical. That's one of the cleanups I need to have Mariam do on the CRC code which uses %z extensively in its debugging dumps. So let's assume %z is a no-go for now. Having a HOST_SIZE_T_PRINT_UNSIGNED seems useful, so I'd tend to prefer we go with that solution from the URL above rather than just throwing some parens around the expression before casting the result to "long". jeff
--- gcc/ira-conflicts.cc 2024-02-01 21:03:57.339193085 +0100 +++ gcc/ira-conflicts.cc 2024-02-09 10:41:39.201150644 +0100 @@ -151,8 +151,8 @@ build_conflict_bit_table (void) fprintf (ira_dump_file, "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + (long) (allocated_words_num * sizeof (IRA_INT_TYPE)), + (long) (object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++)