Hi!
The following patch quiets
../../../libgfortran/generated/in_pack_r17.c:35:1: warning: no previous
prototype for ‘internal_pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_pack_c17.c:35:1: warning: no previous
prototype for ‘internal_pack_c17’ [-Wmissing-prototypes]
../../.
Hi!
The following patch detects the powerpc64le-linux kind == 16 cases
and for the -mabi=ieeelongdouble case (no matter whether it is the
configured in default or just option used on the command line) uses
_r17 or _c17 instead of _r16 or _c17 in the library API names.
>From what I can see, e.g. c
On Fri, Dec 31, 2021 at 03:16:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Haven't played enough with it to see if the various *_r17 or *_c17
> API entrypoints are called (but verified abi_kind is right in the
> debugger), in all my attempts so far everything was emitted inline.
Actually pla
On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote:
> > > If you are building libraries that contain modules with multiple
> > > long double
> > > types, you must use the '-mno-gnu-attribute'. We also use the
> > > '-Wno-psabi'
> > > option, which silences the warning that you are switc
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
> The idea behind this is that libstdc++ is written such that it can handle
> both IBM extended and IEEE quad long double, so its object files are
> compatible with both.
Now tested on powerpc64le-linux (and together with the regenerat
Hi!
Testing found that we also need libquadmath to be built with
-mno-gnu-attribute, otherwise -mabi=ieeelongdouble programs don't link.
Ok for power-ieee128?
2022-01-03 Jakub Jelinek
* configure.ac: Set XCFLAGS to -mno-gnu-attribute on
powerpc64le*-linux*.
* configur
Hi!
The following patch adds the library side of -mabi=ieeelongdouble
I/O support.
There is one issue to be resolved though, for the sake of libgfortran.a
built on an older powerpc64le-linux system (glibc older than 2.32) and
then deployed on glibc 2.32 or later, I believe we want to use
_gfortra
Hi!
Here is the compiler side of those changes, but depends of course
on the decision what to do with those *real128* and *complex128* symbols.
With all the 4 patches e.g. print *, var for real(kind=16) var; var = 1.0;
works both with -mabi=ibmlongdouble and -mabi=ieeelongdouble.
2022-01-03 Jak
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote:
> The following patch adds the library side of -mabi=ieeelongdouble
> I/O support.
>
> There is one issue to be resolved though, for the sake of libgfortran.a
> built on an older powerpc64le-linux system (glibc older th
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> On 03.01.22 17:26, Jakub Jelinek wrote:
>
> > so we could similarly have something like:
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > && __SIZEOF_LONG_DOUBLE__ == 16)
> > _gfortran_transfer_
On Mon, Jan 03, 2022 at 11:43:57PM +0100, Thomas Koenig wrote:
> > clearly there is still work to fix (but seems e.g. most of the lto tests
> > are related to the gnu attributes stuff:( ).
>
> This is looking better than what I expected. Apart from LTO, I expect
I've just verified that LTO is b
Hi!
The following patch fixes:
FAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finl
Hi!
Another patch, this fixes:
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O0 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O1 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -fomit-frame-pointer
-funroll-
Hi!
Following patch adds remaining missing *_r17 entrypoints, so that
we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17).
This fixes:
FAIL: gfortran.dg/dec_math.f90 -O0 execution test
FAIL: gfortran.dg/dec_math.f90 -O1 execution test
FAIL: gfortran.dg/dec_math.f90 -O2
Hi!
This test FAILs because
f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support
compiler exited with status 1
FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors)
As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't
be testing with that option.
Ok for p
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
>
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll star
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll start doing some stuff on it. Just one question:
> What are functions that I can use to conver
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
I've just tried to build libgfortran on an old glibc system
(gcc112.fsffrance.org) an
On Fri, Jan 07, 2022 at 12:29:25PM +0100, Jakub Jelinek wrote:
> we don't do it consistently:
> readelf -Wr
> /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0
> | grep ieee128
> 00250310 01280015 R_PPC64_JMP_SLOT
>
On Fri, Jan 07, 2022 at 03:25:57PM +0100, Thomas Koenig wrote:
> > > 00251038 06ad0015 R_PPC64_JMP_SLOT
> > > __cabsieee128 + 0
> > > All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
> >
> > So, seems all these come from f951 compiled sources
On Fri, Jan 07, 2022 at 11:26:15AM +0100, Thomas Koenig wrote:
> In
>
> https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html
>
> I made a suggestion how how the format could look like. I used
> a plus sign instead of a comma because I thought the environment
> variable should follow th
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:
> One thing that one has to watch out for is a big-endian IBM long double
> file, so the byte swapping will have to be done before assigning
> the value.
I've tried to handle that right, i.e. on unformatted read with
byte-swapping and
On Sat, Jan 08, 2022 at 11:07:24AM +0100, Thomas Koenig wrote:
> I have tried to unravel the different cases here, I count six
> (lumping together the environment variables, the CONVERT specifier
> and -fconvert, and leaving out the byte swapping)
>
> CompilerConvert Read action Write ac
On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> And IMHO the default like for byte-swapping should be the native
> format, i.e. the one the program actually used.
One reason for that is that neither conversion is lossless, neither format
is a subset or superset of
On Sat, Jan 08, 2022 at 12:10:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> One reason for that is that neither conversion is lossless, neither format
> is a subset or superset of the other. Yes, IEEE quad has both much bigger
> exponent range (-16382..16383 vs. -1022..1023) and slightly bigg
On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
>
> On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
> > Note, as for byteswapping, apparently it wasn't ever working right fox
> > the IBM extended real(kind=16) and complex(kind=16).
>
> The
On Wed, Nov 24, 2021 at 06:08:02PM +0100, Marcel Vollweiler wrote:
> + case OMP_CLAUSE_HAS_DEVICE_ADDR:
> + t = OMP_CLAUSE_DECL (c);
> + if (TREE_CODE (t) == TREE_LIST)
> + {
> + if (handle_omp_array_sections (c, ort))
> + remove = true;
> + e
On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:
> Hello world,
>
> I have just pushed the attched patch to the branch.
Thanks.
Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and complex(kind=16).
Similarly to the BT_COMPLEX case it hal
On Tue, Jan 11, 2022 at 02:27:57PM +0100, Tobias Burnus wrote:
> Hi Jakub, hi all,
>
> let me quickly comment on 'has_device_addr' with Fortran arrays
> and with an array section (i.e. regarding your comment quoted
> at the very bottom of this email).
>
> Unfortunately, the OpenMP specification i
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote:
> On 1/11/22 16:48, Toon Moene wrote:
> > On 1/11/22 13:56, Martin Liška wrote:
> >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > Plus it survives build of all FEs (--enable-languages=all) on
> > >
On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote:
> On 1/11/22 16:56, Jakub Jelinek wrote:
> > While e.g. libcpp or gcc are in C++.
>
> Which means I should rename .c files under libcpp, right?
> Is there any other folder from gcc/ and libcpp/ that would need that as well?
>From the d
On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote:
> > Regarding fortran: can we have a vote on this one?
> >
> > Some developers (including myself) are not really familiar with C++,
> > and in the past preference has been expressed on the fortran ML in
> > favor of no
On Tue, Jan 11, 2022 at 10:44:56PM +0100, Thomas Koenig wrote:
> > > So... time to merge the branch into trunk before stage 4
> > > kicks in?
> >
> > IMHO yes. We need to git merge master; git rebase of course
> > before trying to cherry-pick those commits into trunk and pushing there.
>
> I wou
On Tue, Jan 11, 2022 at 10:30:26PM -0500, David Edelsohn wrote:
> The recent patch to support Power IEEE128 causes a bootstrap failure
> on AIX and possibly all non-GLIBC systems.
>
> +#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> +&& defined __GLIBC_PREREQ && __G
On Tue, Jan 11, 2022 at 10:30:26PM -0500, David Edelsohn wrote:
> The recent patch to support Power IEEE128 causes a bootstrap failure
> on AIX and possibly all non-GLIBC systems.
>
> +#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> +&& defined __GLIBC_PREREQ && __G
On Wed, Jan 12, 2022 at 11:23:43AM +0100, FX via Gcc-patches wrote:
> I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux
> 5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master:
>
> $ grep signaling testsuite/gfortran/gfortran.sum
> PASS: gfortran.dg/ieee/sig
On Wed, Jan 12, 2022 at 12:03:40PM +0100, FX wrote:
> > We need -fintrinsic-modules-path option for the signalling_1.f90 compilation
> > but need to make sure it isn't used when the *.c file is compiled, so they
> > need to be compiled by separate compiler invocations probably.
>
> Thanks for post
Hi!
I forgot to change the gfortran.map-sun goal to gfortran.ver-sun
when changing other spots for the preprocessed version file.
Fixed thusly, committed to trunk as obvious.
2022-01-13 Jakub Jelinek
PR libfortran/104006
* Makefile.am (gfortran.map-sun): Rename target to ...
Hi!
In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously version_dep
on Linux used to be a file in $(srcdir), but with my changes it is a generated
file in the object directory (preprocessed version of the $(srcdir) file)
and I thought generated files belong to BUILT_SOURCES so that
On Fri, Jan 14, 2022 at 12:45:54PM +0100, Tobias Burnus wrote:
> On 14.01.22 10:10, Thomas Schwinge wrote:
> > > + integer :: x
> > > ...
> > > + !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected
> > > integer expression of the 'omp_allocator_handle_kind' kind at .1." }
> > We do
On Mon, Dec 20, 2021 at 03:16:23PM +, Andrew Stubbs wrote:
> This patch removes the "sorry" message for the OpenMP "requires
> dynamic_allocators" feature in C, C++ and Fortran.
>
> The clause is supposed to state that the user code will not work without the
> omp_alloc/omp_free and omp_init_a
Hi!
This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).
Bootstrapped/regtested on x86_64-linux and i686-lin
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order to
Hi!
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_datatype_16;
__ieee_arithmetic_MOD_ieee_support_denorm
On Wed, Feb 02, 2022 at 09:19:03AM +0100, Marcel Vollweiler wrote:
> gcc/c-family/ChangeLog:
>
> * c-omp.cc (c_omp_split_clauses): Added OMP_CLAUSE_HAS_DEVICE_ADDR case.
> * c-pragma.h (enum pragma_kind): Added 5.1 in comment.
> (enum pragma_omp_clause): Added PRAGMA_OMP_CLAUSE_H
Hi!
The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check
On Fri, Feb 04, 2022 at 12:39:53PM +0100, Tobias Burnus wrote:
> Already during parsing, the allocatable character array assignment
>x = (x)
>
> is converted to two gfc_codes with EXEC_ASSIGN, namely:
>
> ASSIGN z1:_F.DA0(FULL) (parens z1:x(FULL))
> ASSIGN z1:x(FULL) z1:_F.DA0(FULL)
>
>
On Tue, Feb 15, 2022 at 11:26:12AM +0100, Tobias Burnus wrote:
> As found by Marcel, the 'depend' clause was differently handled in
> 'omp depobj(...) depend(...)' and in 'omp task depend(...)'.
>
> The problem was that for a scalar pointer, depobj depended
> on the pointer address - while task de
On Tue, Feb 15, 2022 at 06:01:09PM +0100, Tobias Burnus wrote:
> OK?
Ok.
> Fortran/OpenMP: Fix depend-clause handling for c_ptr
>
> gcc/fortran/ChangeLog:
>
> * trans-openmp.cc (gfc_trans_omp_depobj): Fix to alloc/ptr dummy
> and for c_ptr.
>
> gcc/testsuite/ChangeLog:
>
> *
On Mon, Feb 21, 2022 at 02:24:40PM +, Hafiz Abid Qadeer wrote:
> This patch fixes an issue that although gfortran accepts
> 'requires dynamic_allocators', it does not set the omp_requires_mask
> accordingly.
>
> gcc/fortran/ChangeLog:
>
> * parse.cc (gfc_parse_file): Set OMP_REQUIRES_DY
On Mon, Feb 21, 2022 at 06:02:06PM +0100, Tobias Burnus wrote:
> I wonder whether there is a real problem in terms of the ME, but maybe
> there is.
>
> For atomic_default_mem_order: That's purely handle by the FEs by
> setting the default – and just using it when parsing the 'atomic'
> directive,
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
> gcc/fortran/
>
> PR fortran/104131
> * openmp.cc (gfc_match_omp_detach): Check that the event handle is not
> an array type.
>
> gcc/testsuite/
>
> PR fortran/104131
> * gfortran.dg/gomp/pr104131.f
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
> > On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
> (...)
> > > Don't we usually test instead || (*expr)->rank != 0 when testing for
> > > scalars?
> > >
> (...)
> >
> > So (*expr)->ra
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
> > It is true that the spots I saw in fortran/openmp.cc that test rank look
> > like:
> > if (!gfc_resolve_expr (el->expr)
> > || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0)
> > etc., so probably !gfc_r
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 21:37, Mikael Morin a écrit :
> > Maybe corank should be checked together with rank?
>
> Lesson learned today: expressions don’t have a corank.
> Does pr104131-2.f90 really need to be rejected?
OpenMP 5.2 says that de
On Tue, Mar 01, 2022 at 08:58:54AM +0100, Tobias Burnus wrote:
> The wording actually also permits array sections. But contrary to coarrays,
> (which are odd but otherwise fine), I think it does not really make sense
> to have arrays and array sections here.
>
> (Do we need/want to get this clarif
On Tue, Mar 01, 2022 at 05:46:20PM +0100, Thomas Schwinge wrote:
> OK to proceed in this way?
With a suitable ChangeLog entry and one nit fixed yes.
> --- gcc/omp-low.cc
> +++ gcc/omp-low.cc
> @@ -188,7 +188,7 @@ struct omp_context
> static splay_tree all_contexts;
> static int taskreg_nesting_
On Wed, Mar 02, 2022 at 05:22:21PM +, Kwok Cheung Yeung wrote:
> I have updated the patch to catch array elements and structure components as
> additional checks, in addition to checking that the variable is a scalar.
>
> The check has been moved to the end of resolve_omp_clauses as it is more
On Fri, Mar 04, 2022 at 03:47:31PM +0100, Marcel Vollweiler wrote:
> libgomp/ChangeLog:
>
> * libgomp.map: Added omp_get_mapped_ptr.
> * libgomp.texi: Tagged omp_get_mapped_ptr as supported.
> * omp.h.in: Added omp_get_mapped_ptr.
> * omp_lib.f90.in: Added interface for omp
On Thu, Mar 10, 2022 at 05:01:35PM +0100, Marcel Vollweiler wrote:
> --- a/gcc/omp-low.cc
> +++ b/gcc/omp-low.cc
> @@ -3962,6 +3962,7 @@ omp_runtime_api_call (const_tree fndecl)
>"target_is_present",
>"target_memcpy",
>"target_memcpy_rect",
> + "get_mapped_ptr",
>
On Tue, Mar 15, 2022 at 06:05:48PM +0100, Marcel Vollweiler wrote:
> Hi,
>
> This patch fixes a small bug for omp_set_num_teams in fortran.c.
>
> Marcel
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Ha
On Wed, Mar 16, 2022 at 02:06:16PM +0100, Marcel Vollweiler wrote:
> libgomp/ChangeLog:
>
> * fortran.c (omp_set_num_teams_8_): Fix bug.
> * testsuite/libgomp.fortran/icv-8.f90: New test.
Ok, with a minor nit. Please use
Call omp_set_num_teams instead of omp_set_max_active_levels.
in
On Fri, Mar 18, 2022 at 02:15:11PM +0100, Tobias Burnus wrote:
> This patch addresses a side issue found when looking at PR103039.
>
> Namely instead of printing:
>
>55 | !$omp parallel firstprivate(tt)
> | 1
> Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FI
On Fri, Mar 18, 2022 at 05:27:02PM +0100, Tobias Burnus wrote:
> SELECT TYPE, SELECT RANK and ASSOCIATE have
> associate-name => selector
> and create a pointer to the selector.
>
> GCC was fixed to handle CLASS properly in
> class(t) :: var
> !$omp ... firstprivate(var)
> As a side effect,
Hi!
On the gfortran.dg/pr103691.f90 testcase the Fortran ICE emits
static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};
That is an invalid RANGE_EXPR where the maximum is smaller than the minimum.
The following patch fixes that. If TYPE_MAX_VALUE is smaller than
TYPE_MIN_VALUE, the array is empty a
On Fri, Mar 25, 2022 at 12:16:40PM +0100, Richard Biener wrote:
> On Fri, Mar 25, 2022 at 11:13 AM Tobias Burnus
> wrote:
> >
> > On 25.03.22 09:57, Jakub Jelinek via Fortran wrote:
> > > On the gfortran.dg/pr103691.f90 testcase the Fortran ICE emits
> > &g
On Fri, Mar 25, 2022 at 01:13:06PM +0100, Richard Biener wrote:
> > Also, I think typically in the Fortran FE side-effects would go into
> > se.pre and se.post sequences, not into se.expr, and this routine
> > doesn't emit those se.pre/se.post sequences anywhere, so presumably it
> > assumes they d
On Fri, Mar 25, 2022 at 08:02:04PM -0600, Sandra Loosemore wrote:
> I ran into this bug in the handling of clauses on the combined "masked
> taskloop" OMP directive when I was working on something else. The fix
> turned out to be a 1-liner. OK for trunk?
>
> -Sandra
> commit 17c4fa0bd97c0709450
On Fri, Mar 25, 2022 at 08:03:09PM -0600, Sandra Loosemore wrote:
> I've got another patch forthcoming (stage 1 material) that adds some new
> diagnostics for non-rectangular loops during gimplification of OMP nodes.
> When I was working on that, I discovered that the Fortran front end wasn't
> att
On Wed, Apr 13, 2022 at 05:16:48PM +0200, Tobias Burnus wrote:
> Trivial fix – after finding the issue. The LOOP directive and
> several LOOP/DO/SIMD combined directives were missing in the
> check. As the PR shows, this leads to an ICE on invalid code.
>
> OK?
>
> Tobias
> -
> Si
On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
> hadn’t seen.
I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?
Even
On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote:
> LGTM - however:
>
> On 26.04.22 14:38, Mikael Morin wrote:
> > --- a/gcc/fortran/trans-array.cc
> > +++ b/gcc/fortran/trans-array.cc
> > @@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
> > if (DECL_P (expr)
> >
On Tue, Apr 26, 2022 at 07:12:13PM +0200, Mikael Morin wrote:
> > I think we can't in C++11/C++14. The options can be if orig_decl would be
> > declared
> > earlier, then it can be
> > tree orig_decl;
> > if (DECL_P (expr)
> > && DECL_LANG_SPECIFIC (expr)
> > && (orig_decl = GFC
On Wed, Apr 20, 2022 at 03:19:38PM +0200, Tobias Burnus wrote:
> For array-descriptor vars, the descriptor is assigned to a temporary. However,
> this failed when the clause's argument was in turn in a data-sharing clause
> as the outer context's VALUE_EXPR wasn't used.
>
> gcc/ChangeLog:
>
>
On Fri, Mar 25, 2022 at 08:03:38PM -0600, Sandra Loosemore wrote:
> This patch adds support for OMP 5.1 "canonical loop nest form" to the
> Fortran front end, marks non-rectangular loops for processing
> by the middle end, and implements missing checks in the gimplifier
> for additi
On Fri, Feb 18, 2022 at 11:13:16PM +, Hafiz Abid Qadeer wrote:
> An allocate clause in target region must specify an allocator
> unless the compilation unit has requires construct with
> dynamic_allocators clause. Current implementation of the allocate
> clause did not check for this restricti
On Mon, Feb 21, 2022 at 12:19:20PM +0100, Marcel Vollweiler wrote:
> gcc/ChangeLog:
>
> * omp-low.cc (omp_runtime_api_call): Added target_memcpy_async and
> target_memcpy_rect_async to omp_runtime_apis array.
>
> libgomp/ChangeLog:
>
> * libgomp.map: Added omp_target_memcpy_asy
On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
> --- a/libgomp/libgomp.map
> +++ b/libgomp/libgomp.map
> @@ -226,6 +226,11 @@ OMP_5.1 {
> omp_get_teams_thread_limit_;
> } OMP_5.0.2;
>
> +OMP_5.1.1 {
> + global:
> + omp_target_is_accessible;
> +} OMP_5.1;
> +
You'v
On Thu, May 05, 2022 at 11:45:19AM +0200, Tobias Burnus wrote:
> > On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
> > > +interface
> > > + function omp_target_is_accessible (ptr, size, device_num)
> > > bind(c)
> > > +use, intrinsic :: iso_c_binding
On Fri, May 13, 2022 at 07:21:02PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.cc (gfc_trans_omp_clauses): When mapping nondescriptor
> array sections, use GOMP_MAP_FIRSTPRIVATE_POINTER instead of
> GOMP_MAP_POINTER for the pointer attachment.
>
> lib
On Fri, May 13, 2022 at 10:51:56PM +0200, Tobias Burnus wrote:
> This adds omp_all_memory handling to Fortran, following C/C++ and shamelessly
> coping
> the C testcases and adapting them to Fortran.
>
> OK?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: A
On Wed, May 18, 2022 at 11:02:27AM +0200, Tobias Burnus wrote:
> OpenMP: Add Fortran support for inoutset depend-kind
>
> Fortran additions to the C/C++ + ME/libgomp commit
> r13-556-g2c16eb3157f86ae561468c540caf8eb326106b5f
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (enum gfc_omp_depend_
On Thu, May 19, 2022 at 10:39:05AM +0200, Marcel Vollweiler wrote:
> > add here
> >else
> > {
> >depend[0] = 0;
> > ...
> > }
>
> Added the "depend" definition to the "if" branch (instead the "else" branch).
Thanks for correcting my thinko.
> gcc/ChangeLog:
>
> * omp
On Wed, May 11, 2022 at 07:33:00PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/104949
> * f95-lang.cc (LANG_HOOKS_OMP_ARRAY_SIZE): Redefine.
> * trans-openmp.cc (gfc_omp_array_size): New.
> (gfc_trans_omp_variable_list): Never turn has_device_addr
>
On Fri, Mar 18, 2022 at 09:24:51AM -0700, Julian Brown wrote:
> 2021-11-23 Julian Brown
>
> gcc/
> * gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete
> functions.
> (omp_tsort_mark): Add enum.
> (omp_mapping_group): Add struct.
> (debug_mapping_gro
On Fri, Mar 18, 2022 at 09:24:52AM -0700, Julian Brown wrote:
> This patch has been split out from the previous one to avoid a
> confusingly-interleaved diff. The two patches should probably be
> committed squashed together.
Agreed, LGTM.
>
> 2021-10-01 Julian Brown
>
> gcc/
> * gimpli
On Fri, Mar 18, 2022 at 09:24:53AM -0700, Julian Brown wrote:
> 2022-03-17 Julian Brown
>
> gcc/fortran/
> * trans-openmp.cc (gfc_trans_omp_clauses): Don't create
> GOMP_MAP_TO_PSET mappings for class metadata, nor GOMP_MAP_POINTER
> mappings for POINTER_TYPE_P decls.
>
On Fri, Mar 18, 2022 at 09:24:54AM -0700, Julian Brown wrote:
> 2022-03-17 Julian Brown
>
> gcc/c-family/
> * c-common.h (c_omp_address_inspector): New class.
> * c-omp.c (c_omp_address_inspector::get_deref_origin,
> c_omp_address_inspector::component_access_p,
>
On Fri, Mar 18, 2022 at 09:26:46AM -0700, Julian Brown wrote:
> This patch relates to OpenMP mapping clauses containing struct members of
> reference type, e.g. "mystruct.myref.myptr[:N]". To be able to access
> the array slice through the reference in the middle, we need to perform
> an attach ac
On Fri, Mar 18, 2022 at 09:26:47AM -0700, Julian Brown wrote:
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -4266,6 +4266,9 @@ cp_parser_new (cp_lexer *lexer)
>parser->omp_declare_simd = NULL;
>parser->oacc_routine = NULL;
>
> + /* Allow array slice in expression. */
Better /*
On Fri, Mar 18, 2022 at 09:26:49AM -0700, Julian Brown wrote:
> This patch changes the representation of OMP array sections in the
> C++ front end to use the new OMP_ARRAY_SECTION tree code instead of a
> TREE_LIST. This is important for "declare mapper" support, because the
> array section repres
On Fri, Mar 18, 2022 at 09:26:50AM -0700, Julian Brown wrote:
> This patch implements OpenMP 5.0 "declare mapper" support for C++ --
> except for arrays of structs with mappers, which are TBD. I've taken cues
> from the existing "declare reduction" support where appropriate, though
> obviously the
On Tue, May 24, 2022 at 04:48:13PM +0200, Jakub Jelinek wrote:
> > This version of the patch improves detection of explicitly-mapped struct
> > accesses which inhibit implicitly-triggered user-defined mappers for a
> > target region.
>
> Will start with a general comment, from looking at the dumps
On Fri, May 27, 2022 at 04:52:17PM +0200, Tobias Burnus wrote:
> This patch adds the Fortran support to the just-committed C/C++ support for
> the 'enter' clause.
>
> The 'TO'/'ENTER' usage is first stored in a linked list – and
> then as attribute to the symbol. I am not sure how to handle it be
On Fri, May 27, 2022 at 05:20:08PM +0200, Jakub Jelinek wrote:
> 2) move the
> else if (n->sym->mark)
> gfc_error_now ("Variable at %L mentioned multiple times in "
>"clauses of the same OMP DECLARE TARGET directive",
>&n
On Fri, Jun 03, 2022 at 03:37:56PM +0200, Tobias Burnus wrote:
> Simple patch. Testcases based on the C/C++ commit.
> For allocate, I found an unrelated bug which prevented me from adding
> the associated testcase: https://gcc.gnu.org/PR105836
>
> Tested on x86-64 (w/o offloading).
> OK for mainli
On Wed, Jun 08, 2022 at 09:54:07AM +0200, Tobias Burnus wrote:
> The OpenMP requires directive may only be placed in the specification part of
> a program unit (except it happens via the USE of a module).
>
> But the target directive ancestor-requires-'reverse_offload' only checked
> the current n
On Wed, Jun 08, 2022 at 04:00:39PM +0100, Julian Brown wrote:
> > I think big question is if we do want to do this map clause reordering
> > before processing the omp target etc. clauses, or after (during
> > gimplify_adjust_omp_clauses, when clauses from the implicit mappings
> > are added too an
On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc
wrote:
> PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
No. gcc_build is used by maintainer-scripts/gcc_release, so by killing it
you'd make gcc unreleasable.
> It was not updated since th
Hi!
As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex
1 - 100 of 297 matches
Mail list logo
