From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 24E04385B1B1 for ; Fri, 25 Nov 2022 09:32:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24E04385B1B1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669368759; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=tgFuDo5+Jc4uk4OKVHKx2RpYf/LzrfUBGdCkZGkZjnE=; b=W2yhobE3wV4U62JHWiwusyNpOaw4Lqz7n6GZFatitCUZ48sDQrnmuMFEIu3Y8ojgxUin85 vMazhQraVeZN19RgqRlgsabAaMp+gDp+m3kJszBepuY+/TfWoINdhd55cf7PbK7dmF6cUC V48O82yFwsno9dHHC3BC++xBIEYsAOg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-632-RsiQiPqOPYGQy8-hWgPQEA-1; Fri, 25 Nov 2022 04:32:38 -0500 X-MC-Unique: RsiQiPqOPYGQy8-hWgPQEA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 612503C0ED4F; Fri, 25 Nov 2022 09:32:38 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 233BE4A9265; Fri, 25 Nov 2022 09:32:38 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2AP9WXgh354648 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 25 Nov 2022 10:32:33 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2AP9WW5E354647; Fri, 25 Nov 2022 10:32:32 +0100 Date: Fri, 25 Nov 2022 10:32:31 +0100 From: Jakub Jelinek To: LIU Hao Cc: gcc@gcc.gnu.org Subject: Re: Please, really, make `-masm=intel` the default for x86 Message-ID: Reply-To: Jakub Jelinek References: <4b31677c-255c-2796-67c4-2d67f0c9fa60@126.com> MIME-Version: 1.0 In-Reply-To: <4b31677c-255c-2796-67c4-2d67f0c9fa60@126.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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, Nov 25, 2022 at 02:39:41PM +0800, LIU Hao via Gcc wrote: > I am a Windows developer and I have been writing x86 and amd64 assembly for > more than ten years. 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. So just use -masm=intel yourself and don't force it on others. Other people are familiar with AT&T syntax rather than Intel syntax, in fact, as history shows, Intel syntax is a second class citizen that often takes years to fix up for new instructions. The memory size prefixes for certain vector instructions are complete lottery and has been changed by the assembler over time. And more importantly, various valid sources aren't really compilable at all with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details. Jakub