From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 392873858D37 for ; Wed, 20 Jul 2022 09:28:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 392873858D37 Received: by mail-pj1-x1035.google.com with SMTP id s18-20020a17090aa11200b001f1e9e2438cso1495836pjp.2 for ; Wed, 20 Jul 2022 02:28:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=rb9P/bz3magoPBz9rSV9YQ0nw+tPZ+BpcmY2cUSPaWs=; b=vzFXxZEvKQWVHYWl6AfJ3OxFwIi6CQ2vvoizVBUmnhXzi/6aMWqt6vmyANcZu4BZp1 fua36vsFhIxc4dlF//nj8J1Ql3ID/WFQO4/em6cR0qdhaLr47CtA5Rxo7mV7FXm/r7xN UVN6j9ay9cNd/NIsHHap6rbX1PJ1Ev+t33TcxMwGSedU/omqVUn8P2yKROIstqJYdwKR dsxE9Td/VGuqfYWw/TroVAvATxABjRcWK89B/Pstvz4LjO73sZInW/sHIMynmmgx9cNS x2DiVd3qGGbgI45LQFzvXcAb1GoDlnSluNKyndT8NPmXkhiwE0A0fdfpnsfIJzXLPrDp /EvA== X-Gm-Message-State: AJIora/LDZz1ICO4B5jOc0WGXOLJ+qWjXN4uTFlvlbeowK8+4MN/lkk8 mEMJNr4RiPFILa1QddYjFHA= X-Google-Smtp-Source: AGRyM1so+H7RaaVYtfVQHQZKH5ID2oM1J0FRQGgfQutBk9v3MO/kJSnvyPn/w0D27FyvWtNljGKs5g== X-Received: by 2002:a17:902:b488:b0:16a:7013:69f0 with SMTP id y8-20020a170902b48800b0016a701369f0mr38109772plr.118.1658309309808; Wed, 20 Jul 2022 02:28:29 -0700 (PDT) Received: from localhost (27-33-251-27.static.tpgi.com.au. [27.33.251.27]) by smtp.gmail.com with ESMTPSA id z16-20020aa79490000000b0052512fdaa43sm13045456pfk.163.2022.07.20.02.28.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 02:28:29 -0700 (PDT) Date: Wed, 20 Jul 2022 19:28:23 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2] powerpc: add documentation for HWCAPs To: Segher Boessenkool , Tulio Magno Quites Machado Filho Cc: Florian Weimer , gcc@gcc.gnu.org, libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org, Paul E Murphy References: <20220715012636.165948-1-npiggin@gmail.com> <877d4euskv.fsf@linux.ibm.com> <20220715195951.GA25951@gate.crashing.org> <874jziuo49.fsf@linux.ibm.com> In-Reply-To: <874jziuo49.fsf@linux.ibm.com> MIME-Version: 1.0 Message-Id: <1658309165.qvjv58f7ui.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2022 09:28:33 -0000 Excerpts from Tulio Magno Quites Machado Filho's message of July 16, 2022 6= :17 am: > Segher Boessenkool writes: >=20 >> That is a usability problem. Can it be fixed, or will that create its >> own compatibility problems? In practice I mean. If it is, the C >> libraries could fix it up, for new programs, and then after a while the >> kernel can do the sane thing? >> >> How big is the problem, anyway? Is it only 2.05, or also 2.04, 2.03? >=20 > PPC_FEATURE_ARCH_2_05 is the first bit referring to an ISA level. > Before that, AT_HWCAP used to have bits for specific processors, e.g. > PPC_FEATURE_CELL and PPC_FEATURE_POWER4. >=20 > Notice that glibc creates its own hwcap-based information that is used by > __builtin_cpu_supports(). In this case bits PPC_FEATURE_ARCH_2_05, > PPC_FEATURE_POWER5_PLUS, PPC_FEATURE_POWER5 and PPC_FEATURE_POWER4 are en= abled > whenever if the processor is compatible with the features provided by any= of > the previous processors [1]. > AT_HWCAP and AT_HWCAP2 are kept intact, though. >=20 > [1] https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dsysdeps/powerp= c/hwcapinfo.c;h=3Dafde05f86382413ce1f0c38e33c9bdd38d6b7e9d;hb=3DHEAD#l45 Hmm, this doesn't seem very nice. That said, before possibly changing=20 that in the kernel, documenting existing unexpected behaviour is=20 probably a good idea. Good catch, I obviously wasn't careful enough reviewing these bits. I'll send out a final patch with this adjustment in a week or so in case any more comments come in the meantime. Thanks, Nick