A;
> + if (code->ext.omp_clauses->lists[OMP_LIST_USE_DEVICE] == NULL)
> + {
> + error_at (gfc_get_location (&code->loc),
> + "% construct requires % clause");
> + return NULL_TREE;
> + }
>
on test
[-PASS:-]{+FAIL:+} libgomp.c/target-51.c output pattern test
... due to:
Output was:
libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device cannot be used
for offloading
Should match:
.*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device not found.*
Grüße
is where this GCC/Rust code has been copied from, so I suggest
you push both patches at once.
Grüße
Thomas
> ---
> gcc/rust/rust-object-export.cc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/rust/rust-object-export.cc b/gcc/rust/rust-object-
Hi!
On 2023-06-19T10:02:58+0200, Tobias Burnus wrote:
> On 16.06.23 22:42, Thomas Schwinge wrote:
>> I see the new tests PASS, but with offloading enabled (nvptx) also see:
>>
>> PASS: libgomp.c/target-51.c (test for excess errors)
>> PASS: libgomp.c
/expr.cc:10446
0x941803 expand_gimple_stmt_1
[...]/gcc/cfgexpand.cc:3984
0x941803 expand_gimple_stmt
[...]/gcc/cfgexpand.cc:4044
0x942eba expand_gimple_basic_block
[...]/gcc/cfgexpand.cc:6096
0x9453d3 execute
[...]/gcc/cfgexpand.cc:6831
That&#
form' to
point to the 'data' construct's 'default' clause? (But not sure if
that's easily done; otherwise don't.)
Similar to the ones you've already got, please also add a few test cases
for nested 'default' clauses, like:
#pragma acc data // no vs. 'default(none)' vs. 'default(present)'
{
#pragma acc data // no vs. same vs. different 'default' clause
{
#pragma acc data // no vs. same vs. different 'default' clause
{
#pragma acc parallel
Similarly, test cases where 'default' on the compute construct overrides
'default' of an outer 'data' construct.
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 Gesellschaft: München; Registergericht
München, HRB 106955
MACHINE_MODE <= 256 assumption.
Thanks to Jakub and Richard for guidance re the offloading compilation
case, where we've got different 'MAX_MACHINE_MODE's between stream-out
and stream-in, and a modes mapping table.
However, with this patch, there are ICEs all over the pl
gt; FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c (test for excess
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c (internal compiler
> error: tree check: expected none of vector_type, have vector_type in
> divmod_candidate_p, at tree-ssa-math-opts.cc:499
x27;s between stream-out
> and stream-in, and a modes mapping table.
>
> However, with this patch, there are ICEs all over the place... I'm
> having a look.
Your patch has all the right ideas, there are just a few additional
changes necessary. Please merge in the attached
"
so it's a little odd that it specifies which register allocator it doesn't
>> use.
>>
>> I hope this helps,
>
> It does. Consider a patch which flips the nvptx port to LRA as
> pre-approved.
Pushed to master branch commit f7e3123638712773e8c01e17aae9dc64d9342016
signed char *mode_table', and adjust all users.
I've split this out as a preparational "no change in behavior" patch; is
"LTO: Capture 'lto_file_decl_data *file_data' in 'class lto_input_block'"
OK to push, see attached?
Grüße
Thomas
---
Hi!
On 2023-06-30T01:39:39+, "Li, Pan2" wrote:
> That’s very cool, thanks Thomas for help!
:-)
> Let’s wait the AMD test running result for the final version of the patch.
That's all looking good, too.
> From: juzhe.zh...@rivai.ai
> Sent: Friday, June 30, 2023
, here?
In particular, the 'lto_mode_identity_table' changes would seem necessary
to keep standard LTO ('-flto') functional for large 'machine_mode' size?
Bernhard: Fancy writing a Coccinelle check whether there are any more
places where we put what originally was a
lready does have
a fixed underlying type -- but apparently it does not, so defaults to
'unsigned int'!
(gdb) ptype lto_mode_identity_table
type = const enum machine_mode : unsigned int {E_VOIDmode, E_BLKmode,
E_CCmode, [...], NUM_MACHINE_MODES = 130} *
So, yeah, should we fix that, and then generally use 'enum machine_mode'
instead of 'char' vs. 'short'? (Or, which other "detail" do I fail to
recognize this time?)
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 Gesellschaft: München; Registergericht
München, HRB 106955
7;gcc/lto/lto-common.cc:lto_mode_identity_table'. Should this turn into
'ENUM_BITFIELD (machine_mode)' ("native size") or
'ENUM_BITFIELD (machine_mode) : MACHINE_MODE_BITSIZE' (space-optimized)?
Grüße
Thomas
-----
Siemens Electronic Design Automa
hat handling of embedded NULs falls out of that, automatically).
For reference, this 'len' field has existed "forever". Before
'struct ht_identifier' was added in
commit 2a967f3d3a45294640e155381ef549e0b8090ad4 (Subversion r42334), we
had in 'gcc/cpplib.h:st
- enum gt_types_enum type ATTRIBUTE_UNUSED)
> + size_t size, bool is_string ATTRIBUTE_UNUSED)
> {
>unsigned order;
>char *result;
..., but left in other 'ATTRIBUTE_UNUSED's.
To enable another thing I'm working on, OK to push the attached clea
gt; +struct GTY(()) non_terminated_string @{
> + size_t sz;
> + const char * GTY((string_length ("%h.sz"))) data;
> +@};
> +@end smallexample
In preparation for another thing I'm working on, OK to push the attached
"GTY: Explicitly reject 'string_length'
Hi!
On 2023-07-04T15:56:23-0400, Lewis Hyatt via Gcc-patches
wrote:
> On Tue, Jul 4, 2023 at 11:50 AM Thomas Schwinge
> wrote:
>> I came across this one here on my way working through another (somewhat
>> related) GTY issue. I generally do understand the issue here, but do
E_POINTER
> - && (nt->kind == TYPE_POINTER
> - || nt->kind == TYPE_STRING));
> -[...]
OK to push the attached
"GTY: Clean up obsolete 'bool needs_cast_p' field of 'gcc/gengtype.cc:struct
w
use_param_2,... use_params) GTY
> - options. */
>TYPE_USER_STRUCT /* User defined type. Walkers and markers for
> this type are assumed to be provided by the
> user. */
OK to push the attached
"GTY:
s use_param, if_marked and splay tree
allocators",
which reciprocally missed corresponding clean-up.
OK to push the attached
"GTY: Repair 'enum gty_token', 'token_names' desynchronization"?
On top of that, I'll then re-submit an adjusted
<http
this type are assumed to be provided by the
>> user. */
>
> OK to push the attached
> "GTY: Clean up obsolete parametrized structs remnants"?
Updated per
<https://inbox.sourceware.org/87jzveu08y@euler.schwinge.homeip.net>
"GTY
Hi!
OK to push the attached
"GGC, GTY: Tighten up a few things re 'reorder' option and strings"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsfüh
GTY: No pointer walking for 'atomic' in PCH 'gt_pch_note_object'"?
Appreciate review from a GGC, GTY-savvy person.
This depends on
<https://inbox.sourceware.org/87edlmtjwh@euler.schwinge.homeip.net>
"GGC, GTY: Tighten up a few things re 'reorder' option and st
m_S', so doesn't get the special string
handling, and this 'gt_pch_nx' doesn't call 'gt_pch_n_S' and also doesn't
'gt_pch_note_object' manually, so I wonder how that ever worked? So
maybe these two in fact never were used? Should we dare to put in
need somebody
for the non-Fortran parts.
Jakub, could you maybe take a look?
Best regards
Thomas
much as feasible -- which I don't know whether or
to which extent it is).
Grüße
Thomas
> PR rust/111899
>
> gcc/rust/ChangeLog:
>
> * backend/rust-constexpr.cc (potential_constant_expression_1):
> Remove NON_DEPENDENT_EXPR handling.
>
27;if' clause without and with modifier"?
That makes an upcoming change a bit lighter.
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, F
Hi!
Ping.
Grüße
Thomas
On 2023-09-12T12:58:27+0200, I wrote:
> Hi!
>
> On 2020-04-20T14:18:40+0100, "Maciej W. Rozycki via Gcc-patches"
> wrote:
>> Fix a problem with the libffi testsuite using a method to determine the
>> compiler to use resulting in the
Hi!
Ping.
Grüße
Thomas
On 2023-09-12T13:03:28+0200, I wrote:
> Hi!
>
> On 2020-04-04T00:00:44+0100, "Maciej W. Rozycki via Gcc-patches"
> wrote:
>> Fix a problem with the libatomic testsuite using a method to determine
>> the compiler to use resulting in
Hi!
Ping.
Grüße
Thomas
On 2023-09-19T10:47:56+0200, I wrote:
> Hi!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2023-09-08T14:02:50+0200, I wrote:
>> Hi!
>>
>> On 2017-08-10T15:42:13+0200, Jan Hubicka wrote:
>>>> On 07/31/2017 11:57 A
r branch
in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs", see
attached.
I'll then apply/submit a number of follow-on commits.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Ar
ype value where
> scalar is required" } */
> + ;
> +
> +#pragma acc serial self self(b) /* { dg-error "too many 'self' clauses" } */
> + ;
> +#pragma acc serial self(*p) /* { dg-error "used struct type value where
> scalar is required&q
parser_omp_clause_name (parser);
..., and similarly in the C++ and (to a lesser extent) Fortran front ends
a bit twisted, and pushed to master branch
commit c92509d9fd98e02d17ab1610f696c88f606dcdf4
"Disentangle handling of OpenACC 'host', 'self' pragma tokens", see
attached.
entially behaves like the 'if' clause with the condition inverted)
Pushed to master branch commit a5e919027fdb1900a6f2d64f763c99dbaf98aee6
"Consistently order 'OMP_CLAUSE_SELF' right after 'OMP_CLAUSE_IF'", see
attached.
Grüße
Thomas
-
Siemens
to
master branch commit 047841a68ebf5f991e842961f9e54f3c10b94f2c
"Extend test suite coverage for OpenACC 'self' clause for compute constructs",
see attached. This is mostly just adapting and cross-linking some
existing 'if' clause test cases. (..., wh
an/self-1.f90
> @@ -0,0 +1,996 @@
> +! OpenACC 'self' clause.
> +
> +! This is 'if-1.f90' with 'self(!cond)' instead of 'if(cond)' on compute
> +! constructs.
> +! ..., which the exception of certain 'kernels' constructs.
..., which
t;Minor fixes for OpenACC/Fortran 'self' clause for compute constructs",
or is anything more needed?
Also, I've filed <https://gcc.gnu.org/PR111938>
"Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'",
which applies generally, not ju
then after
the Cauldron was out for late summer vacations, only recently returned,
and now catching up with things accumulated during that vacation time,
and then planning to resume GCC/nvptx work.
Grüße
Thomas
On 2023-10-25T14:54:50+0100, "Roger Sayle" wrote:
> Random fact: t
GCC style?
And then, the 'contrib/gcc_update' change that's currently in
"libgrust: Add entry for maintainers and stub changelog file" should be
part of the commit that actually adds the files referenced therein.
Grüße
Thomas
> ChangeLog:
>
> * Makefile.de
#x27;s being discussed in
<https://github.com/Rust-GCC/gccrs/issues/2714>
'Update libgrust for upstream GCC commit
6a6d3817afa02bbcd2388c8e005da6faf88932f1 "Config,Darwin: Allow for configuring
Darwin to use embedded runpath"'.
Grüße
Thomas
> libgrust/Changelog:
>
>
ER_POINTER (token->value), "readonly")
> + && c_parser_peek_2nd_token (parser)->type == CPP_COLON)
> + {
> + c_parser_consume_token (parser);
> + c_parser_consume_token (parser);
> + readonly = true;
> + }
> + locati
arget:
@item fopenmp
Target supports OpenMP via @option{-fopenmp}.
..., or move into 'gcc/testsuite/gfortran.dg/gomp/' (may then remove
explicit 'dg-additional-options "-fopenmp"').
I don't know which variant makes more sense, here.
Grüße
Thomas
estsuite/gfortran.dg/c_ptr_tests_21.f90
>> @@ -1,4 +1,5 @@
>> ! { dg-do compile }
>> +! { dg-require-effective-target fopenmp }
>> ! { dg-additional-options "-fopenmp" }
>> !
>> ! Ensure that C_PTR and C_FUNPTR are reported as incompatible types in
>> variant
Yes, that looks good to me -- you may push "as obvious".
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 Gesellschaft: München; Registergericht
München, HRB 106955
disables the
> *host* libgrust build?
... indeed, host libgrust still does get built.
The attached "Only build host libgrust if the Rust language is enabled"
ought to address this.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
Hi!
Short Friday afternoon status update:
On 2023-10-27T08:51:12+0100, Iain Sandoe wrote:
>> On 26 Oct 2023, at 09:21, Thomas Schwinge wrote:
>> First, I've pushed into GCC upstream Git branch devel/rust/libgrust-v2
>> the "v2" libgrust changes as posted by
+402,9 @@ make_ssa_name_fn (struct function *fn, tree var, gimple
> *stmt,
>else
> SSA_NAME_RANGE_INFO (t) = NULL;
>
> + if (VAR_P (var) && DECL_POINTS_TO_READONLY (var))
> +SSA_NAME_POINTS_TO_READONLY_MEMORY (t) = 1;
> +
>SSA_NAME_IN_FREE_LIST (t) = 0
Hi!
Short Friday evening status update:
On 2023-10-27T16:20:34+0200, I wrote:
> Short Friday afternoon status update:
>
> On 2023-10-27T08:51:12+0100, Iain Sandoe wrote:
>>> On 26 Oct 2023, at 09:21, Thomas Schwinge wrote:
>>> First, I've pushed into GCC upstrea
st/config-lang.in
>
>> +target_libs="target-libffi target-libbacktrace target-libgrust"
>
> Please don't add back 'target-libffi' and 'target-libbacktrace' here;
> just 'target-libgrust'. (As is present in GCC/Rust master branch, and
> p
gcc.dg/vect/vect-gather-2.c scan-tree-dump vect "different gather
scale"
+PASS: gcc.dg/vect/vect-gather-2.c scan-tree-dump-not vect "Loop contains
only SLP stmts"
Grüße
Thomas
> PR tree-optimization/31
> * tree-vect-loop.cc (update_epilogue_loop
5d9c3f
"Add OpenACC 'acc_map_data' variant to
'libgomp.oacc-c-c++-common/deep-copy-8.c'",
see attached.
This will be helpful to detect (and then avoid) a regression due to an
libgomp patch elsewhere.
Grüße
Thomas
> .../testsuite/libgomp.oacc-c++/deep-copy-12.C
oacc-c-c++-common/unmap-infinity-1.c
> @@ -10,7 +10,7 @@ main (int argc, char *argv[])
> {
>acc_init (acc_device_default);
>acc_unmap_data ((void *) foo);
> -/* { dg-output "libgomp: cannot unmap target block" } */
> +/* { dg-output "libgomp: refus
Hi!
On 2023-10-31T13:10:24+, Richard Biener wrote:
> On Tue, 31 Oct 2023, Thomas Schwinge wrote:
>> On 2023-10-19T11:47:14+, Richard Biener wrote:
>> > The following implements SLP vectorization support for gathers
>> > without relying on IFNs being pattern
:
>>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
>>> wrote:
>>>> This issue comes up in context of me working on C++ support for GCN and
>>>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>>>> "in other
80dc747416fb60a9835b
"Skip a number of 'g++.dg/compat/' test cases for '-fno-exceptions' testing",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haf
c2df91cd7bef28e8
"Skip a number of 'g++.dg/lto/' test cases for '-fno-exceptions' testing",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Ges
of 'g++.dg/tree-prof/' test cases for '-fno-exceptions' testing",
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
He
Anyway, not resolving that mystery today, but just a simple technicality:
pushed to master branch commit 5926f30a8dcee9142360fdae445ebfdee4a528f9
"GCN: Address undeclared 'NULL' usage in
'libgcc/config/gcn/gthr-gcn.h:__gthread_getspecific'",
see attached.
Grüße
Hi!
On 2022-07-14T19:39:40+0100, Jonathan Wakely wrote:
> On Thu, 14 Jul 2022 at 19:14, Thomas Schwinge wrote:
>> I'm looking into building GCN, nvptx offloading libstdc++ [...]
>> While there is some experimental/incomplete/not-to-be-relied-on support
>> for
mory allocations. What do you think -- you, who've spent a lot more
time on this topic than I have, so it's likely possible that I fail to
realize some "details"?
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 Gesellschaft: München; Registergericht
München, HRB 106955
for
subroutines (like in 'gfortran.dg/weak-1.f90') and also functions (I
suppose; test case?), or also for weak "data" in some way (which, for
example, in the C world then evaluates to a zero-address unless actually
defined)?
Could help to at least add a few more test cases, and cl
e (data->ptr);
+ ialias_call (omp_free) (ptr, free_allocator);
return ret;
(I've not yet analyzed whether that's completely equivalent.)
Note that this likewise applies to the current upstream submission:
<https://inbox.sourceware.org/gcc-patches/400092d8ce44340cece0e
hat this likewise applies to the current upstream submission:
<https://inbox.sourceware.org/gcc-patches/6eb5d0dd-da2a-6d8e-eaa2-d14bf708c...@codesourcery.com>
"openmp: Add support for 'present' modifier".
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ansch
tream submission:
<https://inbox.sourceware.org/gcc-patches/6eb5d0dd-da2a-6d8e-eaa2-d14bf708c...@codesourcery.com>
"openmp: Add support for 'present' modifier".
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
us execution wouldn't produce
> ordered sequence, but can't it happen even with asynchronous execution?
Yes, that does match my findings reported a while ago, see:
<https://inbox.sourceware.org/gcc-patches/87iljk4ji8@euler.schwinge.homeip.net>.
Grüße
Thomas
43b7aa6b54223>:
> "Page-locks the memory range specified [...] and maps it for the
> device(s) [...]. This memory range also is added to the same tracking
> mechanism as cuMemHostAlloc to automatically accelerate [...]"? (No
> manual 'mlock'ing involved in that cas
mp_usm } */
> +/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target
> offload_target_amdgcn } } */
I've pushed to devel/omp/gcc-12 branch
commit b4d4603df3fed290ccf721899be6bc69f037fe2b
"'libgomp.c/usm-{1,2,3,4}.c': Re-enable non-GCN offloading compilation&
9e7f06942409f90c
"Un-break nvptx libgomp build", 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; Sit
Hi!
On 2023-02-10T15:31:47+, Andrew Stubbs wrote:
> On 10/02/2023 14:21, Thomas Schwinge wrote:
>> Is the correct fix the following [...]
>
> Yes, [...]
>>> --- a/libgomp/config/nvptx/allocator.c
>>> +++ b/libgomp/config/nvptx/allocator.c
>>>
zero-initialization for pinned memory",
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 Gesellsc
Hi!
On 2023-02-14T15:11:14+, Andrew Stubbs wrote:
> On 14/02/2023 12:54, Thomas Schwinge wrote:
>> On 2022-01-13T11:13:51+, Andrew Stubbs wrote:
>>> Updated patch: this version fixes some missed cases of malloc in the
>>> realloc implementation.
>>
&
#x27;mmap' gets us.
> so I don't know if this can be used for mlockall replacement.
>
> I had assumed that using the Cuda allocator would fix that limitation.
>From what I've read (but no first-hand experiments), there's non-trivial
overhead with 'cuMemHostRe
'cuMemHostRegister' instead of 'cuMemAllocHost'/'cuMemHostAlloc'.
> And, getting rid of 'mlockall' is yet another topic.
Here, the need to use 'cuMemHostRegister' may then again come up, as
begun to discuss as my "different idea" re "
rich-location.h"
> +#include "target.h"
> +#include "file-prefix-map.h"
> +#include "cgraph.h"
> +
> +#include "output.h"
GCC's '#include' is a m...ystery -- I've pushed to master branch
commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42
race'"?
(..., and once we get to the point where we'd like to use libffi and/or
libbacktrace, then think about how to handle those GCC target
configurations.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ge
Hi!
On 2023-02-20T09:48:53+, Andrew Stubbs wrote:
> On 17/02/2023 08:12, Thomas Schwinge wrote:
>> On 2023-02-16T23:06:44+0100, I wrote:
>>> On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches"
>>> wrote:
>>>> The mmap im
dance of doubt.)
>> (Okay, I have to admit that the final patch was only committed on
>> Monday. But still ...)
>
> Possibly, I had most of this done before then. I'll have a look next
> time I visit this patch.
Until then, let's at least document/verify 'GOMP_enable_pinned_mod
Hi!
On 2023-01-11T13:31:56+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Wed, Jan 11, 2023 at 12:41:06PM +0100, Thomas Schwinge wrote:
>
> I think this should be reviewed by Joseph as option handling maintainer.
Joseph, please?
>> +@item -Wno-complain-wrong-lang
>> +@op
3ecf610b64f2
"Update copyright years.", 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 Gesellschaft
_node init to common code", see attached.
Grüße
Thomas
> Bootstrap and regtest running for all languages on
> x86_64-unknown-linux-gnu.
>
> OK if that succeeds?
>
> Thanks,
> Richard.
>
> gcc/
> * tree.cc (build_common_tree_nodes): Initialize void_li
ile
../../source-gcc/gcc/toplev.cc:2110
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[1]: *** [s-selftest-rust] Erro
aults.h', right? Why should that ever
fail to test that it exists?
> the reason is tm_include_list='** defaults.h' rather than tm_include_list='**
> ./defaults.h'.
> So we add the test condition for this situation.
I'm sorry, I understand neither your fail
int @indxq;
> print @itemq;
> print @lineq[$lstin..@lineq-1];
> }
> else
> {
> print @lineq;
> }
>
> # Local Variables:
> # indent-tabs-mode: nil
> # End:
Grüße
Thomas
> gcc/d/ChangeLog:
>
> * implement-d
ortran.dg/gomp/pr78260-2.f90 -O scan-tree-dump-times original
"#pragma omp target data map\\(tofrom:__result_f1\\)" 1
PASS: gfortran.dg/gomp/pr78260-2.f90 -O scan-tree-dump-times original
"#pragma omp target update to\\(\\*\\(integer\\(kind=4\\)\\[0:\\] \\*
restrict
time on that idea, if that turns out to
require non-trivial Texinfo parsing.
Given that you've now fixed up the existing disordered instances, I
suppose not many new ones are going be introduced, assuming that people
extend the documentation by looking at the existing, now-good context.
G
mory!
> + !! deallocate(x)
> + ! Just assign:
> + x = [character(len=4) :: "abcde","fhji","klmno"]
> + if (any (x /= [character(len=4) :: "abcde","fhji","klmno"])) error stop
> +!$omp end target
> +
gt; @@ -481,8 +481,7 @@ __gnat_runtime_initialize (int install_handler)
>
>FindClose (hDir);
>
> - if (dir != NULL)
> -free (dir);
> + free (dir);
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ans
believe Arsen does not have git write access.
Well, I guess we should fix that? :-) I've met Arsen in person at
FOSDEM 2023, and I'm happy to vouch for his reasonable behavior.
He does have a FSF Copyright Assignment for GCC.
<https://gcc.gnu.org/gitwrite.html#authenticated&g
;', and
commit b8beaa8447ed3c1637e8f93a08c0e47b5709290f
'Revert "OpenACC profiling-interface fixes for asynchronous operations"',
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
fo,
> + true, GOMP_MAP_VARS_OPENACC);
> +}
Pushed to devel/omp/gcc-12 branch
commit 5ea330fdc918e6731c5b706715a18470909247bf
"libgomp: Merge 'gomp_map_vars_openacc' into 'goacc_map_vars' [PR76739]",
see attached.
Grüße
Thomas
---
#x27;ve currently got:
- [...]
- acc_ev_enqueue_launch_start
- launch kernel
- free memory
- acc_ev_free
- acc_ev_enqueue_launch_end
This confused another thing that I'm working on, so I adjusted that to:
- [...]
- acc_ev_enqueue_launch_start
- launch kernel
- acc_ev_enqueue_launch_end
-
Hi!
In order to document/verify one aspect of OpenACC 'async' semantics, I've
pushed to master branch commit 442d51a20ef13a8e6c080ca30bc37fc93b6bfac4
"Document/verify another aspect of OpenACC 'async' semantics in
'libgomp.oacc-c-c++-common/data-3
ck way before your "async re-work".
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 Gesellschaft
Hi!
Pushed to master branch commit 199867d07be65cb0227a318ebf42b8376ca09313
"Simplify OpenACC 'no_create' clause implementation", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellsch
for EPHEMERAL data? (Open
> question:
> + is it more performant to use libgomp CBUF buffering or individual device
> + asyncronous copying?) */
Pushed to master branch commit 2b2340e236c0bba8aaca358ea25a5accd8249fbd
"Allow libgomp 'cbuf' buffering with OpenACC '
lugin-nvptx.c | 154 ++---
libgomp/target.c | 10 +-
.../acc_prof-parallel-1.c | 58 ++--
5 files changed, 44 insertions(+), 238 deletions(-)
I like it. :-)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschri
ain, however, don't we have to defer the 'free'?
Please verify the attached
"Given OpenACC 'async', defer 'free' of non-contiguous array support data
structures",
in particular the 'libgomp/oacc-parallel.c:GOACC_parallel_keyed' case.
G
Hi Christophe!
On 2023-05-09T21:14:07+0200, Christophe Lyon wrote:
> On Tue, 9 May 2023 at 17:17, Christophe Lyon
> wrote:
>> On Tue, 9 May 2023 at 11:00, Thomas Schwinge
>> wrote:
>>> On 2023-05-09T09:32:55+0200, Christophe Lyon
>>> wrote:
>>>
Hi!
On 2014-11-04T10:31:37-0800, Mike Stump wrote:
> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>>> [...]
>>>
>>> Am I on the right track with the following?
>>
>> Nobody commented, whic
101 - 200 of 5586 matches
Mail list logo
