This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING] [PING] Make the OpenACC C++ acc_on_device wrapper "always inline"


On Tue, Jun 06, 2017 at 01:16:03PM +0200, Thomas Schwinge wrote:
> On Tue, 6 Jun 2017 08:58:21 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Tue, Jun 06, 2017 at 08:35:40AM +0200, Thomas Schwinge wrote:
> > > > > commit 9cc3a384c17e9f692f7864c604d2e2f9fbf0bac9
> > > > > Author: Thomas Schwinge <thomas@codesourcery.com>
> > > > > Date:   Tue May 23 13:21:14 2017 +0200
> > > > > 
> > > > >     Make the OpenACC C++ acc_on_device wrapper "always inline"
> > > > >     
> > > > >             libgomp/
> > > > >             * openacc.h [__cplusplus] (acc_on_device): Mark as "always
> > > > >             inline".
> > > > >             * testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c: Remove
> > > > >             file; test cases already present...
> > > > >             * testsuite/libgomp.oacc-c-c++-common/acc_on_device-1.c: ... in
> > > > >             this file.  Update.
> > > > >             * testsuite/libgomp.oacc-c-c++-common/acc-on-device.c: Remove
> > > > >             file; test cases now present...
> > > > >             * testsuite/libgomp.oacc-c-c++-common/acc_on_device-2.c: ... in
> > > > >             this new file.
> > > > >             * testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Update.
> > 
> > I don't like this very much.
> 
> Thanks for having a look.  Would you please clarify whether "this"
> applies to my "always inline" changes and testing additions that you
> quoted, or rather to the C++ "acc_on_device" wrapper function as it is
> currently present?

The C++ acc_on_device wrapper altogether, though of course always inline on
it doesn't sound right either (what if you want to take acc_on_device
address?).

> > Can't you instead just turn the builtin into BT_FN_INT_VAR and diagnose
> > during folding if it has no or 2+ arguments or if the argument is not type
> > compatible with int?
> 
> Thanks for the suggestion, I'll look into that!
> 
> In terms of incremental progress, do you oppose that I commit my existing
> patch now, and then rework the builtin in a later patch?

We are in stage1 and this doesn't seem to be a blocker, I think it is better
to do it right, no need to do it incrementally.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]