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 015983858CDB for ; Fri, 26 May 2023 12:50:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 015983858CDB 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 mr5.vodafonemail.de ([145.253.228.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2Wu2-0001D6-JE for gcc@gnu.org; Fri, 26 May 2023 08:50:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1685105439; bh=dfS7S3N7o1J0gt/jvkZffGXBvyarz0KFnzhLrXbve2s=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: Content-Type:X-Mailer:From; b=ZDgyrQ1mjjpG7OCkIi9wGREY6BvAYqsOtaOyNNOqfhAgLmyMIzXGybm/KOz+Nf5MY L+rnVbuYTfSo1JIJphw7w0vCtSnSyWiAuIu59nN5DGaEegK3th2AeWpneadhVRLFGx rnlhr/RcCXwX4qOXhIJqa1VN1Ws6gD2jpClyw4U4= 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 mr5.vodafonemail.de (Postfix) with ESMTPS id 4QSPsq4nr5z1y0w; Fri, 26 May 2023 12:50:39 +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 4QSPsZ2Kr1z9sDB; Fri, 26 May 2023 12:50:23 +0000 (UTC) Message-ID: <2D3BCE2E82544ACD95352C72BE944C59@H270> From: "Stefan Kanthak" To: "Jonathan Wakely" Cc: "Jakub Jelinek" , , "Andrew Pinski" References: <51071A92918346ABBC6B5703179F5174@H270> <896EB515110646CEBAA84E98E273E4B8@H270> <4BD5D8BA8E0F45098CC3E2B188A216E6@H270> In-Reply-To: Subject: Re: Will GCC eventually support SSE2 or SSE4.1? Date: Fri, 26 May 2023 14:42:45 +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: 2846 X-purgate-ID: 155817::1685105435-B6FFC4DE-9FCA09CC/0/0 Received-SPF: pass client-ip=145.253.228.165; envelope-from=stefan.kanthak@nexgo.de; helo=mr5.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 13:23, Stefan Kanthak wrote: >> >> "Jonathan Wakely" wrote: >> >> > On Fri, 26 May 2023 at 12:42, Stefan Kanthak wrote: >> >> Why does the documentation FAIL to specify that CPU features given by >> >> -m* override -m32 or enables them in ADDITION to those enabled by -march=? >> > >> > Because it's obvious. If you ask for sse2 you get it. >> >> ARGH! The documentation for -m32 contradicts >> >> | -m32 >> ... >> | The -m32 option sets int, long, and pointer types to 32 bits, and >> | generates code that runs on any i386 system. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> > I find it very SURPRISING that you're only just learning the basics of >> > how to use gcc NOW, after YELLING about all the OUCH. >> >> I'm NOT surprised that you don't grok it! >> >> gcc -msse4.1 -m32 -march=core2 ... >> >> Which -m* options win here? >> Do -m32 or -march=core2 override -msse4.1? > > No, because -m32 says to generate code for the 32-bit model, it > doesn't select an instruction set. I underlined the relevant part, EXTRA FOR YOU! Bonus question: does every 32-bit i386 system support SSE instructions? > A multilib x86_64 compiler has a default 64-bit arch and a default > 32-bit arch. If you don't configure GCC with --with-arch-32 and/or > --with-arch-64 then you get -march=x86-64 for both 32-bit and 64-bit. > Using -m32 without -march will use the default 32-bit arch, which is > probably x86-64. Using -m32 with any explicit -march will override the > default, and use the one you specified. This is NOT what the underlined part of the documentation says! > And I already said that -march selects the base instruction set, and > then -msse4.1 adds to that, enabling sse4.1 as well. > > I said: > > -march enables the instructions listed for the relevant cpu family, > then using -mxxx or -mno-xxx adds or removes particular instruction > sets from the ones enabled by -march. "Then" means after, not before! Guess why I asked EXPLICITLY for the preferences?! > So -march=core2 selects the instruction sets listed in the docs, and > then -msse4.1 adds to that. I don't know how to say it more clearly. That's your problem! Set some sequence points... > All this could have been explained easily and without conflict if > you'd use the right mailing list in the first place and asked how > things work, instead of storming in acting like a clown and being > rude. > > "Will GCC eventually support SSE2 or SSE4.1?" is confrontational, and > makes you look dumb. And it's just got worse since then. I could have added PROPERLY, because that's where it CLEARLY fails, as shown by the generated unoptimised code. Stefan