OpenACC] Use proper location to 'inform' of
enclosing parent compute construct" to master branch in commit
fab72592d86d11b89a01f0f3c2c9c329d43466c1, and backported to
releases/gcc-10 branch in commit
a32d089dcf3edaa625e4871e78150b7d297cda5b, see attached.
Grüße
Thomas
-
Mentor G
From: Thomas Rodgers
Adds
libstdc++/ChangeLog:
* include/Makefile.am (std_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/std/barrier: New file.
* testsuite/30_thread/barrier/1.cc: New test.
* testsuite/30_thread/barrier/2.cc
From: Thomas Rodgers
IGNORE the previous version of this patch please.
Adds
libstdc++/ChangeLog:
* include/Makefile.am (std_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/std/barrier: New file.
* testsuite/30_thread/barrier/1.cc: New
> On Nov 4, 2020, at 10:52 AM, Jonathan Wakely wrote:
>
> On 04/11/20 10:41 -0800, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> IGNORE the previous version of this patch please.
>
> OK, but all my comments seem to apply to this one too.
>
> On Nov 4, 2020, at 10:50 AM, Jonathan Wakely wrote:
>
> On 04/11/20 09:29 -0800, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> Adds
>>
>> libstdc++/ChangeLog:
>>
>> * include/Makefile.am (std_headers): Add ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
> On Nov 4, 2020, at 11:54 AM, Stephan Bergmann wrote:
>
> On 07/10/2020 18:55, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>> New ctors and ::view() accessor for -
>> * basic_stingbuf
>> * basic_istring
ite] Enable column location checking for 'dg-optimized',
'dg-missed'" -- with or without the demonstrator
'gcc.dg/vect/nodump-vect-opt-info-1.c',
'gcc.dg/vect/nodump-vect-opt-info-2.c' changes, your call? (I still have
to run this through regression testin
pilation to fail). Thus, same as 'dg-message', these should use
'saved-dg-warning' instead of 'saved-dg-error', which will print: "(test
for *warnings*, line [...])". OK to change that after regression
testing?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
ially interested if
*additional* notes appear over time, as GCC evolves. It seemed somewhat
useful, but I'm not insisting on coupling the disabling of notes pruning
on 'dg-note' usage, so if anyone feels strongly about that, please speak
up.
TODO document (also 'dg-optimized'
.dg/goacc/loop-6.f95'" to master branch in commit
4dfa1789ab6560a69de22afe7982f372f598c5b8 and commit
52b74462176e4741ce1248c055e6bb1cb902c025, and backported to
releases/gcc-10 branch in commit 1288da82c0f239e81cc8474d320edb517a5754d1
and commit 594672c89dd4279fcf3b5a824d69b206ebf4b700, see attached.
Grüße
Thomas
ove OpenACC 'loop'
inside 'parallel' special-case code" to master branch in commit
4c27f900950ed0ecb2897a8931c5cc348b1980be, and backported to
releases/gcc-10 in commit f41ca73aa11f28ad7d847ac5bf7e07f8bc763721, see
attached.
Grüße
Thomas
-
Mento
es should automatically be
demoted into '{ dg-do compile }', but that would be wrong for link-time
ICEs. But can we "expect" the UNRESOLVED, and turn that into another
XFAIL? Aha, actually I see that for '{ dg-do link }', this seems to
behave as expected (no UNRESOLV
ed – I assume that's because the C
> testcase uses 'unsigned' which does not exist with Fortran.
>
> Committed as r11-4903-g1644ab9917ca6b96e9e683c422f1793258b9a3db
I'm confirming this fixes things for '-m32' -- but it also broke '-m64'.
;-)
Grüße
milar testsuite coverage with other pending
patches of mine.
> In principle, it should also have an effect on warnings (if there are
> any) and it unsurprisingly affects --fdump-tree-*-lineno.
>
> Comments, remarks, does it look good to you?
I have not verified all the details,
evant for releases/gcc-10 branch; the commit introducing that testcase
isn't there yet -- that's to be discussed in a different thread.)
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Gesch
ba078d9bcc3457d36ba12695cfef29eb3ca942, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
>From d1ba078d9bcc3457d36ba12695cfef29eb3ca
Hi!
I've pushed "Attach an attribute to all outlined OpenACC compute regions"
to master branch in commit 703e4f86496214e4915db898397fcd0ae1d955e0, and
backported to releases/gcc-10 branch in commit
40bf92be5b621318a43347236508696cc387f3a6, see attached.
Grüße
Thomas
-
Hi!
I've pushed "More explicit checking of which OMP constructs we're
expecting" to master branch in commit
bd7885755405bc9947ebe805a53d6100c78c8e82, and backported to
releases/gcc-10 branch in commit
00d4aa2128fd73b49e28c8a8c5fcb81150b640fe, see attac
t; items, but nevertheless: it's a good first step.
That's still the case... :-)
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
&
(lang_hooks.decls.get_generic_function_decl (current_function_decl)
!= NULL)
..., so thanks, Kwok, that you've figured that out. :-)
I've just pushed to master branch commit
ccd56db89806a5f6eb3be99fc3b4fe364cf35e98 "In
'gcc/omp-oacc-kernels-decompose.cc', use langhook i
ese tests be skipped or adjusted to not fail on other
> systems?
They are expected to work fine on all systems; they're not specific to
actual code offloading. So if something FAILs, we shall resolve it.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
Hi David!
While you were writing your email, I've also been busy:
On 2020-11-16T11:32:46-0500, David Edelsohn wrote:
> On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge
> wrote:
>> On 2020-11-15T15:47:15-0500, David Edelsohn wrote:
>> > I am seeing a number of new
This patch looks good to me.
It would be great to find a way to do a similar refactoring of
condition_variable.
> On Nov 12, 2020, at 9:07 AM, Jonathan Wakely via Libstdc++
> wrote:
>
> On 11/11/20 17:31 +, Jonathan Wakely wrote:
>> On 11/11/20 16:13 +, Jonathan Wakely wrote:
>>> This
you might consider
to add them as well. (I would exclude the error item, however.)
I have also added this as a test case.
Committed as r280063 (without the spaces at the end of the
lines that you pointed out in a separate mail).
Thanks for the review!
Regards
Thomas
omp.oacc-c-c++-common/host_data-7.c
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/host_data-5.F90
If I understand correctly that these two are testing the same things,
then please cross-reference them: "C/C++ variant of
'libgomp.oacc-fortran/host_data-5.F90'", "Fortran variant of
'libgomp.oacc-c-c++-common/host_data-7.c'.
If that makes sense to consider (now or later), as I see there's some
overlap in the 'gcc/omp-low.c:lower_omp_target' code paths: do we need
test cases to verify 'if_present' in combination with Fortran optional
arguments?
Grüße
Thomas
SET_INLINED'
already, to avoid again processing this in the second loop.
> If that makes sense to consider (now or later), as I see there's some
> overlap in the 'gcc/omp-low.c:lower_omp_target' code paths: do we need
> test cases to verify 'if_present' in combi
the libgomp plugins that don't implement OpenACC support.
>>> Maybe [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. ;-)
>>
&
t char *driver = acc_get_property_string (dev_num, dev_type,
> + acc_property_driver);
> + if (strcmp (expected_driver, driver))
> +{
> + fprintf (stderr, "Expected acc_property_driver to equal %s, "
> +"but was %s.\n", expected_driver, driver);
> + abort ();
> +}
> +
> + int unknown_property = 16058;
> + int v = acc_get_property (dev_num, dev_type,
> (acc_device_property_t)unknown_property);
> + if (v != 0)
> +{
> + fprintf (stderr, "Expected value of unknown numeric property to equal
> 0, "
> +"but was %d.\n", v);
> + abort ();
> +}
> +
> + int unknown_property2 = -16058;
> + const char *s = acc_get_property_string (dev_num, dev_type,
> (acc_device_property_t)unknown_property2);
> + if (s != NULL)
> +{
> + fprintf (stderr, "Expected value of unknown string property to be
> NULL, "
> +"but was %d.\n", s);
> + abort ();
> +}
> +
> +
> +}
Grüße
Thomas
signature.asc
Description: PGP signature
issue the
error during resolution.
Regression-tested. OK for trunk?
Regards
Thomas
2020-01-16 Thomas König
PR fortran/44960
* resolve.c (resolve_function): Issue error when a
function call contains a reference.
2020-01-16 Thomas König
PR fortran/
rmation for the reference (which we do not collect), I think this
is the best I can do.
So, OK for trunk (with the old ChangeLog)?
Regards
Thomas
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6f2a4c4d65a..a846677b770 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/reso
n see if I can also replace this with something more useful
(have to find the place where this is issued first, though).
Regards
Thomas
for trunk?
Regards
Thomas
2020-01-18 Thomas König
PR fortran/44960
* primary.c (gfc_match_rvalue): Break after setting MATCH_ERROR.
* resolve.c (resolve_function): Issue error when a
function call contains a reference.
2020-01-18 Thomas König
Regression-tested. OK for trunk?
Regards
Thomas
2020-01-19 Thomas König
PR fortran/85781
* resolve.c (resolve_substring): If the substring is empty, set it
to (1:0) explicitly.
2020-01-19 Thomas König
PR fortran/85781
* gfortran.dg/substr_
?
Regards
Thomas
... that one. As obvious, pushed Dominique's trunk r270390/commit
ef9387d8fe79219a106c3f9d6c6a87b0a9065d54 to releases/gcc-8 in
8e55f241ab8c754a2ab8ec2fe39afd9173589401 "pr89358_0.C: Replace dg-* with
dg-lto-*.", see attached.
Grüße
Thomas
>> PR lto/89358
>> * g++.dg/lto/pr89358_0
Hi Frederik!
On 2020-01-20T15:01:01+0100, "Harwath, Frederik"
wrote:
> I have attached a patch containing the changes that you suggested.
> On 16.01.20 17:00, Thomas Schwinge wrote:
>> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
>> wrote:
> Ok
From cfd3c2e2a49dd3e29b42baa0f22feffd4b346231 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 23 Jan 2020 21:54:44 -0800
Subject: [PATCH] Suppress deprecation warnings in tbb effective target check
TBB 2020 added deprecation warnings which produced output not expected by
Hi Tobias,
I hope my patch covers all issues. – OK for the trunk?
Yep.
Thanks a lot for the patch!
Regards
Thomas
er(acc_device_property) :: acc_get_property`,
| whereas in C/C++, it is `size_t`. For avoidance of doubt: it's correct
| to map the C/C++ `acc_device_property_t property` formal parameter to
| Fortran `integer(acc_device_property), value :: property`, but it's not
| clear w
#x27;gsi_insert_before'. Include a
test case that covers all relevant code paths; I've attached a test case
to the PR, but I've not verified whether "that covers *all* relevant code
paths". This should then be backported to all GCC release branches; I
can easily test the backp
trunk commit of the AMD GCN
offloading support, given that we did have it on the development branch.)
> Ok to commit this patch to master?
Thanks, OK. Reviewed-by: Thomas Schwinge
This also supersedes Tobias' earlier patch,
<http://mid.mail-archive.com/a1ae248c-ce70-f501-d421
0
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/acc_get_property.f90
> @@ -3,8 +3,6 @@
> ! of all device types mentioned in the OpenACC standard.
> !
> ! See also acc_get_property.c
> -! { dg-do run { target { { ! { openacc_host_selected } } && { ! {
> openacc_amdgcn_
Looks good to me, ok for trunk.
Thanks.
Jonathan Wakely writes:
> Fix synchronization issues in . Replace shared_ptr with
> _Stop_state_ref and a reference count embedded in the shared state.
> Replace std::mutex with spinlock using one bit of a std::atomic<> that
> also tracks whether a stop re
gma acc exit data delete ([data]) // no-op; S: 1, D: 0
} // copyout; S: 0, D: 0
assert (!acc_is_present ([data]));
(Haven't compiled but I'm reasonably sure that the nesting and my manual
"[action]; [S], [D]" annotations are correct. But please verify, if
cou
s 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 curio
YPE_GPU
> + || (support_cpu_devices && device_type == HSA_DEVICE_TYPE_CPU)))
> + return HSA_STATUS_SUCCESS;
> +
> + AGENT_GET_INFO (HSA_AGENT_INFO_NAME, name)
> + AGENT_GET_INFO (HSA_AGENT_INFO_VENDOR_NAME, vendor_name)
> +
> + SYSTEM_GET_INFO (HSA_SYSTEM_INFO_VERSION_MINOR, minor)
> + SYSTEM_GET_INFO (HSA_SYSTEM_INFO_VERSION_MAJOR, major)
> +
> + snprintf (driver, sizeof driver, "HSA Runtime %hu.%hu",
> + (unsigned short int)major, (unsigned short int)minor);
> +
> + expect_device_string_properties(acc_device_radeon, *dev_num,
> + vendor_name, name, driver);
> +
> + (*dev_num)++;
> +
> + return status;
> +}
> +
> +int main ()
> +{
> + int dev_num = 0;
> + test_setup ();
> +
> + hsa_status_t status =
> +hsa_iterate_agents_fn (&check_agent_properties, &dev_num);
> +
> + return status;
> +}
Grüße
Thomas
signature.asc
Description: PGP signature
Hi!
On 2020-01-30T16:45:39+, Andrew Stubbs wrote:
> On 30/01/2020 16:08, Thomas Schwinge wrote:
>> Andrew and Frederik, thanks for your emails reminding/educating me about
>> 'snprintf' as well as this HSA fixed-size buffer API. There doesn't
>> happen
Hi Frederik!
On 2020-01-31T13:17:52+0100, "Harwath, Frederik"
wrote:
> On 30.01.20 17:08, Thomas Schwinge wrote:
>
>> I understand correctly that the only reason for:
>>
>> On 2020-01-29T10:52:57+0100, "Harwath, Frederik"
>> wr
nning to use as a test case? You can put
multighreading programs into libgomp/testsuite/libgomp.fortran
where they will be executed.
Regards
Thomas
Hi Tobias,
OK? – And for which branches?
OK for all branches (assuming you checked with "make pdf" and
"make dvi").
Thanks for doing this - our documentation is not always quite
up to date...
Regards
Thomas
-- patch in testing.
Plus some more cleanup that fell out during analysis/development --
patches in testing.
Oh, and one of these actually (unintentially so) happens to resolve
<https://gcc.gnu.org/PR101204> "[12 Regression] infinite recursion in
gtype-desc.c since r12-1801-g7036e9ef462
gt; +
> +class GTY(()) string_concat_db
> +{
> +[...]
> + hash_map *m_table;
> +};
OK to push the attached
"Generalize 'gcc/input.h:struct location_hash'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
g/plugin/diagnostic-test-string-literals-1.c': for these, we do see
'BUILTINS_LOCATION' (via 'string_concat_db::record_string_concatenation').
Unless someone tell me that's unexpected (I'm completely lost in this
code...), I shall change/generalize my changes to prov
for 'Deleted'.
... I didn't do this, but instead would like to push the attached
"Don't record string concatenation data for 'RESERVED_LOCATION_P'"
(replacing "Harden 'gcc/input.c:string_concat_db::get_key_loc'" as
originally proposed).
Hi!
Martin, thanks for your review. Now need someone to formally approve the
third patch.
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:
>>> On 6/22/2
762cd, see
attached.
And, I've filed <https://gcc.gnu.org/PR102215>
"[GCN offloading] Missing '__atomic_compare_exchange_1' etc.".
Grüße
Thomas
> 2021-09-03 Jakub Jelinek
>
> * omp-expand.c (expand_omp_atomic_pipeline): Use
> IFN_ATOM
Hi!
Ping.
On 2021-09-03T21:16:46+0200, Thomas Schwinge wrote:
> Martin, thanks for your review. Now need someone to formally approve the
> third patch.
Again attached for easy reference.
Grüße
Thomas
> On 2021-09-01T18:14:46-0600, Martin Sebor wrote:
>> On 9/1/21
Hi!
Ping. My patches again attached, for easy reference.
Grüße
Thomas
On 2021-09-03T18:33:37+0200, I wrote:
> Hi!
>
> On 2021-09-02T21:09:54+0200, I wrote:
>> On 2021-09-02T15:59:14+0200, I wrote:
>>> On 2016-08-05T14:16:58-0400, David Malcolm wrote:
>>>>
Hi!
On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches
wrote:
> On 8/30/21 4:46 AM, Thomas Schwinge wrote:
>> Ping -- we still need to plug the memory leak; see patch attached, and/or
>> long discussion here:
>
> Thanks for answering my questions. I have no concerns
Hi!
Ping. Patch again attached for easy reference.
Plus, incrementally, the two "should we" questions cited below?
Grüße
Thomas
On 2021-08-24T12:23:07+0200, I wrote:
> Hi!
>
> On 2021-08-19T22:13:56+0200, I wrote:
>> On 2021-08-16T10:21:04+0200, Jakub Jelinek
e following bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269
No, not ICEs, but just "regular 'scan-tree-dump' FAILs". I suppose these
are all data-type mismatches: for example, 'long' or 'int *' not mapping
to the expected '8'
DATA" }
> +
> +!$acc end HOST DATA ! { dg-error "Unclassifiable OpenACC directive" }
Pushed to master branch commit 8b69c481fc86e04c6c83f3a49eef2760c175a8f2
"Add OpenACC 'host_data' testing to 'gfortran.dg/goacc/unexpected-end.f90'",
s
e on
our front page to the Internet ;-) -- OK to push to wwwdocs master branch
the attached "GNU Tools @ Linux Plumbers Conference 2021"?
Grüße
Thomas
> A total of 25 talks, lightning talks and BoFs plus our regular Q&A
> session with the GCC steering committee and Glibc, GDB
Hi!
On 2021-09-16T05:58:22+0200, Gerald Pfeifer wrote:
> On Wed, 15 Sep 2021, Thomas Schwinge wrote:
>>> The program for the GNU Tools Track at Linux Plumbers Conference is
>>> published:
>>>
>>> https://linuxplumbersconf.org/event/11/sessions/109/
From: Thomas Rodgers
Remove UB in atomic_ref/wait_notify test.
Signed-off-by: Thomas Rodgers
libstdc++-v3/ChangeLog:
PR libstdc++/101761
* testsuite/29_atomics/atomic_ref/wait_notify.cc (test): Use
va and vb as arguments to wait/notify, remove unused bb local.
Tested
we have a patch in the opposite direction: get rid of this dependency via
removing 'lang_env_dependencies = { module=libffi; cxx=true; };' from
'Makefile.def'. See
<http://mid.mail-archive.com/alpine.DEB.2.21..1812201344250.99920@build7-trusty-cs.sje.mentorg.com&g
Hi!
On 2021-09-10T09:48:56+0200, I wrote:
> Ping. My patches again attached, for easy reference.
Ping once again.
Grüße
Thomas
> On 2021-09-03T18:33:37+0200, I wrote:
>> Hi!
>>
>> On 2021-09-02T21:09:54+0200, I wrote:
>>> On 2021-09-02T15:59:14+0200, I w
Hi!
On 2021-09-10T10:00:25+0200, I wrote:
> On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches
> wrote:
>> On 8/30/21 4:46 AM, Thomas Schwinge wrote:
>>> Ping -- we still need to plug the memory leak; see patch attached, and/or
>>> long discussion here:
t; 32; i++)
> + {
> + int u = USES2(h,+);
> + w += u;
> + }
> +
> +printf ("w=%d\n", w);
> +/* { dg-output "w=2048(\n|\r\n|\r)" } */
Is there a reason for device-side 'printf' plus 'dg-output' matching
inste
Hi!
On 2021-09-17T15:03:18+0200, Richard Biener wrote:
> On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely wrote:
>> On Fri, 17 Sept 2021 at 13:08, Richard Biener
>> wrote:
>> > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge
>> > wrote:
>> > > On 2
From: Thomas Rodgers
Signed-off-by: Thomas Rodgers
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Do not match new _Sp_locker
constructor.
(GLIBCXX_3.4.30): Export _Sp_locker::_M_wait/_M_notify and new
constructor.
* include/bits
4" } */
... just without that directive, obviously.
Pushed to master branch commit 8251f90e87f67e09f5203e8edd77bfe73b68a54d
"Add 'libgomp.oacc-c-c++-common/broadcast-many.c'", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; A
RKER);
> +
> +/* No worker partitioning if we know the number of workers is 1. */
> +return worker_dim != 1;
>};
Pushed to master branch commit 82792cc407d7a7ab99f37e8501d19be2e6164e50
"openacc: Turn off worker partitioning if num_workers==1", see attached.
Grüße
T
deon_accel_selected } }
+*/
(Would be good to have test cases testing for the error conditions
handled in these changes here.)
The the clean-up items from my earlier email remain to be done still.
Pushed to master branch commit 2a3f9f6532bb21d8ab6f16fbe9ee603f6b1405f2
"openacc: Shared memor
shed to master branch commit 2961ac45b9e19523958757e607d11c5893d6368b
"openacc: Remove unnecessary barriers (gimple worker
partitioning/broadcast)", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München;
From: Thomas Rodgers
Let's try this one instead.
Signed-off-by: Thomas Rodgers
libstdc++-v3/ChangeLog:
* acinclude.m4: Update ABI version.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Do not match new _Sp_locker
constructor.
(GLIBCXX_3.4.30): Export _Sp_l
Hi!
On 2021-09-20T13:46:03+0100, Julian Brown wrote:
> On Fri, 17 Sep 2021 16:26:50 +0200
> Thomas Schwinge wrote:
>
>> > @@ -1449,8 +1634,120 @@ oacc_do_neutering (void)
>>
>> > + addr_range ar
>> > + = first_fit_range (
issing-include-dirs to the test config, I now only warn for
> -I and -J by default (similar to previous state) and only do a full
> warnings when the user requested passes the -Wmissing-include-dirs
> explicitly. The Fortran behavior is now also properly documented
> in the manual.
y has improper
> OpenACC privatization level: 'parm_decl'} "TODO4" { xfail *-*-* }
> l_compute$c_compute }
... etc. (also similarly in a handful of earlier commits, if I remember
correctly), why don't we do that programmatically, like in the attached
"Make
s to
'noconfigdirs' for '! test -d "$srcdir"/gcc/' (because that would also
disable them for host usage), I wonder if it'd make sense to turn all
existing 'target_libraries=[...]' and 'target_tools=[...]' assignments
and later amendments
From: Thomas Rodgers
This change implements P0528 which requires that padding bits not
participate in atomic compare exchange operations. All arguments to the
generic template are 'sanitized' by the __builtin_clear_padding intrinsic
before they are used in atomic compare_exch
; target_configdirs if we're not also building gcc.
Thanks, that looks better in line with how that script generally appears
to work (... per my not-in-depth understanding). (But I can't formally
approve.)
Reviewed-by: Thomas Schwinge
Grüße
Thomas
> commit 84c8b7f160
From: Thomas Rodgers
Now with checks for __has_builtin(__builtin_clear_padding)
This change implements P0528 which requires that padding bits not
participate in atomic compare exchange operations. All arguments to the
generic template are 'sanitized' by the __builtin_clearpaddin
27;ve
pushed to master branch commit a43ae03a053faad871e6f48099d21e64b8e316cf
'Further test case adjustment re "Fortran: Fix assumed-size to
assumed-rank passing"', see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesell
;
> + else
> + __builtin_printf ("ERROR: c_assumed num=%d: "
> + "x->dim[2].extent = %d != 0\n",
> + num, x->dim[2].extent);
> +}
> + else
> +assert (0);
... the 'ERROR:' prefixes printed do co
XFAIL: gfortran.dg/goacc/privatization-1-compute.f90 -O TODO4 {+at line
52+} (test for warnings, line 29)
PASS: gfortran.dg/goacc/privatization-1-compute.f90 -O TODO {+at line
53+} (test for warnings, line 29)
PASS: gfortran.dg/goacc/privatization-1-compute.f90 -O {+at lin
e quoted
>>>>> below), which will be useful elsewhere, so:
>>>>>> --- a/gcc/input.h
>>>>>> +++ b/gcc/input.h
>>>>>
>>>>>> +struct location_hash : int_hash { };
>>>>>> +
>>>>>> +clas
/19 10:29 AM, Thomas Schwinge wrote:
>> On 2018-12-03T10:50:44-0500, Pierre-Marie de Rodat
>> wrote:
>>> Matching front-end bits to support Acc_Kernels, Acc_Parallel,
>>> Acc_Loop and Acc_Data.
See here: <https://gcc.gnu.org/ml/gcc-patches/2018-12/>.
Grüße
Thomas
signature.asc
Description: PGP signature
make a decision (by means still to be determined).
- Put suitable Emacs/Vim configuration files into the source tree?
- Update coding style guidelines.
Grüße
Thomas
signature.asc
Description: PGP signature
clear description.
I suppose this hasn't been a problem for nvptx, as we're not
supporting/using the symbol aliasing machinery there.
> Tested on an x86_64 host with both NVPTX and GCN offloading. Okay to
> commit to trunk?
Yes, thanks. To record the review effort, please inc
it off on a by-file basis if they
don't want it.
OK for trunk?
Regards
Thomas
Introduce -finline-pack.
2019-12-07 Thomas Koenig
PR middle-end/91512
PR fortran/92738
* invoke.texi: Document -finline-pack.
* lang.opt: Add -finline
target.c:gomp_unmap_vars_internal' that we're not unmapping
'tgt' while it's still in use": the following 'tgt->list_count'
iterations as well as the following 'gomp_unref_tgt' would read 'free'd
memory. OK to commit? If approving this p
e a ticket at
<https://github.com/OpenACC/openacc-spec/issues> so this gets clarified.
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/optional-reduction.f90
> +! { dg-additional-options "-w" }
Why that?
Grüße
Thomas
signature.asc
Description: PGP signature
Hello world,
In the fix for PR 91783, I had not considered the case that
the _data ref could also be somewhere inside. The solution was
obvious and simple: Move the check into the loop over the refs.
Committed as r279086 after regression-testing.
Regards
Thomas
2019-12-08 Thomas
Hello world,
the attached patch fixes an ICE where a NULL check was missing.
Committed as obvious and simple after regression-testing as
r279087.
Since this is an ICE after an error has already been emitted,
I don't see any particular need to backport.
Regards
Thomas
2018-
Hello world,
yet another obvious and simple fix: You cannot really associate
the main program with a variable. Committed as r279088 after
regression-testing.
Regards
Thomas
2018-12-08 Thomas Koenig
PR fortran/92780
* resolve.c (resolve_assoc_var): Issue error if
> 1)
> - n->tgt->refcount--;
> - else
> - {
> - is_tgt_unmapped = true;
> - gomp_unmap_tgt (n->tgt);
> - }
> - }
> + is_tgt_unmapped = gomp_remove_var (devicep, n);
>
Hi!
See attached "Add 'libgomp.oacc-c-c++-common/host_data-6.c'", committed
to trunk in r279119.
Grüße
Thomas
From e5247d4a6930ca12fef2d38922cf6dbd9812da22 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Mon, 9 Dec 2019 11:40:08 +
Subject: [PATCH] Add 'libgomp.oa
Hi!
See attached "[PR92854] Add 'libgomp.oacc-c-c++-common/pr92854-1.c'",
committed to trunk in r279120, "to document the status quo", which does
match my understanding of the OpenACC 2.6 semantics.
Grüße
Thomas
From e14bd9d202bc4140d825a396ddaf64a5930ee3d1
Hi!
See attached "Add 'libgomp.oacc-c-c++-common/map-data-1.c'", committed to
trunk in r279121.
Grüße
Thomas
From 524aec42ea4d0a98fd6a0815e7573bf94fa70ee3 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Mon, 9 Dec 2019 11:40:27 +
Subject: [PATCH] Add 'libgomp.oac
501 - 600 of 5586 matches
Mail list logo
