From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92686 invoked by alias); 31 Jul 2017 11:47:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 91886 invoked by uid 89); 31 Jul 2017 11:47:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=schwab@suse.de, schwabsusede, Hx-languages-length:1727, differentiate X-HELO: mail-lf0-f54.google.com Received: from mail-lf0-f54.google.com (HELO mail-lf0-f54.google.com) (209.85.215.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 31 Jul 2017 11:47:46 +0000 Received: by mail-lf0-f54.google.com with SMTP id m86so105522765lfi.4 for ; Mon, 31 Jul 2017 04:47:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=znAht3ktiWrilHSBs+cy8mFeIoIIB8SivTxBkauipg0=; b=t6Ef5mHlVVIvFkupu7nt831eYEIWjAko/pMhic8p1nbPhafLryZrNAxZUytlJnIMts VeJNeQy0uP4traEgHkzct18xrlqKu9Mv0e2xrb30CzguWn32kJGaL24PiB6Z64m2sWD4 03eVRd+YFwfGOvi62/tzlWkOfcEedZVSDS7wXTrFZaN+iKK7slD6+6ItAYIY/z1EfRlx jI8MoM+eVWhlmeNgdh1SVFNSK07QsrW23S0Y2qV6k6BRhkP2aCEnfdM0iHm1I+Q744hg 2bMOdXH4/0V9FJd0BfPVJabJI1QgImMyuC+eiChNR6+8yIDcYKEvLdbzq7RATbF0mfLA 9XCw== X-Gm-Message-State: AIVw111Zy4v3YEGpJsUjtpl1q7EdHMcq+EVEeYvsTv6hQMiuBTR4d9NE 0ih258tdXmtFHLoU X-Received: by 10.46.5.136 with SMTP id 130mr5397548ljf.86.1501501664144; Mon, 31 Jul 2017 04:47:44 -0700 (PDT) Received: from [192.168.1.19] ([94.25.183.203]) by smtp.gmail.com with ESMTPSA id c4sm3978930lfk.42.2017.07.31.04.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 04:47:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v12] add -fpatchable-function-entry=N,M option From: Maxim Kuvyrkov In-Reply-To: Date: Mon, 31 Jul 2017 11:47:00 -0000 Cc: Torsten Duwe , "Richard Earnshaw (lists)" , Sandra Loosemore , Marek Polacek , GCC Patches , Szabolcs Nagy , nd@arm.com, Li Bin , Jiri Kosina , Marcus Shawcroft , Takahiro Akashi , Andrew Wafaa Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170706140311.GA20710@suse.de> <20170707193028.GA17752@suse.de> <20170726142629.GG22969@suse.de> To: Andreas Schwab X-SW-Source: 2017-07/txt/msg02016.txt.bz2 On Jul 26, 2017, at 5:33 PM, Andreas Schwab wrote: >=20 > On Jul 26 2017, Torsten Duwe wrote: >=20 >> On Wed, Jul 26, 2017 at 04:16:25PM +0200, Andreas Schwab wrote: >>> On Jul 07 2017, Torsten Duwe wrote: >>>=20 >>>> diff --git a/gcc/testsuite/c-c++-common/patchable_function_entry-decl.= c b/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c >>>> new file mode 100644 >>>> index 00000000000..8514b10e820 >>>> --- /dev/null >>>> +++ b/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c >>>> @@ -0,0 +1,16 @@ >>>> +/* { dg-do compile } */ >>>> +/* { dg-options "-O2 -fpatchable-function-entry=3D3,1" } */ >>>> +/* { dg-final { scan-assembler-times "nop" 2 } } */ >>>=20 >>> This fails on ia64. >>=20 >> The solution is fairly obvious: on architectures where the nop is not ca= lled >> "nop" provide a custom, cpu-specific test, or document the failure. >=20 > But on ia64, a nop _is_ called nop. The problem here is that ia64 backend emits "nop" instructions to pad IA64 = bundles. The 2 nops at the beginning are [as expected] from the patchable = attribute, but [unexpected] nops after ld8.mov and before "add r8" are gene= rated by ia64 bundle packing. nop 0 nop 0 .prologue .body .mmi addl r14 =3D @ltoffx(a#), r1 ;; ld8.mov r14 =3D [r14], a# nop 0 ;; .mmi ld4 r14 =3D [r14] ;; shladd r8 =3D r14, 2, r0 nop 0 ;; .mib nop 0 add r8 =3D r8, r14 br.ret.sptk.many b0 I don't see an easy way to correctly differentiate between "attribute" nops= and "bundle" nops, so XFAILing these tests on ia64 seems like a valid appr= oach. I speculate that other tests fail on ia64 for the same reason, but I didn't= check. -- Maxim Kuvyrkov www.linaro.org