Hi! On 2020-01-10T23:52:11+0100, I wrote: > On 2019-12-21T23:02:38+0100, I wrote: >> On 2019-12-20T17:46:57+0100, "Harwath, Frederik" wrote: >>>> > --- a/include/gomp-constants.h >>>> > +++ b/include/gomp-constants.h > >>>> > +#define GOMP_DEVICE_CURRENT -3 > >>>> Should this actually get value '-1' instead of '-3'? Or, is the OpenACC >>>> 'acc_device_t' code already paying special attention to negative values >>>> '-1', '-2'? (I don't think so.) > >>>> | Also, 'acc_device_current' is a libgomp-internal thing (doesn't interface >>>> | with the compiler proper), so strictly speaking 'GOMP_DEVICE_CURRENT' >>>> | isn't needed in 'include/gomp-constants.h'. But probably still a good >>>> | idea to list it there, in this canonical place, to keep the several lists >>>> | of device types coherent. > >>>> I still wonder about that... ;-) > >> I still think that 'GOMP_DEVICE_CURENT' should get value '-1' (and >> probably be rename 'GOACC_DEVICE_CURRENT' to make more obvious that it's >> not related to the 'GOMP_DEVICE_*' ones), but we shall have a look at >> that later (before GCC 10 release); that's libgomp/OpenACC-internal, >> doesn't affect anything else. > > That's still pending. Recently, > "Missing definition > for acc_device_current" got filed; let's (also/first) watch/wait what > comes out of that. (That's still pending, but) notwithstanding the specific value we'll use eventually, the 'acc_device_current' interface should work already now. ..., but I noticed that we don't have any test cases for that (so by that definition, it must be broken). The curious guy that I am sometimes ;-) I gave that a try, and... "of course"... it doesn't work. Please review the attached (Tobias the Fortran test cases, please), and test with AMD GCN offloading. If approving this patch, please respond with "Reviewed-by: NAME " so that your effort will be recorded in the commit log, see . Grüße Thomas