From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 47DB93858D37 for ; Tue, 30 Jun 2020 09:46:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 47DB93858D37 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-320-EMzKCU9ZNCSp8OQmeSTZ1A-1; Tue, 30 Jun 2020 05:46:05 -0400 X-MC-Unique: EMzKCU9ZNCSp8OQmeSTZ1A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 576D0107ACCA; Tue, 30 Jun 2020 09:46:04 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-128.ams2.redhat.com [10.36.112.128]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 805B22B4AD; Tue, 30 Jun 2020 09:46:03 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: "H.J. Lu via Libc-alpha" , Adhemerval Zanella Subject: Re: V6: [PATCH] x86: Install [BZ #26124] References: <87ftamg7ez.fsf@oldenburg2.str.redhat.com> <87a70ug5v8.fsf@oldenburg2.str.redhat.com> <871rm4bkj6.fsf@oldenburg2.str.redhat.com> <697cab8a-2d75-ef36-9e09-dbfe6daa4ae1@linaro.org> <87a70r8urd.fsf@oldenburg2.str.redhat.com> <20200625123059.GA1169557@gmail.com> <20200625132023.GA1223726@gmail.com> <871rlxx326.fsf@oldenburg2.str.redhat.com> <87k0zpvmuj.fsf@oldenburg2.str.redhat.com> Date: Tue, 30 Jun 2020 11:46:01 +0200 In-Reply-To: (H. J. Lu's message of "Mon, 29 Jun 2020 17:29:42 -0700") Message-ID: <87lfk4sx7q.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.8 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:46:08 -0000 * H. J. Lu: > On Mon, Jun 29, 2020 at 9:49 AM Florian Weimer wrote: >> >> * H. J. Lu: >> >> >> One thing I still dislike (sorry) is the asymmetry between the usable >> >> and feature checks. For example, why is there are usability check for >> >> VAES, but not for AES? I believe the reason is that VAES depends on >> >> AVX/AVX2, but AES only depends on SSE2. But even that suggests to me >> >> that for 32-bit, there should be a usable gate for that (which is false >> >> if SSE2 support has been masked). >> > >> > CPU with AES must have SSE2. I don't think we need explicit check >> > for SSE2. >> >> But SSE2 needs operating system support, so we get the usable vs >> available distinction this way. I think. >> > > We don't check if OS supports SSE2. Isn't this a bug? Not that it matters much these days, but how did this work in the beginning? Thanks, Florian