From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B245FC433EF for ; Thu, 7 Oct 2021 07:53:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9B4756112D for ; Thu, 7 Oct 2021 07:53:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232617AbhJGHzC convert rfc822-to-8bit (ORCPT ); Thu, 7 Oct 2021 03:55:02 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.85.151]:29035 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232550AbhJGHzB (ORCPT ); Thu, 7 Oct 2021 03:55:01 -0400 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-38-fz1CuUWYNx6QMVBcOLTHFg-1; Thu, 07 Oct 2021 08:53:02 +0100 X-MC-Unique: fz1CuUWYNx6QMVBcOLTHFg-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 7 Oct 2021 08:53:01 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.023; Thu, 7 Oct 2021 08:53:01 +0100 From: David Laight To: 'Segher Boessenkool' , Stafford Horne CC: Rich Felker , "Rafael J. Wysocki" , Catalin Marinas , "x86@kernel.org" , Guo Ren , "H. Peter Anvin" , "linux-riscv@lists.infradead.org" , "Will Deacon" , Jonas Bonn , Rob Herring , Florian Fainelli , Frank Rowand , "linux-sh@vger.kernel.org" , Russell King , "linux-csky@vger.kernel.org" , Ingo Molnar , "bcm-kernel-feedback-list@broadcom.com" , James Morse , "devicetree@vger.kernel.org" , Albert Ou , Ray Jui , Stefan Kristiansson , "openrisc@lists.librecores.org" , Borislav Petkov , "Paul Walmsley" , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Scott Branden , Yoshinori Sato , "linux-kernel@vger.kernel.org" , Palmer Dabbelt , Greg Kroah-Hartman , "Paul Mackerras" , "linuxppc-dev@lists.ozlabs.org" Subject: RE: [PATCH 06/12] openrisc: Use of_get_cpu_hwid() Thread-Topic: [PATCH 06/12] openrisc: Use of_get_cpu_hwid() Thread-Index: AQHXuvrQ2rKkD2ly1kazB6yB6/HdHavHKFTA Date: Thu, 7 Oct 2021 07:53:01 +0000 Message-ID: References: <20211006164332.1981454-1-robh@kernel.org> <20211006164332.1981454-7-robh@kernel.org> <20211006212728.GM10333@gate.crashing.org> In-Reply-To: <20211006212728.GM10333@gate.crashing.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org From: Segher Boessenkool > Sent: 06 October 2021 22:27 > > On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote: > > You have defined of_get_cpu_hwid to return u64, will this create compiler > > warnings when since we are storing a u64 into a u32? > > > > It seems only if we make with W=3. > > Yes. This is done by -Wconversion, "Warn for implicit conversions that > may alter a value." > > > I thought we usually warned on this. The microsoft compiler does - best to turn all those warnings off. > This warning is not in -Wall or -Wextra either, it suffers too much from > false positives. It is very natural to just ignore the high bits of > modulo types (which is what "unsigned" types *are*). Or the bits that > "fall off" on a conversion. The C standard makes this required > behaviour, it is useful, and it is the only convenient way of getting > this! I've also seen a compiler convert: struct->char_member = (char)(int_val & 0xff); into: reg = int_val; reg &= 0xff; // for the & 0xff reg &= 0xff; // for the cast struct->char_member = low_8bits(reg); You really don't want the extra noise. I'll bet that (char)int_val is actually an arithmetic expression. So its type will be 'int'. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)