From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 26DB53858403 for ; Sat, 3 Feb 2024 08:45:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26DB53858403 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 26DB53858403 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706949945; cv=none; b=qB5pKxObTpMp7gkFCB8oNA+ogCM4zLX/6oXQ2MsiNizJYQYLerDsUKFVO8BWWclS00KyB+hiHTauaQP5BOvC26S8b+vZo7bszC0zmONX/0Jd39SGnPrY0XNnPaegvtdI0y04pduiF/C1YOoBA1H4J9e9x6qImQEHBaoJTFUhajo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706949945; c=relaxed/simple; bh=tRQyzzSE9ZwpKuSBHjfvE8Vq7G4KDEIRqwXnxPXbv1Q=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wNPMgsTFUwgwd0MPN15NFUuAaFTbA23VFL4PJYxU3w/VAaJorWoTk1XKHL4lJkizc6HbzkwHppb5PV2vTSKQLJW+mp0fJ2a/Y8Ev6f3yknoEbrBk65FCEKqJLimcn5h5DaQ7OR0Wpz+HXIbX87l/xd80B6qj+hKbmUlhIMlBz9U= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706949938; 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=dXeZtrXrP11agQe7eS/n0YZP5DbovdPDA7jWdXic0GA=; b=QBLHXFV77YAbEjHIFs31gqO5DLVTN5UFq+OHT2TGYARe5o58lTDvSkHmsnUkFzATgV3M7z Cu/Ut7kqijhCfU7ORznJvjXH62og97w72xcFCxmPM59+4a4+n9pVfmapT0PRhxNAUxYn08 lWvPkp7w5dPTY5Is+4ZqHSRC+0B7qUA= 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-563-L91e_22YMK6O5TjU8rVwxQ-1; Sat, 03 Feb 2024 03:45:37 -0500 X-MC-Unique: L91e_22YMK6O5TjU8rVwxQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 602D783B86E; Sat, 3 Feb 2024 08:45:36 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A1B651D5; Sat, 3 Feb 2024 08:45:35 +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 4138jXV81643532 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 3 Feb 2024 09:45:33 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4138jVnv1643530; Sat, 3 Feb 2024 09:45:31 +0100 Date: Sat, 3 Feb 2024 09:45:31 +0100 From: Jakub Jelinek To: Richard Biener , Richard.Sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] wide-int: Fix up wi::bswap_large [PR113722] Message-ID: Reply-To: Jakub Jelinek MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 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=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 List-Id: Hi! Since bswap has been converted from a method to a function we miscompile the following testcase. The problem is the assumption that the passed in len argument (number of limbs in the xval array) is the upper bound for the bswap result, which is true only if precision is <= 64. If precision is larger than that, e.g. 128 as in the testcase, if the argument has only one limb (i.e. 0 to ~(unsigned HOST_WIDE_INT) 0), the result can still need 2 limbs for that precision, or generally BLOCKS_NEEDED (precision) limbs, it all depends on how many least significant limbs of the operand are zero. bswap_large as implemented only cleared len limbs of result, then swapped the bytes (invoking UB when oring something in all the limbs above it) and finally passed len to canonize, saying that more limbs aren't needed. The following patch fixes it by renaming len to xlen (so that it is clear it is X's length), using it solely for safe_uhwi argument when we attempt to read from X, and using new len = BLOCKS_NEEDED (precision) instead in the other two spots (i.e. when clearing the val array, turned it also into memset, and in canonize argument). wi::bswap asserts it isn't invoked on widest_int, so we are always invoked on wide_int or similar and those have preallocated result sized for the corresponding precision (i.e. BLOCKS_NEEDED (precision)). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-02-03 Jakub Jelinek PR middle-end/113722 * wide-int.cc (wi::bswap_large): Rename third argument from len to xlen and adjust use in safe_uhwi. Add len variable, set it to BLOCKS_NEEDED (precision) and use it for clearing of val and as canonize argument. Clear val using memset instead of a loop. * gcc.dg/pr113722.c: New test. --- gcc/wide-int.cc.jj 2024-01-03 11:51:42.077584823 +0100 +++ gcc/wide-int.cc 2024-02-02 18:13:34.993332159 +0100 @@ -729,20 +729,19 @@ wi::set_bit_large (HOST_WIDE_INT *val, c } } -/* Byte swap the integer represented by XVAL and LEN into VAL. Return +/* Byte swap the integer represented by XVAL and XLEN into VAL. Return the number of blocks in VAL. Both XVAL and VAL have PRECISION bits. */ unsigned int wi::bswap_large (HOST_WIDE_INT *val, const HOST_WIDE_INT *xval, - unsigned int len, unsigned int precision) + unsigned int xlen, unsigned int precision) { - unsigned int i, s; + unsigned int s, len = BLOCKS_NEEDED (precision); /* This is not a well defined operation if the precision is not a multiple of 8. */ gcc_assert ((precision & 0x7) == 0); - for (i = 0; i < len; i++) - val[i] = 0; + memset (val, 0, sizeof (unsigned HOST_WIDE_INT) * len); /* Only swap the bytes that are not the padding. */ for (s = 0; s < precision; s += 8) @@ -753,7 +752,7 @@ wi::bswap_large (HOST_WIDE_INT *val, con unsigned int block = s / HOST_BITS_PER_WIDE_INT; unsigned int offset = s & (HOST_BITS_PER_WIDE_INT - 1); - byte = (safe_uhwi (xval, len, block) >> offset) & 0xff; + byte = (safe_uhwi (xval, xlen, block) >> offset) & 0xff; block = d / HOST_BITS_PER_WIDE_INT; offset = d & (HOST_BITS_PER_WIDE_INT - 1); --- gcc/testsuite/gcc.dg/pr113722.c.jj 2024-02-02 18:25:22.702561427 +0100 +++ gcc/testsuite/gcc.dg/pr113722.c 2024-02-02 18:21:00.109186858 +0100 @@ -0,0 +1,22 @@ +/* PR middle-end/113722 */ +/* { dg-do run { target int128 } } */ +/* { dg-options "-O2" } */ + +int +main () +{ + unsigned __int128 a = __builtin_bswap128 ((unsigned __int128) 2); + if (a != ((unsigned __int128) 2) << 120) + __builtin_abort (); + a = __builtin_bswap128 ((unsigned __int128) 0xdeadbeefULL); + if (a != ((unsigned __int128) 0xefbeaddeULL) << 96) + __builtin_abort (); + a = __builtin_bswap128 (((unsigned __int128) 0xdeadbeefULL) << 64); + if (a != ((unsigned __int128) 0xefbeaddeULL) << 32) + __builtin_abort (); + a = __builtin_bswap128 ((((unsigned __int128) 0xdeadbeefULL) << 64) + | 0xcafed00dfeedbac1ULL); + if (a != ((((unsigned __int128) 0xc1baedfe0dd0fecaULL) << 64) + | (((unsigned __int128) 0xefbeaddeULL) << 32))) + __builtin_abort (); +} Jakub