Dear all,
using a bad expression as stride in a subsequent array section did
lead to an internal error which was directly invoked after the
failure. We better return a failure code to let error recovery
do its expected job.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Fro
On Sun, Dec 05, 2021 at 12:16:38PM +0100, Thomas Koenig wrote:
>
> On 05.12.21 01:35, Peter Bergner wrote:
> > Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
> > setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
> > allow the other system binaries to not find
Dear all,
we didn't check the type of the upper bound in a case range.
Bummer. Simply add a corresponding check.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b4e7aeae4f6c59d8fe950d7981832e3f9c6a8f0e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 Dec 2021
Hi,
here is a first stab at the library side of power-ieee128,
committed to the branch.
It compiles, but probably still has a lot of issues. It
is also not called from the compiler yet.
Regards
Thomas
2021-10-19 Thomas Koenig
Prepare library for REAL(KIND=17).
This
Hi everyone,
Since support for target aarch64-apple-darwin has been submitted for review,
it’s time to submit the Fortran part, i.e. enabling IEEE support on that target.
The patch has been in use now for several months, in a developer branch shipped
by some distros on macOS (including Homebrew
On Mon, Dec 06, 2021 at 05:06:10PM +0100, Tobias Burnus wrote:
> Regarding the sorting and iterators: I think we already have this problem
> intrinsically – for depend/affinity, we create for (iterator(...) :
> a, b)
> a single loop - also to have a consistency with regards to the array bounds.
d
On 06.12.21 16:16, Jakub Jelinek wrote:
I think there is no reason why the 3 arrays passed to GOMP_target_ext
(etc., for target data {, enter, exit} too and because this
affects to and from clauses as well, target update as well)
need to be constant size.
We do a lot of sorting of the map clauses
On Mon, Dec 06, 2021 at 03:00:30PM +0100, Tobias Burnus wrote:
> This is a RFC/WIP patch about:
>
> (A) OpenMP (C/C++/Fortran)
>omp target map(iterator(i=n:m),to : x(i))
>
> (B) Fortran:
> (1) omp target map(to : dt_var, class_var)
> (2) omp parallel allocator(my_alloc) firstprivate(class
This is a RFC/WIP patch about:
(A) OpenMP (C/C++/Fortran)
omp target map(iterator(i=n:m),to : x(i))
(B) Fortran:
(1) omp target map(to : dt_var, class_var)
(2) omp parallel allocator(my_alloc) firstprivate(class_var)
(3) call co_reduce(dt_coarray, my_func)
The problem with (A) is that t
