e in their
> current form they no longer make much sense, as far as I can tell:
>
> For example, 'libgomp.oacc-c-c++-common/lib-22.c':
>
> acc_copyin (h, N);
>
> ... followed by:
>
> acc_copyout (h + 1, N - 1);
>
> ... is now meant to no longer abort wit
'? Am I missing something there?
It will be OK to clean that up later, but I'd like to understand this
now. Well, or, stating that you just blindly copied that from the
existing 'gomp_unmap_vars_async' is fine, too! ;-P
Grüße
Thomas
> --- a/libgomp/target.c
>
al
packing that happens for arguments.
Maybe -finline-repack would be a better name? -finline-internal-pack?
Regards
Thomas
Hi!
See attached "[PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped
by 'acc_map_data'", committed to trunk in r279145.
As mentioned in the patch, some further checking can be applied, later,
incrementally.
Grüße
Thomas
From bea573cb7ea13cece9c51ca9eb1
sibly "we might actually keep such additional/expensive
sanity-checking, but guard it by an environment variable".
Grüße
Thomas
From 03383a93c7318009ddd0e8d77b1a950c4b2b8f5a Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Mon, 9 Dec 2019 22:52:47 +
Subject: [PATCH] [PR92503]
Hi!
\o/ Yay for the first split-out piece of the big "OpenACC reference count
overhaul" going in:
On 2019-10-29T12:15:01+, Julian Brown wrote:
> On Mon, 21 Oct 2019 16:14:11 +0200
> Thomas Schwinge wrote:
>> Remeber to look into <https://gcc.gnu.org/PR92116>
Hi Julian!
On 2019-12-09T15:04:15+, Julian Brown wrote:
> On Mon, 9 Dec 2019 15:44:25 +0100
> Thomas Schwinge wrote:
>> On 2019-10-03T09:35:04-0700, Julian Brown
>> wrote:
>> > --- a/libgomp/oacc-mem.c
>> > +++ b/libgomp/oacc-mem.c
>>
>>
-low.c.
>
> here are patches adding the promised test for Fortran and a corresponding
> test for C.
>
> Is it ok to include them in trunk?
Thanks, yes, with my following remarks considered, and acted on per your
preference. To record the review effort, please include "Re
ough
to cure the ICE.
Regards
Thomas
2019-12-10 Thomas Koenig
PR fortran/92863
* misc.c (gfc_typename): If derived component is NULL for
derived or class, return "invalid type" or "invalid class",
respectively.
2019-12-10 T
Am 09.12.19 um 17:30 schrieb Thomas Koenig:
Maybe -finline-repack would be a better name? -finline-internal-pack?
Steve made an excellent suggestion: -finline-arg-packing .
So, OK with that change?
Regards
Thomas
Hello world,
this fixes a regression introduced by my inline repacking patch.
With the test case, it is simple and obvious enough - do not repack
an assumed rank argument (which makes no sense).
Committed as obvious and simple as r279203 after regression-testing.
2019-12-10 Thomas Koenig
this is not the case, it is better to add new tests to
new test cases - this makes regression hunting much easier.
Regards
Thomas
Tested x86_64-pc-linux-gnu, committed to trunk, backported to
gcc-9-branch.
Jonathan Wakely writes:
> On 18/11/19 20:54 -0800, Thomas Rodgers wrote:
>>
>> * include/pstl/glue_numeric_defs.h: Restore enable_if lost during
>> original
>> import of p
User-agent: mu4e 1.3.4; emacs 26.2
* include/std/condition_variable
(condition_variable_any::wait_on(_Lock&, stop_token, _Predicate): Rename
to match current draft standard.
(condition_variable_any::wait_on_until(_Lock&, stop_token,
const chrono::time_point<>
dynamic_refcount' whenever we
initialize 'refcount'" for 'Cases missed in r261813 "Update OpenACC data
clause semantics to the 2.5 behavior"'; committed to trunk in r279230,
and backported to gcc-9-branch in r279238.
Grüße
Thomas
From 20d0998b970ba693b2
the OpenACC 2.6 semantics.
The TODO in 'libgomp.oacc-c-c++-common/acc_map_data-device_already-3.c'
is being tracked in PR92888 "[OpenACC] Failure to resolve back via
'acc_hostptr' an 'acc_deviceptr' retrieved for a '#pragma acc declare'd
variable".
G
Hi!
As a preparational patch/general refactoring, see attached "[OpenACC]
Consolidate 'async'/'wait' code in 'libgomp/oacc-async.c'"; committed to
trunk in r279232.
Grüße
Thomas
From 2b04bb7b4c9a13b6eadc7d9723245dd58f0f4f04 Mon Sep 17 00:00:00 2001
Fr
Hi!
On 2019-10-29T12:15:01+, Julian Brown wrote:
> On Mon, 21 Oct 2019 16:14:11 +0200
> Thomas Schwinge wrote:
>> On 2019-10-03T09:35:04-0700, Julian Brown
>> wrote:
>> > void
>> > -gomp_acc_remove_pointer (void *h, size_t s,
Hi!
See attached "[PR92843] [OpenACC] Fix dynamic reference counting for
structured 'REFCOUNT_INFINITY'"; committed to trunk in r279234.
Grüße
Thomas
From 7c8ffaf54af2c8acb77f82349aac4dd68d47ad9d Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Wed, 11 Dec 2019 16:49:27 +
ort will be
recorded in the commit log, see <https://gcc.gnu.org/wiki/Reviewed-by>.
(It will be a separate discussion to change the 'GOMP_MAP_POINTER',
'GOMP_MAP_TO_PSET' stuff later on -- thinking about the changes from
Julian's big "OpenACC reference count overh
ed = false;
> - [...]
> +
> + struct target_mem_desc *tgt = (struct target_mem_desc *) ptr;
> +
> + assert (tgt->refcount != REFCOUNT_INFINITY);
Please leave out this 'assert': we don't have any of these yet for
'tgt->refcount' (as far as I remember), and fixing that is a separate
change, to generally deal that issue;
<87r22an29u.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/87r22an29u.fsf@euler.schwinge.homeip.net>.
Grüße
Thomas
signature.asc
Description: PGP signature
Hi Julian!
On 2019-10-29T12:15:01+, Julian Brown wrote:
> On Mon, 21 Oct 2019 16:14:11 +0200
> Thomas Schwinge wrote:
>
>> On 2019-10-03T09:35:04-0700, Julian Brown
>> wrote:
>> > --- a/libgomp/oacc-parallel.c
>> > +++ b/libgomp/oacc-parallel.c
>
Am 10.12.19 um 22:22 schrieb Thomas Koenig:
Steve made an excellent suggestion: -finline-arg-packing .
So, OK with that change?
In other words, is
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
OK with renaming the option to -finline-arg-packing ?
Regards
Thomas
Some vertical space before the "From openacc_kinds" comment, and before
the 'acc_async_*' ones?
>public :: openacc_version
>
>public :: acc_get_num_devices, acc_set_device_type, acc_get_device_type
> @@ -730,6 +731,7 @@ module openacc
>public :: acc_update_device, acc_update_self, acc_is_present
>public :: acc_copyin_async, acc_create_async, acc_copyout_async
>public :: acc_delete_async, acc_update_device_async, acc_update_self_async
> + public :: acc_copyout_finalize, acc_delete_finalize
Put these into the place where they really belong, after 'acc_copyout,
and 'acc_delete', respectively?
Grüße
Thomas
signature.asc
Description: PGP signature
Hi Paul,
Regtested on FC31/x86_64 - OK for 9- and 10- branches?
OK. Thanks for the patch!
Regards
Thomas
that as an alternative to the Fortran 'openacc' module, there also
exists 'openacc_lib.h', which you didn't update here.
As of OpenACC 2.5, 'openacc_lib.h' has been deprecated ("no longer
supported"), but so far, we continued to support it, and it'
ossible. (Especially different Fortran
interfaces.)
I see 'libgomp/oacc-host.c:host_get_property',
'libgomp/plugin/plugin-hsa.c:GOMP_OFFLOAD_get_property',
'liboffloadmic/plugin/libgomp-plugin-intelmic.cpp:GOMP_OFFLOAD_get_property'
do have a 'default:
y-3.c',
'libgomp.oacc-c-c++-common/deep-copy-5.c' test cases work?
Grüße
Thomas
signature.asc
Description: PGP signature
ommon
> case no aux pointer at all, so no growth in the base struct size.
That was in response to:
> On Fri, 18 Oct 2019 18:47:08 +0200
> Thomas Schwinge wrote:
>> While reviewing
>> <http://mid.mail-archive.com/20191003163505.49997-2-julian@codesourcery.com>
>&g
Hi!
On 2019-12-17T12:28:32+0100, Thomas Schwinge wrote:
> As a first step, can you please split out just the code required to make
> the OpenACC 'acc_attach*', 'acc_detach*' runtime library routines work?
I've now simply done this myself (that is, code extracti
Hi Julian!
Thanks for walking me through this.
On 2019-12-14T00:19:04+, Julian Brown wrote:
> On Fri, 13 Dec 2019 16:25:25 +0100
> Thomas Schwinge wrote:
>> On 2019-10-29T12:15:01+, Julian Brown
>> wrote:
>> > static int
>> > -find_pointer (in
Hi!
On 2019-05-13T21:33:20+0800, Chung-Lin Tang wrote:
> committed
(... in r271128.)
As obvious, see attached "Make 'libgomp/target.c:gomp_unmap_tgt' 'static'
again"; committed to trunk in r279529.
Grüße
Thomas
From 60272bbbd67100b5fd864bfa8a9495b249778
Hi!
I haven't researched when this broke, but to fix PR92848 "[OpenACC]
Memory leak for simple 'acc_create', 'acc_delete' sequence", see attached
"[PR92848] [OpenACC] Use 'GOMP_MAP_VARS_ENTER_DATA' for dynamic data
lifetimes"
Hi!
On 2019-12-13T23:34:15+, Julian Brown wrote:
> On Fri, 13 Dec 2019 15:13:53 +0100
> Thomas Schwinge wrote:
>> Julian, Tobias, regarding the following OpenACC 'exit data' 'finalize'
>> handling:
>>
>> On 2018-05-25T13:01:58-0700, Cesar
_delete'
etc. for 'NULL'-in, non-present data, or size zero"; committed to trunk
in r279532.
More C/C++ and also Fortran test cases (that exercises all the different
code paths that we have in 'libgomp/oacc-mem.c:GOACC_enter_exit_data',
related to 'find_poi
return false;
> +default:
> + return true;
> +}
> +}
Poor 'GOMP_MAP_FORCE_FROM'... ;'-|
See attached "[OpenACC] In 'libgomp/target.c:gomp_to_device_kind_p',
handle 'GOMP_MAP_FORCE_FROM' like 'GOMP_MAP_FROM'"; co
Hi!
On 2019-12-07T15:22:33+0100, I wrote:
> [...] propose the attached patch
> adding a safeguard [...]
See attached "Assert in 'libgomp/target.c:gomp_unmap_vars_internal' that
we're not unmapping 'tgt' while it's still in use"; committ
;, "[OpenACC] Refactor
'goacc_remove_pointer' interface", "[OpenACC] Refactor 'goacc_enter_data'
so that it can be called from 'goacc_insert_pointer', "not present"
case", "[OpenACC] Refactor 'goacc_enter_data' so that it can be
patches for
'libgomp.oacc-c-c++-common/', and then 'libgomp.oacc-fortran/'), but
instead per self-contained functional change, incrementally.
Grüße
Thomas
signature.asc
Description: PGP signature
at present.)
> Otherwise, except for added acc_is_present calls to no_create-3.c to
> check that no_create does not cause mapping and applying your/Thomas's
> patches, it matches my previous version, which was OK'ed. — Hence, I
> intent to commit it tomorrow, unless
, but for this bug fix, I
left the functionality as is).
Regression-tested. OK for trunk?
Regards
Thomas
2019-12-19 Thomas Koenig
PR fortran/91541
* intrinsic.c (add_sym_4ind): New function.
(add_functions): Use it for INDEX.
(resolve_intrinsic): Also
t
this patch in.
So, OK for trunk, and thanks for the patch!
Regards
Thomas
patch. Rather than try to transport state across I
do not know how many levels of calls, I chose a global variable.
Regression-tested. OK for all affected branches?
Regards
Thomas
2019-12-20 Thomas Koenig
PR fortran/92961
* gfortran.h (gfc_seen_div0): Add declaration
too many regressions occurring. It might be better to slow this
down somewhat, and to conduct a more throrough review process before
committing.
Regards
Thomas
the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.
Actually, it does not fix all testcases in the PR, so some more
tweaking is still needed.
Regards
Thomas
hanks, and sorry for the breakage.
Note to self: Try not to forget that dot.
This was not caught with "make check-fortran" from the gcc
build directory. Maybe it would be a good idea to add that
test to check-fortran too. Does anybody have an idea
how to do that?
Regards
Thomas
Am 20.12.19 um 22:33 schrieb Harald Anlauf:
The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message. The patch below rectifies that.
OK for trunk?
OK.
Thanks for the patch!
Regards
Thomas
attached "[PR93026, PR92929] Adjust
'gfortran.dg/goacc/finalize-1.f' for r279626 changes"; committed to trunk
in r279700.
Grüße
Thomas
> ChangeLog
>
> gcc/
> * gimplify.c (gimplify_omp_var_data): Add GOVD_MAP_HAS_ATTACHMENTS.
> (insert_struct_
ink 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.
>> Maybe this stuff should move from 'include/gomp-constants.h' to
>> 'libgomp/oacc-int.h'. I'll think about that again, when I'm awake again
>> tomorrow. ;-)
>
> Have you made up your mind yet? :-)
Still sleepy. ;-)
> Is it ok to commit the patch to trunk?
OK, thanks. And then some follow-up/clean-up next year, also including
some of the open questions that I've snipped off here.
Grüße
Thomas
signature.asc
Description: PGP signature
equently-used/API-specific data" commit,
<80e0dba326a4414fd2dbe8401dbd8d8f08445129.1576648001.git.julian@codesourcery.com">http://mid.mail-archive.com/80e0dba326a4414fd2dbe8401dbd8d8f08445129.1576648001.git.julian@codesourcery.com>,
so curious why it now appears here -- ho
information several calls deep, I chose
to use a global variable.
Regression-tested. OK for trunk?
(Only a few bugs to fix to be at least below 900 bugs at the end
of the year, by the way - we are at 389 submitted bugs vs. 461 closed,
which is not bad).
Regards
Thomas
2019-12-22 Thomas
-bit pointers, such as x86_64
GNU/Linux's '-m32' multilib. This will need further tweaking to enable
tree dump scanning for all configurations, but for now, see attached
"Restrict 'c-c++-common/goacc/mdc-1.c' to LP64, LLP64"; committed to
trunk in r279720.
Grü
Hi Tobias,
Build on x86-64-gnu-linux without offloading and with nvptx offloading.
OK for the trunk?
I can't really say a lot about OpenACC, but the changes do look
reasonable.
So, OK for trunk.
Regards
Thomas
Am 22.12.19 um 16:28 schrieb Thomas Koenig:
here is an update for the fix for PR 92961, which also takes care
of the second test case in the PR (included in the first one).
The patch itself should be clear enough - make sure that there
is a MATCH_ERROR on matching an array spec which contains
Am 19.12.19 um 08:23 schrieb Thomas Koenig:
Regression-tested. OK for trunk?
Ping?
Hi Jerry,
OK for trunk?
Looks good. I also think that your approach that DEC stuff should
be checked later is good. If it passes the testsuite, that's good
enough for a commit.
Thanks for the patch!
Regards
Thomas
Hello world,
New year, new bug, new patch :-)
I have just committed as obvious and simple the attached patch
as r279821, where we failed to account for %re and %im in dependency
checking. This is a 10 regression, gcc 9 works.
Regards
Thomas
Handle REF_INQUIRY for dependency checking
, and
the type has not been set some other way.
Regression-tested. OK for trunk?
Regards
Thomas
Save typespec for empty array constructor.
2020-01-02 Thomas Koenig
PR fortran/65428
* array.c (empty_constructor): New variable.
(empty_ts): New var
Hi Tobias,
Build on x86-64-gnu-linux. OK for the trunk?
Looks good.
Thanks for the patch!
Regards
Thomas
xample counting
while statements in the *.original dump) that the copyback does not
happen.
Generally, if we are passing an expression, the call to
gfc_conv_subref_array_arg is not needed - we will generate an array
temporary for the expression anyway, and this will always be contiguous.
Regards
Thomas
Hi Tobias,
PS: I lost a bit the overview. Is there any patch pending review or
otherwise pending?
From my side, there is the patch for PR 65428,
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00040.html
Apart from that, I don't see any outstanding patches.
Regards
Thomas
patch!
Regards
Thomas
add test
cases etc. (... but need not be done right now.)
Grüße
Thomas
> 2020-01-07 Jakub Jelinek
>
> PR fortran/93162
> * trans-openmp.c (gfc_trans_omp_clauses): Check for REF_ARRAY type
> before testing u.ar.type == AR_FULL.
>
> --- gcc/fortran/trans-o
Tested x86_64-pc-linux-gnu, committed to trunk.
Jonathan Wakely writes:
> On 10/12/19 22:38 -0800, Thomas Rodgers wrote:
>>User-agent: mu4e 1.3.4; emacs 26.2
>> * include/std/condition_variable
>> (condition_variable_any::wait_on(_Lock&, stop_token, _Pred
Am 02.01.20 um 23:35 schrieb Thomas Koenig:
Hello world,
the attached patch fixes an ICE where an array constructor
containing an empty array constructor with a type didn't
get the type from the inner constructor.
The solution is to stash the type away in yet another variable
and only u
ors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -Os
compilation failed to produce executable
... due to:
/tmp/cciVc43I.o:(.gnu.offload_vars+0x10): undefined reference to `A.12.4064'
[...]
..., which may be something like PR90779, PR85063, PR84592, PR90779,
PR80411,
Jelinek wrote:
> On Mon, Nov 01, 2021 at 06:25:45PM -0700, Thomas Rodgers via Gcc-patches
> wrote:
> > +template
> > + constexpr bool
> > + __maybe_has_padding()
> > + {
> > +#if __has_builtin(__has_unique_object_representations)
> > + r
Hi!
Ping, once more.
Grüße
Thomas
On 2021-10-14T12:12:41+0200, I wrote:
> Hi!
>
> Ping, again.
>
> Commit log updated for <https://gcc.gnu.org/PR102735>
> "privatization-1-compute.c results in both XFAIL and PASS".
>
>
> Grüße
> Thomas
>
Hi!
On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
> On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>> On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
>> wrote:
>>> --- /dev/null
>>> +++ b/gcc/diagnostic-spec.h
>>
>>> +typedef location_
Hi!
On 2021-11-09T11:54:04+0100, Richard Biener wrote:
> On Tue, Nov 9, 2021 at 11:28 AM Thomas Schwinge
> wrote:
>> On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
>> > On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>> >> On 2021-06-23T13:47:08-0600, Martin Se
Hi!
On 2021-10-17T16:33:03-0600, Jeff Law via Gcc-patches
wrote:
> On 9/30/2021 12:47 AM, Thomas Schwinge wrote:
>> On 2021-09-17T13:16:14+0200, I wrote:
>>> On 2021-09-10T09:48:56+0200, I wrote:
>>>> On 2021-09-03T18:33:37+0200, I wrote:
>>>>> On
Hi!
On 2021-09-03T21:16:46+0200, I wrote:
> On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
>> On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>>> On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
>>> wrote:
>>>> --- /dev/null
>>>> +++ b
>FOR_EACH_BB_FN (bb, cfun)
> {
> gimple_stmt_iterator gsi;
Given my recent commit 088199e5d0fc0d54f48af0783a2630a773bbb387
"Generalize 'gcc/input.h:struct location_hash'", OK to push the attached
"Use 'location_hash' for 'see
ptr == pos', like everywhere
else.
(That there are no diagnostics for malformed 'GOMP_OPENACC_DIM', is a
different topic, of course.)
>
>goacc_default_dims[i] = (int)val;
> - pos = eptr;
> + pos = (const char *) eptr;
> }
> }
Pushed to maste
contains '0-1', I get a FAIL:
[...]
OPENMP DISPLAY ENVIRONMENT BEGIN
_OPENMP = '201511'
OMP_DYNAMIC = 'FALSE'
OMP_NESTED = 'FALSE'
OMP_NUM_THREADS = '8'
OMP_SCHEDULE = 'DYNAMIC'
OMP_PROC_BIND = 'TRUE
Hi!
..., and here is another ping.
Grüße
Thomas
On 2021-11-08T11:45:12+0100, I wrote:
> Hi!
>
> Ping, once more.
>
>
> Grüße
> Thomas
>
>
> On 2021-10-14T12:12:41+0200, I wrote:
>> Hi!
>>
>> Ping, again.
>>
>> Commit log up
Hi!
Ping.
Grüße
Thomas
On 2021-11-09T15:18:44+0100, I wrote:
> Hi!
>
> On 2021-09-03T21:16:46+0200, I wrote:
>> On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
>>> On 9/1/21 1:35 PM, Thomas Schwinge wrote:
>>>> On 2021-06-23T13:47:08-0600, Marti
be it was for some earlier revision of these code
changes? Anyway, as it's all-PASS for all systems that I've tested on,
I've now pushed "Add 'libgomp.oacc-c-c++-common/loop-gwv-2.c'" to master
branch in commit 5a16fb19e7c4274f8dd9bbdd30d7d06fe2ef
and I've filed
<https://gcc.gnu.org/PR100678> "[OpenACC/nvptx]
'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in
certain configurations"... :-\
As it's not clear yet what the conditions are, I cannot come up with a
selector to (differently) XFAI
ture use (given that they've been tested to
work) or remove (as now unused, danger of bit-rot)?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
]
| ^
[...]/libgomp.oacc-fortran/privatized-ref-2.f90:27:30: note: ‘a’ declared
here
27 | integer, allocatable :: A(:)
| ^
I haven't looked into these.
Grüße
Thomas
-
Mentor Graphics
Hi!
On 2021-04-19T12:23:56+0100, Julian Brown wrote:
> On Thu, 15 Apr 2021 19:26:54 +0200
> Thomas Schwinge wrote:
>> This has iterated through several conceptually different designs and
>> implementations, by several people, over the past several years.
>
> I hope thi
e
aspects [PR90115]" to master branch in commit
f6f45309d9fc140006886456b291e4ac24812cea, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>F
tmt), ctx);
>
>block = make_node (BLOCK);
So, yes -- but then, apparently, that again got lost in a later version
of the patch. ;-)
I've pushed "[OpenACC privatization] Don't evaluate OpenMP 'for' clauses
[PR90115]" to master branch in commit
3a285ebd0cf5
s is a separate bug to be fixed.
I've pushed "[OpenACC privatization] Don't let unhandled
'IFN_UNIQUE_OACC_PRIVATE' linger [PR90115]" to master branch in commit
ff451ea723deb3fe8471eb96ac9381c063ec6533, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutsc
Hi!
On 2021-04-19T12:23:56+0100, Julian Brown wrote:
> On Thu, 15 Apr 2021 19:26:54 +0200
> Thomas Schwinge wrote:
>> On 2021-02-26T04:34:50-0800, Julian Brown
>> wrote:
>> > Two new target hooks are introduced:
>> > TARGET_GOACC_ADJUST_PRIVATE_DECL and TA
Hi!
On 2021-04-19T12:23:56+0100, Julian Brown wrote:
> On Thu, 15 Apr 2021 19:26:54 +0200
> Thomas Schwinge wrote:
>> As that may not be obvious to the reader, I'd like to have the
>> 'TREE_ADDRESSABLE' conditionalization be documented in the code. You
extern int e;
static int s;
[...]
#pragma acc parallel
{
#pragma acc loop gang private(e, s)
for ([...])
[...]
}
Is the idea that these are to be "properly privatized"? The gang-private
instances of 'e', 's' lose
927876c315d1fa706d9881
> Author: Thomas Schwinge
> Date: Fri May 21 08:51:47 2021 +0200
>
> [OpenACC privatization] Reject 'static', 'external' in blocks [PR90115]
Actually not that one, but instead one commit before is the culprit:
commit 11b8286a83289f
This is a remnant of poorly executed refactoring.
libstdc++-v3/ChangeLog:
* include/std/barrier (__tree_barrier::_M_arrive): Remove
unnecessary hasher instantiation.
---
libstdc++-v3/include/std/barrier | 1 -
1 file changed, 1 deletion(-)
diff --git a/libstdc++-v3/include/std/b
This cleans up the implementation of atomic_timed_wait.h and fixes the
accidental pessimization of spinning after waiting in
__timed_waiter_pool::_M_do_wait_until.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__wait_clock_t): Define
conditionally.
(__cond_wa
Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/deduction.cc: Add
reproducer case from PR.
---
libstd
Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/100889.cc: New test.
---
libstdc++-v3/include/bits/atomic_bas
zero on map clauses added implicitly for reduction clauses on combined
or composite constructs. They shall be removed if there is an explicit
map clause. */
#define OMP_CLAUSE_MAP_IMPLICIT(NODE) \
(OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_MAP)->base.default_
Fixes libstdc++/100889
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Extend
coverage of types tested.
---
libstdc++-v3/include/bits/atomic_ba
This time without the repeatred [PR] in the subject line.
Fixes libstdc++/100889
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (atomic_ref<_Tp*>::wait):
Change parameter type from _Tp to _Tp*.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Extend
cov
t ();
As obvious, pushed "[nvptx] Update comment in
'libgomp.oacc-c-c++-common/parallel-dims.c'" to master branch in commit
e64d62c7008e6a4b0227fd25e071db8f0b3f1820, see attached.
Grüße
Thomas
-----
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München
s.c'" to master branch in commit
0886426f5f543e813c1a61e18da6616caf377dfc, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From 088642
[string match "amdgcn*" $offload_target] } {
> +return 1;
> +}
> +return 0;
> +}
Pushed "[GCN] Streamline
'libgomp/testsuite/lib/libgomp.exp:check_effective_target_openacc_radeon_accel_selected'"
to master branch in commit f9da798ba6348feaa
#x27;" to master branch in commit
77f41a5c4e60a88533c90f0948b4dd24c9bb88b2, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From 77f41a5c4e60a88533c90f0948b4dd24c9bb8
601 - 700 of 5586 matches
Mail list logo
