From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.killthe.net (mail.killthe.net [207.126.114.3]) by sourceware.org (Postfix) with ESMTP id 5487C3944401 for ; Fri, 25 Nov 2022 07:47:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5487C3944401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=killthe.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=killthe.net Received: from magic (unknown [172.58.158.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.killthe.net (Postfix) with ESMTPSA id 059D7124F01 for ; Fri, 25 Nov 2022 02:47:53 -0500 (EST) Date: Fri, 25 Nov 2022 01:48:22 -0600 From: Dave Blanchard To: gcc@gcc.gnu.org Subject: Re: Please, really, make `-masm=intel` the default for x86 Message-Id: <20221125014822.563a07773cdc2a33b4c872b7@killthe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_NONE,TXREP 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: On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc wrote: >> One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I >> have to do it twice: one in AT&T syntax and one in Intel syntax. > Why? A default is merely a default. I don't really see why changing > that should help you specifically. A decision "which assembly syntax > to use" is one that makes a project like ones you're contributing to, > not GCC. If they decided to use AT&T syntax, they won't switch to > Intel just because a compiler toolchain has changed their default. While I sympathize with the desire to get rid of crud (and I agree that AT&T syntax is crud), as stated above it wouldn't really make a practical difference. For distro maintainers it would likely break some/many older packages which assumed the old default behavior, thus requiring a number of patches. Usually not a big deal in and of itself (though it can be if the build system for that package is particularly junky), but when you consider there are so many packages including GCC always deprecating and changing things, it adds up to a lot of work to keep up with it all. -- Dave Blanchard