From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 294F938582BC for ; Wed, 12 Oct 2022 14:11:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 294F938582BC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f50.google.com with SMTP id v130-20020a1cac88000000b003bcde03bd44so1274117wme.5 for ; Wed, 12 Oct 2022 07:11:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IexWSHm3IfNZp4njkwBI7GyINoG8Tv3nSOJrpjohOB4=; b=pSOYxZUoQafJ9i3T6il2zwD4an7xiR2vn8mirW6y6eD9HeChr3w9LdtahK4G2ygH/6 YhF+937K5axhPKcGvZJM5OvSMMup/2qQY+ZoKB1QtdoOpNz/yA68ipbAskr0JzyC9LkK o+ZNjkhkhYp6uHabCx23xRASU41H5lhwiJy0dERpO+bX/Qa1qHo5NX8bBK1UszuZMF2/ ZLK5GZDZUxQC5t+TVQicr4U+Ma5SqHjv33F+4IWPiY4ikYwlCoZAA3X2kgAdgYYqSKaI GZa2M+txDSEEslHhUGhKlZwqIXA3ZfbO5aMXk1I3Vioz0at8yRwSiHkKWHITHekzY/c2 HQKg== X-Gm-Message-State: ACrzQf3gxOpG1x/LZmvTK+I/VP2rnE7yDqdoHk5WKrZo888qzKHJcuQz qZW8/Ci8hqJ12qV+YvxXDqjZ8jqj8fQ6BW4c X-Google-Smtp-Source: AMsMyM6vI59j04TTqOt9j7ifLJ88kQmkziWDVdDW5UsEBiZ9uxWFoO/DmNo8Ug3xwE7Ecc7xyHX5xQ== X-Received: by 2002:a05:600c:1d1a:b0:3c6:d715:2d69 with SMTP id l26-20020a05600c1d1a00b003c6d7152d69mr1714068wms.145.1665583889315; Wed, 12 Oct 2022 07:11:29 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id m35-20020a05600c3b2300b003a1980d55c4sm2111108wms.47.2022.10.12.07.11.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Oct 2022 07:11:28 -0700 (PDT) Subject: Re: [PATCH 4/5] sim/erc32: avoid dereferencing type-punned pointer warnings To: Andrew Burgess , gdb-patches@sourceware.org References: From: Pedro Alves Message-ID: <170dc056-7e74-6c15-7131-31943c17be3a@palves.net> Date: Wed, 12 Oct 2022 15:11:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2022 14:11:34 -0000 On 2022-10-12 1:38 p.m., Andrew Burgess via Gdb-patches wrote: > When building the erc32 simulator I get a few warnings like this: > > /tmp/build/sim/../../src/sim/erc32/exec.c:1377:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] > 1377 | sregs->fs[rd] = *((float32 *) & ddata[0]); > | ~^~~~~~~~~~~~~~~~~~~~~~~ > > The type of '& ddata[0]' will be 'uint32_t *', which is what triggers > the warning. > > This commit uses an intermediate pointer of type 'char *' when > performing the type-punning, which is well-defined behaviour, and will > silence the above warning. I'm afraid that's not correct. That's still undefined behavior, it's just silencing the warning. The end result is still aliasing float32 and uint32_t objects, and risks generating bogus code. The char escape hatch only works if you access the object representation via a character type. Here, the patch is still accessing the object representation of a uint32_t object via a floa32 type. Here's an old article explaining strict aliasing (just one that I found via a quick google): https://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html This scenario is the "CASTING TO CHAR*" one in that article. > @@ -1345,7 +1345,8 @@ dispatch_instruction(struct pstate *sregs) > if (mexc) { > sregs->trap = TRAP_DEXC; > } else { > - sregs->fs[rd] = *((float32 *) & data); > + char *ptr = (char *) &data; > + sregs->fs[rd] = *((float32 *) ptr); The best IMHO is to do the type punning via a union, like e.g.: union { float32 f; uint32_t i; } u; u.i = data; sregs->fs[rd] = u.f; See here in the C11 standard: https://port70.net/~nsz/c/c11/n1570.html#note95 and also the documentation of -fstrict-aliasing at: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Pedro Alves