From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4F5773858289 for ; Fri, 26 May 2023 15:14:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F5773858289 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nexgo.de Received: from mr3.vodafonemail.de ([145.253.228.163]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2Z8r-00088I-9q for gcc@gnu.org; Fri, 26 May 2023 11:14:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1685114046; bh=zdKxSKgPz3MhqanGNJex08rlPPY8I6LOuR1D2LH6EHw=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: Content-Type:X-Mailer:From; b=mfTQFf7utoBGpccUaZF1LGvNAF+5JVfFOyxu8w4RKp6+FgXyEOxQmHTNyufjcaFQO 7ZKUeL9ALeKJDkAMNARqak6ws7twNmb6h24tflJMDBwAt3WBbpb9IK+MNNLcOonoaW 7MUMAeBUJ5gH+mpiiJAF4lu5JbJFnVWIV8WJYKDA= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr3.vodafonemail.de (Postfix) with ESMTPS id 4QST3L1cYTz20wM; Fri, 26 May 2023 15:14:06 +0000 (UTC) Received: from H270 (p5b38f631.dip0.t-ipconnect.de [91.56.246.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4QST345g30zMkrp; Fri, 26 May 2023 15:13:49 +0000 (UTC) Message-ID: From: "Stefan Kanthak" To: "Jonathan Wakely" Cc: "Jakub Jelinek" , , "Andrew Pinski" References: <896EB515110646CEBAA84E98E273E4B8@H270> <4BD5D8BA8E0F45098CC3E2B188A216E6@H270> In-Reply-To: Subject: Re: Will GCC eventually support SSE2 or SSE4.1? Date: Fri, 26 May 2023 17:07:13 +0200 Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-purgate-type: clean X-purgate: clean X-purgate-size: 1728 X-purgate-ID: 155817::1685114042-BE7FB4B9-8097F9F3/0/0 Received-SPF: pass client-ip=145.253.228.163; envelope-from=stefan.kanthak@nexgo.de; helo=mr3.vodafonemail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,RCVD_IN_DNSWL_LOW=-0.7,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_FAIL,SPF_HELO_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Jonathan Wakely" wrote: > On Fri, 26 May 2023 at 15:48, Stefan Kanthak wrote: >> >> "Jakub Jelinek" wrote: >> >> [...] >> >> > And for -m32 it is also the last option that wins, but as with >> > many other cases just last one from certain set of options. [...] >> > The -mISA options are processed left to right after >> >> as well as BEFORE > > No. You seem to be interpreting "after" to mean "later in the command > line" OUCH: "left" and "right" denote SPACE, not TIME! "after" follows "left to right", so it can only mean the position in the command line; if he meant "later or earlier/before" instead he should write that! > but Jakub means *at a later time*. He used "left to right" to > describe position in the command line, and "after" means "at a later > time". See above: that's his fault! > Any -march options are processed first, from left to right. After > that, there is a base arch in effect. > Then, after that, the -mISA options are processed, and take effect > relative to the base arch. > > What Jakub wrote is correct. If you try a bit harder to understand > what has been said repeatedly, you might get it. Why don't you and Jakub try to express yourself unambiguously? >> > setting base from -march=. >> >> In other words: although -march= selects a (documented sub)set of >> -mISA options, it does NEITHER reset any -mISA option set NOR any >> -mno-ISA option reset BEFORE or AFTER itself, i.e. all -m[no-]ISA >> options have precedence even if they preceed -march=. >> >> Just document that! > > That is not far from unreadable. Far in respect to space or time? Stefan