From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96267 invoked by alias); 10 Aug 2017 10:21:12 -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 96169 invoked by uid 89); 10 Aug 2017 10:21:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=watching, Hx-languages-length:3024, H*r:PDT X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 10:21:00 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1dfkaG-0006C9-JL from Thomas_Schwinge@mentor.com for gcc-patches@gcc.gnu.org; Thu, 10 Aug 2017 03:20:56 -0700 Received: from tftp-cs (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Thu, 10 Aug 2017 03:20:56 -0700 Received: by tftp-cs (Postfix, from userid 49978) id D475BC22BB; Thu, 10 Aug 2017 03:20:55 -0700 (PDT) From: Thomas Schwinge To: Tom de Vries CC: GCC Patches Subject: Re: [nvptx, PR 81662, committed] Error out on nvptx for fpatchable-function-entry In-Reply-To: <6ad5514b-cb0c-98f0-50ed-bacfa19a39a3@mentor.com> References: <9b7cba92-382d-4255-9983-2868726ad4f5@mentor.com> <6ad5514b-cb0c-98f0-50ed-bacfa19a39a3@mentor.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/25.2.1 (x86_64-pc-linux-gnu) Date: Thu, 10 Aug 2017 13:13:00 -0000 Message-ID: <87mv773erl.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-08/txt/msg00735.txt.bz2 Hi Tom! On Thu, 3 Aug 2017 13:23:16 +0200, Tom de Vries wr= ote: > [ was: Re: [testsuite, PR81662, committed] Skip=20 > fpatchable-function-entry tests for nvptx ] >=20 > On 08/03/2017 09:17 AM, Tom de Vries wrote: > > fpatchable-function-entry requires nop, which nvptx does not have. Generally, should we perhaps use something like the following to at least make it obvious in the generated PTX code that the compiler tried to generate a "nop"? --- gcc/config/nvptx/nvptx.md +++ gcc/config/nvptx/nvptx.md @@ -989,10 +989,11 @@ =20 ;; Miscellaneous =20 +;; PTX doesn't define a real "nop" instruction. (define_insn "nop" [(const_int 0)] "" - "") + "/* nop */") =20 (define_insn "return" [(return)] I have not tested this, have not verified whether we need to set the "predicable" attribute to "false" here (existing problem maybe?), have not thought about any other implications. But given that "comments in PTX are treated as whitespace", that should be fine? > > I've disabled the corresponding test for nvptx. Conceptually ACK. Not useful on PTX. > This patch errors out on nvptx for fpatchable-function-entry. > --- a/gcc/config/nvptx/nvptx.c > +++ b/gcc/config/nvptx/nvptx.c > @@ -180,6 +180,10 @@ nvptx_option_override (void) > if (!global_options_set.x_flag_no_common) > flag_no_common =3D 1; >=20=20 > + /* The patch area requires nops, which we don't have. */ > + if (function_entry_patch_area_size > 0) > + sorry ("not generating patch area, nops not supported"); > + > /* Assumes that it will see only hard registers. */ > flag_var_tracking =3D 0; I noticed that this doesn't trigger if using "-fpatchable-function-entry" during offloading compilation (but it does trigger for "-foffload=3D-fpatchable-function-entry"). Is this a) intentional or by accident, and/or b) desired? > --- /dev/null > +++ b/gcc/testsuite/gcc.target/nvptx/patchable_function_entry-default.c > @@ -0,0 +1,15 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2 -fpatchable-function-entry=3D3,1" } */ > + > +extern int a; > + > +int f3 (void); > + > +int > +__attribute__((noinline)) > +f3 (void) > +{ > + return 5*a; > +} > + > +/* { dg-excess-errors "sorry, unimplemented: not generating patch area, = nops not supported" } */ Given that the first argument of "dg-excess-errors" is just a comment, shouldn't we instead explicitly scan for this specific diagnostic, while also still watching for other excess errors? --- gcc/testsuite/gcc.target/nvptx/patchable_function_entry-default.c +++ gcc/testsuite/gcc.target/nvptx/patchable_function_entry-default.c @@ -1,5 +1,6 @@ /* { dg-do compile } */ /* { dg-options "-O2 -fpatchable-function-entry=3D3,1" } */ +/* { dg-message "sorry, unimplemented: not generating patch area, nops not= supported" "" { target *-*-* } 0 } */ =20 extern int a; =20 @@ -11,5 +12,3 @@ f3 (void) { return 5*a; } - -/* { dg-excess-errors "sorry, unimplemented: not generating patch area, no= ps not supported" } */ Gr=C3=BC=C3=9Fe Thomas