Hi!
As the testcase shows, we need to gimplify OMP_CLAUSE_SIZE, so that we
don't end up with SAVE_EXPR or anything similar non-gimple in it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2021-06-08 Jakub Jelinek
PR fortran/100965
* trans-ope
On Mon, Jun 14, 2021 at 02:34:53PM +0200, Tobias Burnus wrote:
> Rather obvious fix for a warning found by David via cppcheck.
>
> OK?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: T
On Wed, Jun 09, 2021 at 02:18:43PM +0200, Tobias Burnus wrote:
> This patch add's OpenMP 5.1's defaultmap extensions to Fortran.
>
> There is one odd thing,
> integer :: ii, it
> target :: it
> both count as nonallocatable, nonpointer scalars (i.e. category 'scalar').
> But with implicit mapp
On Tue, Jun 15, 2021 at 03:45:15PM +0200, Tobias Burnus wrote:
> PR fortran/92568
>
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_clauses): Update for defaultmap.
> * f95-lang.c (LANG_HOOKS_OMP_ALLOCATABLE_P,
> LANG_HOOKS_OMP_SCALAR_TARGET_P): New.
> * g
On Wed, Jul 07, 2021 at 07:59:58PM +0200, Marcel Vollweiler wrote:
> OpenMP: Add support for device-modifiers for 'omp target device'
>
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_omp_clause_device): Add support for
> device-modifiers for 'omp target device'.
>
> gcc/cp/ChangeLog:
On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote:
> gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305]
>
> gcc/testsuite/
> PR libfortran/101305
> * gfortran.dg/dg.exp: Add '-I /libgfortran'
> compile flag.
Wouldn't it be better to do that in gcc/t
On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub Jelinek wrote:
> On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote:
> > gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305]
> >
> > gcc/testsuite/
> > PR libfortran/101305
> >
On Tue, Aug 10, 2021 at 04:45:33PM +0200, Tobias Burnus wrote:
> --- a/libgfortran/Makefile.am
> +++ b/libgfortran/Makefile.am
> @@ -1076,6 +1076,9 @@ fpu-target.inc: fpu-target.h $(srcdir)/libgfortran.h
> grep '^#define GFC_FPE_' < $(top_srcdir)/../gcc/fortran/libgfortran.h >
> $@ || true
>
On Thu, Aug 12, 2021 at 12:52:17PM +0200, Tobias Burnus wrote:
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_omp_clause_proc_bind): Accept
> 'primary' as alias for 'master'.
>
> gcc/cp/ChangeLog:
>
> * parser.c (cp_parser_omp_clause_proc_bind): Accept
> 'primary' as alias
On Fri, Aug 13, 2021 at 08:52:34PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_clauses): Handle 'filter' clause.
> (show_omp_node, show_code_node): Handle (combined) omp masked construct.
> * frontend-passes.c (gfc_code_walker): Likewise
On Tue, Aug 17, 2021 at 02:55:56PM +0200, Tobias Burnus wrote:
> On 17.08.21 09:47, Jakub Jelinek wrote:
> > This patch implements the OpenMP 5.1 scope construct, which is similar
> > to worksharing constructs in many regards, but isn't one of them.
>
> And the attach
On Wed, Aug 18, 2021 at 11:00:47AM +0200, Tobias Burnus wrote:
> Note 2 ---
> 'omp_lib.h' is included in as declaration-construct in the
> specification-part of a file (i.e. possibly after an implicit statement);
> hence, it cannot contain a use-stmt. Additiona
On Wed, Aug 18, 2021 at 01:10:12PM +0200, Tobias Burnus wrote:
> I think otherwise the patch is boring - as boring as 'omp nothing' itself
> (outside its use in metadirectives).
Yeah, I think nobody sane will use it for anything but metadirective
except in compiler testsuites.
> Fortran: Add Open
On Fri, Aug 20, 2021 at 08:48:57AM +0200, Harald Anlauf via Gcc-patches wrote:
> Hi!
>
> > Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> > Von: "H.J. Lu"
>
> > This may have broken bootstrap on 32-bit hosts:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
>
> I
On Fri, Aug 20, 2021 at 12:00:10PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_clauses): Handle 'at', 'severity'
> and 'message' clauses.
> (show_omp_node, show_code_node): Handle EXEC_OMP_ERROR.
> * gfortran.h (gfc_statement): Add
On Fri, Aug 20, 2021 at 11:45:33AM +0200, Harald Anlauf wrote:
> Hi Jakob,
>
> thanks for the detailed explanation!
>
> > The other much easier but uglier option is to use a temporary buffer:
> > char buffer[21];
> > sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> > gfc_error ("...
On Fri, Aug 20, 2021 at 12:53:33PM +0200, Harald Anlauf wrote:
> > Gesendet: Freitag, 20. August 2021 um 12:12 Uhr
> > Von: "Jakub Jelinek"
>
> > I have verified it fixes i686-linux bootstrap.
> > But the new testcase doesn't trigger any of thos
On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
> On 20.08.21 11:16, Jakub Jelinek wrote:
>
> > Now, the non-Fortran FE diagnostic code actually has %wd for this (w
> > modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
> >
On Fri, Aug 20, 2021 at 03:47:54PM +0200, Tobias Burnus wrote:
> On 20.08.21 13:56, Jakub Jelinek wrote:
>
> > On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
> > > Comments? OK?
> > LGTM (except that the last hunk won't apply anymore).
>
&g
On Mon, Aug 23, 2021 at 02:14:46PM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -1490,7 +1490,7 @@ typedef struct gfc_omp_clauses
>unsigned inbranch:1, notinbranch:1, nogroup:1;
>unsigned sched_simd:1, sched_monotonic:1, sched_nonmonotonic:1
On Wed, Aug 25, 2021 at 12:14:09PM +0200, Marcel Vollweiler wrote:
> Add support for device-modifiers for 'omp target device'.
>
> 'device_num' and 'ancestor' are now parsed on target device constructs for C,
> C++, and Fortran (see OpenMP specification 5.0, p. 170). When 'ancestor' is
> used, th
On Wed, Sep 01, 2021 at 09:06:31AM +0200, Christophe Lyon wrote:
> > > * gfortran.dg/gomp/target-device-ancestor-4.f90: New test.
> >
>
> The last new test fails on aarch64:
> /gcc/testsuite/gfortran.dg/gomp/target-device-ancestor-4.f90:7:15: Error:
> Sorry, 'reverse_offload' clause at (1)
On Thu, Sep 02, 2021 at 02:09:25PM +0200, Marcel Vollweiler wrote:
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/gomp/target-device-ancestor-4.f90: Comment out dg-final
> to avoid
>UNRESOLVED.
Ok, thanks.
>
> diff --git a/gcc/testsuite/gfortran.dg/gomp/target-device-ancestor-4.f90
On Mon, Sep 06, 2021 at 06:08:14PM +0200, Marcel Vollweiler wrote:
> C, C++, Fortran, OpenMP: Add support for 'flush seq_cst' construct.
>
> This patch adds support for the 'seq_cst' memory order clause on the 'flush'
> directive which was introduced in OpenMP 5.1.
>
> gcc/c-family/ChangeLog:
>
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >.../GCC-HEAD/libgfortran/ISO_Fortran
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote:
> Regarding FreeBSD: Does this output different values? – If yes, we know
> what to do, otherwise – hmm.
>
> [...]
>
> > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
> > > float.h? The header doesn't want
On Mon, Sep 13, 2021 at 05:56:53PM +0200, Gerald Pfeifer wrote:
> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> /usr/include/x86/float.h:#define LDBL_MAX_EXP 163
On Tue, Sep 14, 2021 at 05:17:04PM +0200, Andreas Schwab wrote:
> On Sep 14 2021, Gerald Pfeifer wrote:
>
> > #define __LDBL_MANT_DIG__ 53
> > #define __LDBL_DIG__ 15
> > #define __LDBL_MIN_EXP__ (-16381)
> > #define __LDBL_MIN_10_EXP__ (-4931)
> > #define __LDBL_MAX_EXP__ 16384
> > #d
On Fri, Sep 17, 2021 at 07:57:38PM +0800, Chung-Lin Tang wrote:
> 2021-09-17 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
> false parameter. Add 'always,tofrom' map for OMP_LIST_IN_REDUCTION case.
> (gf
On Fri, Sep 17, 2021 at 11:42:13PM +0200, Tobias Burnus wrote:
> Fortran/OpenMP: unconstrained/reproducible ordered modifier
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (gfc_omp_clauses): Add order_unconstrained.
> * dump-parse-tree.c (show_omp_clauses): Dump it.
> * openmp.c (g
On Mon, Sep 20, 2021 at 05:01:32PM +0200, Tobias Burnus wrote:
> On 20.09.21 11:55, Jakub Jelinek via Fortran wrote:
> > So the FE was splitting the order clause to distribute already before,
> > perhaps we should undo that for gcc 11 which doesn't claim any OpenMP 5.1
On Thu, Sep 30, 2021 at 01:14:49PM +0200, Tobias Burnus wrote:
> On 30.09.21 09:45, Jakub Jelinek wrote:
>
> > This patch adds new OpenMP 5.1 allocator entrypoints ...
>
> ... and this patch adds the Fortran support for it, using the C→Fortran
> converted testcases. Addit
On Fri, Oct 01, 2021 at 11:32:24AM +0200, Tobias Burnus wrote:
> libgomp/ChangeLog:
>
> * testsuite/libgomp.fortran/alloc-10.f90: Fix alignment check.
> * testsuite/libgomp.fortran/alloc-7.f90: Fix array access.
> * testsuite/libgomp.fortran/alloc-8.f90: Likewise.
> * tests
Hi!
On powerpc64le-linux target, one can select between two incompatible
long double formats (both of them are 16-byte), __ibm128 which is
a sum of two doubles, and __float128 (note, not implemented through
libquadmath), which is IEEE754 quad format. The default for
long double can be selected wi
On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > Your thoughts on this?
>
> How does glibc deal with this? There's a load of long double ABI in there.
I don't know, CCing Florian; all I can see is that starting with glibc 2.26
in addition to sin{f,,l} there is also sinf128, bu
On Mon, Oct 04, 2021 at 01:36:56PM +0200, Jakub Jelinek via Gcc wrote:
> On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > > Your thoughts on this?
> >
> > How does glibc deal with this? There's a load of long double ABI in there.
>
> I don&#
On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux. From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_RE
On Wed, Oct 06, 2021 at 12:39:01PM +0100, Kwok Cheung Yeung wrote:
> In secion 2.3.1 of the OpenMP 5.0 spec, it says:
>
> 3. For functions within a declare target block, the target trait is added to
> the beginning of the set...
>
> But OpenMP in Fortran doesn't have the notion of a declare targe
On Wed, Oct 06, 2021 at 12:39:01PM +0100, Kwok Cheung Yeung wrote:
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -11599,8 +11599,11 @@ omp_construct_selector_matches (enum tree_code
> *constructs, int nconstructs,
> }
> }
>if (!target_seen
> - && lookup_attribute ("omp dec
On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data. If some user has written
> > >>out data in double double and wants to
On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> We can emulate it everywhere (using libquadmath for example). This can
> magically make -msoft-float work as well everywhere, btw.
Emulation is one thing, but another one is where are those __float128 or
quad long double argume
On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example). This c
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem i
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
>
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions
> > and designs
>
> Even glibc ha
On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote:
> On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> > On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > > I tried this at one point. There are a lot of hidden assumptions that
> > > the kind
> > > number is
On Thu, Oct 07, 2021 at 09:59:00PM +0800, Chung-Lin Tang wrote:
> this patch add support for "strictly-structured blocks" introduced in OpenMP
> 5.1,
> basically allowing BLOCK constructs to serve as the body for directives:
>
> !$omp target
> block
> ...
> end block
> [!$omp end target] !! en
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them. Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
I'd hope Debian can just
ln -sf libgfortran.s
On Mon, Oct 11, 2021 at 11:40:54AM +0200, Marcel Vollweiler wrote:
> libgomp: Add tests for omp_atv_serialized and deprecate omp_atv_sequential.
>
> The variable omp_atv_sequential was replaced by omp_atv_serialized in OpenMP
> 5.1. This was already implemented by Jakub (C/C++, commit ea82325afec)
On Mon, Oct 11, 2021 at 01:28:11PM +0200, Marcel Vollweiler wrote:
> > > libgomp/ChangeLog:
> > >
> > > * allocator.c (omp_init_allocator): Replace omp_atv_sequential with
> > > omp_atv_serialized.
> > > * omp.h.in: Add deprecated flag for omp_atv_sequential.
> > > * omp_lib.f9
On Thu, Oct 07, 2021 at 07:09:07PM +0200, Jakub Jelinek wrote:
> The workshare/parallel workshare case is unclear, I've filed
> https://github.com/OpenMP/spec/issues/3153
> for it. Either don't allow block if workshare_stmts_only for now
> until that is clarified, or if
On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Thinking more about the Fortran case for !$omp sections, there is an
> ambiguity.
> !$omp sections
> block
> !$omp section
> end block
> is clear and !$omp end sections is optional, but
>
On Thu, Oct 14, 2021 at 11:04:59AM +0100, Kwok Cheung Yeung wrote:
> I have now dropped this. This affects test2 in
> gfortran.dg/gomp/declare-variant-8.f90, which I have added a comment to.
Thanks.
> I have added Fortran-specific tests as
> gfortran.dg/gomp/declare-variant-15.f90 to declare-vari
On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote:
> Thanks, Jakub, for starting this discussion, and to everyone who weighed in.
> The conversation
> went in a number of different directions, so I'd like to summarize my
> understanding of points
> where I think there was agreement.
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
> > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
> > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
> > precision of C long double if it is double-double nor range matches
> > a
On Sat, Oct 16, 2021 at 02:44:12AM +0800, Chung-Lin Tang wrote:
> The patch currently does not allow strictly-structured BLOCK for
> sections/parallel sections,
> since I was referencing the 5.1 spec while writing it, although that is
> trivially fixable.
> (was sensing a bit odd why those two co
On Mon, Oct 18, 2021 at 10:05:29PM +0100, Kwok Cheung Yeung wrote:
> On 14/10/2021 1:47 pm, Jakub Jelinek wrote:
> > What I still miss is tests for the (proc_name : variant_name) syntax
> > in places where proc_name : is optional, but is supplied and is valid, like
> > e.g
On Tue, Oct 19, 2021 at 09:03:06PM +0800, Chung-Lin Tang wrote:
> 2021-10-19 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
> false parameter. Add 'always,tofrom' map for OMP_LIST_IN_REDUCTION case.
> (gf
On Wed, Oct 20, 2021 at 08:30:34PM +0800, Chung-Lin Tang wrote:
> 2021-10-20 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case
> together with COMP_BLOCK.
> * parse.c (parse_omp_structured_block): Change return
On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> Introduce a helper to construct a user operator from a name and the
> reverse operation, i.e. a helper to construct a name from a user
> operator.
>
> Cc: Ja
On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
> - Have a compiler switch which selects between IEEE_QP and IBM_QP.
> This was a suggestion by Steve Lionel formerly of DEC and Intel,
> and they did that when they had a few floating point formats on
> the Alpha to choose from.
On Mon, Nov 01, 2021 at 06:32:51PM +0100, Thomas Koenig wrote:
> f->value.function.name
> = gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
> f->ts.kind);
>
> Easy enough to add something there if ts.type is BT_REAL,
> ts.kind is 16 and the compiler
On Thu, Nov 11, 2021 at 04:04:04PM +0100, Tobias Burnus wrote:
> Just the Fortran FE work + Fortranized version for the C tests.
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäf
On Thu, Nov 11, 2021 at 06:11:23PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -915,15 +915,16 @@ decode_omp_directive (void)
>matcho ("error", gfc_match_omp_error, ST_OMP_ERROR);
>matcho ("end atomic", gfc_match_omp_eos_error, ST_OMP_END
On Fri, Nov 12, 2021 at 12:01:27PM +0100, Tobias Burnus wrote:
> With the attached patch, the following combined/composite
> directives accept 'nowait' at 'end':
I've filed https://github.com/OpenMP/spec/issues/3184 because
I think OpenMP 5.2 got it wrong (and 5.1 got it wrong for
the end directiv
On Fri, Nov 12, 2021 at 04:56:37PM +0100, Tobias Burnus wrote:
> Fortran/openmp: Fix '!$omp end'
>
> gcc/fortran/ChangeLog:
>
> * parse.c (decode_omp_directive): Fix permitting 'nowait' for some
> combined directives, add missing 'omp end ... loop'.
> (gfc_ascii_statement): Fix
yte 0x23# DW_OP_plus_uconst
.uleb128 0x10
.byte 0x94# DW_OP_deref_size
.byte 0x1
which perform
*(unsigned char *)(a + 0x1c)
and
*(unsigned char *)(a + 0x10)
respectively.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-11-19 Jakub Jeli
On Tue, Nov 16, 2021 at 08:51:03AM +0100, Thomas Koenig wrote:
> If you could start working on the points above, that would be great.
Just small completely untested step, which IMHO should ensure that
on powerpc64le-*linux* (unless --with-long-double-64 configured)
we build libgfortran by default
On Thu, Nov 04, 2021 at 04:23:43PM +0800, Chung-Lin Tang wrote:
> 2021-11-04 Chung-Lin Tang
> Thomas Schwinge
>
> PR fortran/90030
>
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_omp_finish_clause): Remove fold_convert to pointer
> to char_type_node, add gcc_
On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote:
> I am currently working on implementing the IEEE 128-bit floating
> on POWER. One of the things to decide is what to call the
> math functions for the library calls.
>
> Example: libgfortran/generated/bessel_r16.c currently h
On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote:
> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> if those need to be declared by libgfortran or math.h declares them).
To answer this myself, just tried on Fedora 34 and we'd need to
declare
On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
>
> On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
>
> > Inside of libgfortran, I think it should depend on some macro defined
> > in libgfortran.h.
> > #if defined(__powerpc64__) && __BYTE
On Fri, Dec 03, 2021 at 12:16:56PM +0100, Thomas Koenig wrote:
> > It is part of upstream glibc 2.32 (released Aug 2020) and later, see
> > https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67
> > distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 a
On Mon, Nov 15, 2021 at 12:29:31PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -1926,6 +1930,22 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
>fputc (' ', dumpfile);
>fputs (memorder, dumpfile);
> }
> + if (
On Fri, Nov 19, 2021 at 09:54:12PM +0800, Chung-Lin Tang wrote:
> 2021-11-19 Chung-Lin Tang
>
> gcc/c/ChangeLog:
>
> * c-parser.c (struct omp_dim): New struct type for use inside
> c_parser_omp_variable_list.
> (c_parser_omp_variable_list): Allow multiple levels of array and
On Sat, Dec 04, 2021 at 11:16:28AM +0100, Thomas Koenig wrote:
>
> On 04.12.21 07:39, Michael Meissner via Fortran wrote:
> > I have loaded Advance Toolchain 15.0 on the system. It is located in
> > /opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
>
> I tried bootstrapping (from
On Sat, Dec 04, 2021 at 10:12:37AM -0600, Peter Bergner via Gcc wrote:
> On 12/4/21 9:37 AM, Peter Bergner wrote:
> > On 12/4/21 9:25 AM, Michael Meissner wrote:
> > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not
> > f
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
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 Mon, Dec 13, 2021 at 12:19:50PM +0100, Tobias Burnus wrote:
> Some Sunday work ...
> Implement the 'compare' part in trans-openmp of OpenMP 5.1's atomic changes
> plus a couple of bugfixes throughout.
>
> OK?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift
301 - 379 of 379 matches
Mail list logo
