nvptx.c
> +++ libgomp/plugin/plugin-nvptx.c
> @@ -546,6 +546,8 @@ nvptx_open_device (int n)
>ptx_dev->omp_stacks.size = 0;
> pthread_mutex_init (&ptx_dev->omp_stacks.lock, NULL);
>
> + ptx_dev->rev_data = NULL;
> +
>return ptx_dev;
Hi!
OK to push the attached patch to "Document 'distclean-stage[N]'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Fra
Hi!
Ping. For convenience, I've re-attached
"options: Clarify 'Init' option property usage for streaming optimization".
(I've re-verified: "No functional change; no change in generated files.")
Grüße
Thomas
On 2022-03-31T15:22:59+0200, I wrote:
>
.c',
'libgomp/testsuite/libgomp.oacc-fortran/routine-nohost-1.f90'.
'gcc/config/nvptx/nvptx.cc:nvptx_find_sese' doing
'fprintf (dump_file, "SESE regions:"); [...]', and that's scanned in:
libgomp/testsuite/libgomp.oacc-c-c++-common/nvptx-sese-1.c-/*
ble_length } } }
> } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect"
> { target { ! vect_multiple_sizes } xfail { vect_no_int_min_max || {
> aarch64_sve && vect_variable_length } } } } } */
> +/* { dg-final { scan-tree-dump "vector
; {
> tree c = omp_find_clause (gimple_omp_for_clauses (ctx->stmt),
... I've additionally run into a bootstrap error, and have now pushed
"Resolve '-Wsign-compare' issue in
'gcc/omp-low.cc:lower_rec_simd_input_clauses'"
to devel/omp/g
Hi!
On 2022-10-18T15:59:24+0100, Julian Brown wrote:
> On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge
> wrote:
>> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> ..., but to my surprised, that did fire in one occasion:
>>
>> > --- a/libgomp/testsuit
Hi!
On 2022-10-28T10:11:04+0200, I wrote:
> On 2022-10-18T15:59:24+0100, Julian Brown wrote:
>> On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge
>> wrote:
>>> On 2022-10-14T13:38:56+, Julian Brown wrote:
>>> ..., but to my surprised, that did fire
Hi!
On 2022-10-18T16:46:07+0200, Thomas Schwinge wrote:
> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> This patch prevents compiler-generated artificial variables from being
>> treated as privatization candidates for OpenACC.
>>
>> The rationale is that e.
to support expressions of
> some kind, but even then the expressions would get hairy.
I guess my confusion is why this then hasn't already previously be
FAILing for example for x86_64-pc-linux-gnu, which also is
'vect_multiple_sizes'? Anyway: "I've no clue about that
@@ -66,6 +69,65 @@ fwpa=
> LTO Driver RejectNegative Joined Var(flag_wpa)
> Whole program analysis (WPA) mode with number of parallel jobs specified.
>
> +
> +[LTODump option records]
> +
> +
> fresolution=
> LTO Joined
> The resolution file.
OK to push the attach
uble *)&reduced] = .GOACC_REDUCTION (TEARDOWN, 0, MEM
[(double *)&reduced], -1, 73, 0);
during GIMPLE pass: cfg
[...]/source-gcc/gcc/testsuite/c-c++-common/goacc/reduction-10.c:10:9:
internal compiler error: verify_gimple failed
(Same for C++ testing.)
Grüße
Thomas
> Diff:
>
;dg-xfail-run-if' for '-DACC_MEM_SHARED=0' (see above).
..., I've then pushed to master branch
commit 8c357d884b16cb3c14cba8a61be5b53fd04a6bfe
"Add 'libgomp.oacc-fortran/declare-allocatable-1.f90'", see attached.
Grüße
Thomas
-
Siemens Electr
ran 'allocatable' has new
> behavior".
> +! { dg-xfail-run-if TODO { *-*-* } { -DACC_MEM_SHARED=0 } }
> +
> +[...]
Getting rid of the "'dg-xfail-run-if' for '-DACC_MEM_SHARED=0'" via a
work around (as seen in real-world code), I've pu
e
> "Add 'libgomp.oacc-fortran/declare-allocatable-1-runtime.f90'"
> ... which is 'libgomp.oacc-fortran/declare-allocatable-1.f90' adjusted
> for missing support for OpenACC "Changes from Version 2.0 to 2.5":
> "The 'declare create
> +! host/device array descriptors.
> +! { dg-skip-if n/a { *-*-* } { -DACC_MEM_SHARED=1 } }
> +
> +!TODO-OpenACC-declare-allocate
> +! Missing support for OpenACC "Changes from Version 2.0 to 2.5":
> +! "The 'declare create' directive with a Fort
/* The only thing we expect to see here. */
> + assert ((kinds[i + k] & 0xff) == GOMP_MAP_POINTER);
> + }
> +
> + /* Given that 'goacc_exit_data_internal'/'goacc_exit_datum_1'
> + will always see
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-06T21:20:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-27T17:48:46+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-06T21:20:38+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-27T17:48:58+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:12:47+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:13:42+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:38+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
dron 2022", see attached.
See you in less than two weeks!
Grüße
Thomas
>From b465e8f1f72a0718aebcf483a78b68c3e68ead72 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Fri, 2 Sep 2022 21:39:18 +0200
Subject: [PATCH] GNU Tools Cauldron 2022
---
htdocs/index.html | 4
1 file
gram main
> + implicit none (type, external)
> + integer :: j
> + integer, allocatable :: A(:)
> +
> + A = [(3*j, j=1, 10)]
> + call foo (A, size(A))
> + deallocate (A)
> +contains
> + subroutine foo (array, nn)
> +integer :: i, nn
> +integer :: array(nn
ize;
> + if (gangprivate_hwm > gang_local_size_opt)
> + error ("gang-private data-share memory exhausted (increase with "
> +"-mgang-local-size=)");
> }
> }
In a new case (to be discussed later), we're running into this erro
7;ve currently not been doing OpenACC privatization scanning in
'libgomp.oacc-fortran/print-1.f90', which I've now added, to help
document the issue; no need to review that.
Of course, the issue could alternatively be fixed by adding more logic to
the GCN back end to auto-scale the al
atal error: Asynchronous queue error
Runtime message: HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION: The agent
attempted to access memory beyond the largest legal address.
..., and I still get that if lowering the allocation to the minimum,
'-foffload-options=amdgcn-amdhsa=-mgang-private-si
Hi Tom!
On 2022-04-08T09:35:44+0200, Tom de Vries wrote:
> On 4/8/22 00:27, Thomas Schwinge wrote:
>> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
>>> Especially for distributions it is undesirable to need to have proprietary
>>> CUDA libraries and headers
>
>> For avoidance of doubt, [an earlier] change doesn't affect (build-tree)
>> testsuite
>> usage, where we have:
>>
>> libgomp/testsuite/libgomp-test-support.exp.in:set hsa_runtime_lib
>> "@HSA_RUNTIME_LIB@"
>>
>> libgomp/testsu
LDFLAGS"
>>> + PLUGIN_HSA_LIBS="-ldl"
>>
>> So this switched from directly linking against 'libhsa-runtime64.so' to a
>> 'libdl'-based runtime linking variant.
>
> (Not intending to change anything regarding that.)
>
> Gi
Hi Tom!
On 2022-04-06T11:57:57+0200, Tom de Vries wrote:
> On 4/5/22 17:14, Thomas Schwinge wrote:
>> Regarding the following:
>>
>> On 2022-03-30T14:27:41+0200, Tom de Vries wrote:
>>> The -mptx flag has been added to specify the PTX ISA
>>> ver
his via 'dlopen', and not directly link GCC
against 'libcuda.so' etc.: so that the GCC build may also be used on a
system where no 'libcuda.so' is available.
So -- sorry ;-) -- that's not a show-stopper for removing the
'--with-cuda-driver' etc. '
that's in fact not the problem/cure here.
OK to push to the relevant branches the attached
"Make 'c-c++-common/goacc/kernels-decompose-pr100400-1-*.c' behave
consistently, regardless of checking level"?
Grüße
Thomas
-
Siemens Electronic Design Automati
Hi Richard!
On 2022-05-03T09:17:52+0200, Richard Biener wrote:
> On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge
> wrote:
>> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc wrote:
>> >> On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc wrote:
>> >>
>&
Hi Richard!
On 2022-05-03T12:53:50+0200, Richard Biener wrote:
> On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge
> wrote:
>> On 2022-05-03T09:17:52+0200, Richard Biener
>> wrote:
>> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge
>> > wrote:
>> &
.pred %r_do_abort;
+mov.pred %r_do_abort,0;
+setp.ne.b32 %r_do_abort,%r_act,0x;
+@ %r_do_abort trap;
+@ %r_do_abort exit;
+}
+bar.sync 0;
// join 2;
ret;
}
Do the 'trap/'exit' "no-return" calls allow for optimizing JIT register
Hi!
Ping.
Grüße
Thomas
On 2022-04-28T15:45:20+0200, I wrote:
> Hi Tom!
>
> On 2022-04-08T09:35:44+0200, Tom de Vries wrote:
>> On 4/8/22 00:27, Thomas Schwinge wrote:
>>> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
>>>> Especially for distributio
Hi!
Ping^2.
Grüße
Thomas
On 2022-04-28T15:48:13+0200, I wrote:
> Hi!
>
> Ping.
>
> On 2022-04-06T11:20:47+0200, I wrote:
>> On 2021-01-14T15:50:23+0100, I wrote:
>>> I'm raising here an issue with HSA libgomp plugin code changes from a
>>> while a
Hi!
Right in time for the GCC 12.1 release -- yay \o/ -- I've pushed
to wwwdocs commit c6a7f816f3531d5727674620d74818fe1d150467
"GCC 12: OpenACC", see attached.
Online: <https://gcc.gnu.org/gcc-12/changes.html#openacc>.
Grüße
Thomas
-
Siemens Electronic D
; + allocate (aaa(-4:10,-3:8,2))
> + aaa(:,:,:) = reshape ([(i, i = 1, size(aaa))], shape(aaa))
> +
> + do i = 0, omp_get_num_devices()
> +!$omp target data map(to: aaa)
> + call test_addr (aaa, i)
> + call test_ptr (aaa, i)
> +!$omp end target data
> + end
Hi!
On 2022-05-03T15:46:43+0200, Richard Biener wrote:
> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge
> wrote:
>> On 2022-05-03T12:53:50+0200, Richard Biener
>> wrote:
>> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge
>> > wrote:
>> >
; Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
> "libgomp GCN plugin: Clean up unused references to system-provided HSA
> Runtime library"?
With that done, I've then pushed to master branch
commit 91a6dcd14915181b4bce51cd44b56a3e9f9d35d8 &q
Hi!
On 2022-04-06T12:02:08+0200, Thomas Schwinge wrote:
> On 2021-01-14T15:50:23+0100, I wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago. While HSA is now no longer relevant for GCC master branch,
>> the same code has als
is built, 0 if not.])
Later also cargo-culted for other libgomp plugins, where the same
"unused" reasoning applies likewise.
Pushed to master branch commit edbd2b1caaa79d68467418a4571c3b09f9602805
"libgomp plugins: Don't 'AC_SUBST' and 'AC_DEFINE_UNQUOTED' for
Hi!
Another ping -- Jakub maybe? This is a simple refactor; no change in
behavior. I'll soon post further patches depending on this.
Grüße
Thomas
On 2022-05-05T21:18:47+0200, I wrote:
> Hi!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-04-28T15:45:20+0200
port dynamic loading schemes different from 'dl.so'/'dlopen'. ;-)
(But I'm not working on that.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsfüh
#x27;re actually (a) meaningful and (b)
(possibly) non-empty, so I've clarified that, pushed to master branch
commit 1f89e48789d230c78ec60ff3dc9e7e2478cc3df9 "libgomp nvptx plugin:
Only consider '--with-cuda-driver=[...]' when applicable", see attached.
Grüße
Thomas
--
Hi!
On 2022-04-29T15:48:03+0200, I wrote:
> On 2022-04-06T11:57:57+0200, Tom de Vries wrote:
>> On 4/5/22 17:14, Thomas Schwinge wrote:
>>> Regarding [...]
>>> Now, consider doing a GCC/nvptx offloading build with
>>> '--with-cuda-driver' [...]
&
Hi!
Ping.
Grüße
Thomas
On 2022-05-10T16:03:12+0200, I wrote:
> Hi!
>
> On 2022-05-03T15:46:43+0200, Richard Biener
> wrote:
>> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge
>> wrote:
>>> On 2022-05-03T12:53:50+0200, Richard Biener
>>> wr
'extern "C"'", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gese
include/cuda/cuda.h': Add parts necessary for nvptx-tools 'nvptx-run'",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heu
0001-Add-support-for-C-2a-stop_token.patch
Description: le patch
e 0
unexpectedly exited with code 0".
So non-OpenACC code paths seem to be negatively affected in some way?
Hopefully that'll go away when backing out the 'VREFCOUNT_LINK_KEY'
etc. changes, as discussed elsewhere. (I can easily test patches for
you, no need for you to set up Intel MIC (emulated) offloading testing.)
Grüße
Thomas
signature.asc
Description: PGP signature
From 56b78956a003b91e538cd5c680d614fdaee9c9eb Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Wed, 23 Oct 2019 12:32:31 -0700
Subject: [PATCH] Add C++20 jthread type to
---
libstdc++-v3/ChangeLog| 8 +
libstdc++-v3/include/std/stop_token | 14
Thomas Rodgers writes:
Let's try this again.From 23e1c9402cc15666d099fd61b58a0019181a9115 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Tue, 22 Oct 2019 17:53:00 -0700
Subject: [PATCH] Add support for C++2a stop_token
* include/Makefile.am: Add header.
* include/Makefi
)
..., with the patch applied, this doesn't get any diagnostic anymore, so
wrong-code gets generated.
Grüße
Thomas
> gcc/c/
> * c-parser.c (c_parser_omp_variable_list): New c_omp_region_type
> argument. Use it to speciali
Hi Frederik and Jakub!
On 2019-10-21T09:08:28+0200, "Harwath, Frederik"
wrote:
> OpenACC requires that, if a variable is used in reduction clauses on two
> nested loops, then there
> must be reduction clauses for that variable on all loops that are nested in
> between the two loops
> and all t
e GOVD_FIRSTPRIVATE also for "kernel"
Thanks!
> The patch survived bootstrapping + regtesting on my laptop (no
> offloading) and on a build server (with nvptx offloading).
OK for trunk, with the following few small items considered. To record
the review effort, please include
.h' would be generated.
Please find attached a patch with rationale. OK to commit? If approving
this patch, please respond with "Reviewed-by: NAME " so that your
effort will be recorded in the commit log, see
<https://gcc.gnu.org/wiki/Reviewed-by>.
Grüße
Thomas
From
.
(Really, the changes needed are quite trivial, and the code is in fact
invalid. I actually wrote the patch for LAPACK which removed all the
fallout from their TESTING routines; it didn't take long).
Regards
Thomas
> @@ -0,0 +1 @@
> +! { dg-do run }
> --- a/libgomp/testsuite/libgomp.fortran/use_device_addr-2.f90
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-2.f90
> @@ -0,0 +1 @@
> +! { dg-do run }
On powerpc64le-unknown-linux-gnu without offloading, I'm seeing (only)
the '-O0' execution tests FAIL for both these, with 'STOP 1' message.
Grüße
Thomas
signature.asc
Description: PGP signature
:
>> >
>> > unless somebody comes up with something clever over the weekend...
>>
>> Nothing clever, but something rare like BImode is probably safer than
>> SImode, in case doing this masks real "uninitialised" uses in future.
>
> Ick, and I forgot t
Hi!
On 2019-10-30T12:19:28+0100, Jakub Jelinek wrote:
> On Wed, Oct 30, 2019 at 11:57:12AM +0100, Thomas Schwinge wrote:
>> ..., and when building gcc-9-branch with
>> '--enable-checking=yes,extra,rtl' (apparently I'm the only one doing
>> that, huh?), runs in
-pc-linux-gnu.
>> Is it OK for trunk?
>
> OK.
The very same problem existed since the beginning of D language support
in GCC, so I backported this to gcc-9-branch in r277611 "[LIBPHOBOS] Fix
multi-lib RUNTESTFLAGS handling", see attached.
Grüße
Thomas
From 2dba914d0a00623209ce8f9
Hi!
Just for posterity.
On 2019-04-20T23:22:31+0200, Iain Buclaw wrote:
> On Sat, 20 Apr 2019 at 22:30, Thomas Schwinge wrote:
>> On Tue, 18 Sep 2018 02:39:46 +0200, Iain Buclaw
>> wrote:
>> > This patch adds the configure and make files used for building D
>>
Hi Tobias,
OK for the trunk and GCC 9?
As far as I can see, this looks good.
So, OK for trunk. If it later turns out that there are problems
caused by this, I suspect we will hear about them soon enough :-)
Thanks for taking this on!
Regards
Thomas
ing it with generic and/or
well-explained code.
Question, for my understanding:
> On Mon, 21 Oct 2019 16:14:11 +0200
> Thomas Schwinge wrote:
>> On 2019-10-03T09:35:04-0700, Julian Brown
>> wrote:
>> > @@ -577,17 +551,14 @@ present_create_copy (unsigned
h -O2 there.
OK for trunk/9/8?
Regards
Thomas
2019-11-02 Thomas Koenig
PR fortran/92133
* trans-decl.c (gfc_get_symbol_decl): If __def_init actually
contains a value, put it into the read-only section.
Index: trans-d
ublesome that a segfaulting
> testcase isn't caught by the testsuite.
It certainly is, but I have no solution for this at the moment.
Thanks for the review!
Regards
Thomas
Hi Tobias,
I think this is also OK for gcc 9. Backporting regression fixes should always
be all right under normal circumstances.
Regards
Thomas
Hi Frederik!
On 2019-10-29T13:20:53+0100, "Harwath, Frederik"
wrote:
> On 24.10.19 16:31, Thomas Schwinge wrote:
>> So just C/C++ testing, no Fortran at all. This is not ideal, but
>> probably (hopefully) acceptable given that this is working on the middle
>> en
tgt->list[i].offset = OFFSET_INLINED;
> + tgt->list[i].length = sizes[i];
> + tgt->list[i].copy_from = false;
> + tgt->list[i].always_copy_from = false;
> + break;
>
was right
that this patch doesn't have sufficient test coverage at all. Or, I'm
completely confused -- we still have that option, too. ;-\
Grüße
Thomas
From 38fcb35dcb98b0fd709db72896455895243d8e54 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 6 Nov 2019 13:39:12 +0100
S
bfuscated layout/rendering
source code (as far as I understand), not really in spirit of its GPL
license? (But I'm not a lawyer, of course.)
So I guess I'm just curious why it's now coming back.
Grüße
Thomas
signature.asc
Description: PGP signature
Hi Chung-Lin!
On 2019-11-05T22:35:43+0800, Chung-Lin Tang wrote:
> Hi Thomas,
> after your last round of review, I realized that the bulk of the compiler
> omp-low work was
> simply a case of dumb over-engineering in the wrong direction :P
> (although it did painstakingly fun
Hi,
I just committed the patch below as obvious to fix a 9/10 regression
when directly calling BLAS routines for matmul. Will backport
to gcc-9 soon.
Regards
Thomas
Commit symbol for external BLAS routine when translating MATMUL to *GEMM.
2019-11-09 Thomas Koenig
PR
make a note in https://gcc.gnu.org/gcc-10/changes.html ?
Regards
Thomas
ortant
enough.
Grüße
Thomas
From 5ba7804033a285907cfda88c9de5acc103c9881a Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Mon, 11 Nov 2019 08:05:27 +
Subject: [PATCH] [build] Properly track GCC language configure fragments
The 'gcc/configure' script sources all 'gcc/*/config-lang.
Hi!
On 2019-10-16T18:52:55+0200, Jakub Jelinek wrote:
> On Wed, Oct 16, 2019 at 03:22:52PM +0200, Thomas Schwinge wrote:
>> Stumbled over this while reviewing Julian's "Factor out duplicate code in
>> gimplify_scan_omp_clauses":
>
Hi!
On 2019-05-29T09:50:42-0600, Jeff Law wrote:
> On 5/29/19 8:32 AM, Thomas Schwinge wrote:
>> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin wrote:
>>> I have left Intel 3 years ago. If you have any questions regarding MIC
>>> offloading, you can reach me by iver..
e_device_ptr-1.f90
As obvious; see attached, committed "Torture testing:
'libgomp.fortran/use_device_addr-3.f90',
'libgomp.fortran/use_device_addr-4.f90',
'libgomp.fortran/use_device_ptr-1.f90'" to trunk in r278044.
Grüße
Thomas
From d7a5b0d74344
Hi!
On 2019-10-30T16:48:43+0100, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/target9.f90
As obvious; see attached, committed "Torture testing:
'libgomp.fortran/target9.f90'" to trunk in r278045.
Grüße
Thomas
From d462cbc6c48994
Hi Tobias!
By the way, do you know what's the status is for Fortran common blocks in
OpenMP: supported vs. expected per the specification?
On 2019-10-25T16:36:10+0200, Tobias Burnus wrote:
> On 10/25/19 10:43 AM, Thomas Schwinge wrote:
>> Or, would it be easy to add an OpenACC
tc., plus a few
more things, see my comments in the patch review below.
To record the review effort, please include "Reviewed-by: Thomas Schwinge
" in the commit log, see
<https://gcc.gnu.org/wiki/Reviewed-by>.
I'm working on an additional patch to handle 'serial
'{ dg-do run }' for torture testing (please remember to), I
see the '-O0' and '-O1' execution testing FAIL, complaining that
"libgomp: use_device_ptr pointer wasn't mapped".
Grüße
Thomas
> @@ -0,0 +1,33 @@
> +! Check whether absent optional
optimization by the middle-end easier.
I left in the parts for debugging that I added for this patch.
Seeing the difference between EXEC_INIT_ASSIGN and EXEC_ASSIGN was
particularly instructive.
Regression-tested. OK for trunk?
Regards
Thomas
Index: dump-parse-tree.c
Am 11.11.19 um 22:55 schrieb Thomas König:
Regression-tested. OK for trunk?
Of course, better with a ChangeLog entry.
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping
a procedure
if it will be called with an explicit interface or not.
The user can always add an interface block for a stand-alone procedure.
Regards
Thomas
Hi Janne,
> Ah, of course. I should have said module procedures. Or even module
> procedures without bind(C)?
It would probably be the latter.
The change would actually be rather small: If conditions are met, just add
attr.value for INTENT(IN).
This is something we should probably do when we a
Hi Tobias,
> On 11/12/19 1:42 PM, Thomas König wrote:
>>> Ah, of course. I should have said module procedures. Or even module
>>> procedures without bind(C)?
>> It would probably be the latter. The change would actually be rather small:
>> If conditions are me
The attached patch should be a complete implementation of C++20
stop_token, jthread, and changes to condition_variable_any which also
addresses the comments on the previous patch.
From 2cdaa367ed919b24f3bbb84d6f7391a350dce77b Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Wed, 13 Nov 2019
Hi!
On 2020-10-30T12:25:38+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Fri, Oct 30, 2020 at 12:22:31PM +0100, Thomas Schwinge wrote:
>> Turns out that GCC PR85303 "[testsuite, libgomp] dg-message not
>> supported" is the very same problem as (the libgomp aspect of)
Hi Tobias!
On 2020-10-30T12:16:05+0100, Tobias Burnus wrote:
> On 30.10.20 11:47, Thomas Schwinge wrote:
>>>> Fixed by introducing a new function; now one only needs to make sure
>>>> that no new code will re-introduce "lb->location":-)
>> .
Hi Tom!
On 2020-10-30T17:32:56+0100, Tom de Vries wrote:
> On 10/30/20 5:16 PM, Thomas Schwinge wrote:
>> OK to simplify and enhance the
>> testcases as attached, "Simplify and enhance
>> 'libgomp.oacc-c-c++-common/pr85486*.c' [PR85486]"?
>
> Ye
From: Thomas Rodgers
Changes implementation to use a private __mutex type as discussed on
IRC.
libstdc++/ChangeLog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include
From: Thomas Rodgers
IGNORE the previous patch.
Changes implementation to use a private __mutex type as discussed on
IRC.
libstdc++/ChangeLog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header
More precise diagnostics for 'gang',
'worker', 'vector' clauses with arguments on 'loop' only allowed in
'kernels' regions" to master branch in commit
beddd1762ad2bbe84dd776c54489153f83f21e56, and backported to
releases/gcc-10 in commit 8d09f4900
location information for OpenACC
'gang', 'worker', 'vector' clauses with argument [PR92793]" to master
branch in commit 41f7f6178e2d35288273656dc55dae8fcf3edeb5, and backported
to releases/gcc-10 in commit 5ceaf8a54abb3f9bd3c268fe420999a7962b2a15,
see attached.
Grüße
Thomas
or inconsistent nested
'reduction' clauses checking" to master branch in commit
fedf3e94efe774b8c0539d344130a7b25f50a881, and backported to
releases/gcc-10 branch in commit
eeeb6833d2c6bcc0e675928f17a75efb41eeaf13, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnul
for (k = 0; k < 10; k++)
>> + sum = 1;
Getting these diagnostics consistent is easy enough, however. I've
pushed "[OpenACC] Enable inconsistent nested 'reduction' clauses checking
for OpenACC 'kernels'" to master branch in commit
64dc14b1a764bd3059170431c9b43c6192dbd48f,
401 - 500 of 5586 matches
Mail list logo
