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 a
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
quot;
> 107 | && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> | ^
This is what I've committed as obvious:
2022-01-12 Jakub Jelinek
* libgfortran.h (POWER_IEEE128): Use __GLIBC_PREREQ in a separate
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
So, this change reverts that mistake and instead adds $(version_dep) to
what is removed during make clean (clean-local in particular).
The reversion committed under the reversion of our own patches policy,
the clean-local change considered obvious, committed to trunk.
2022-01-14 Jakub Jelinek
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
-linux, ok for trunk?
2022-01-21 Jakub Jelinek
* lang.opt (fconvert=): Add EnumSet property and mention also
r16_ieee and r16_ibm arguments.
(big-endian, little-endian, native, swap): Add Set(1) property.
(r16_ieee, r16_ibm): New EnumValue entries with Set(2
754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.
Ok for trunk?
2022-01-25 Jakub Jelinek
* i
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
t we check that in an IF ->block is non-NULL
and then immediately dereference ->block->next->op, but on invalid
code with no statements in the then clause ->block->next might be NULL.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk.
2022-02-02 Jakub J
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
> > > scal
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,
unk?
2022-03-25 Jakub Jelinek
PR fortran/103691
* trans-array.cc (gfc_conv_array_initializer): If TYPE_MAX_VALUE is
smaller than TYPE_MIN_VALUE (i.e. empty array), throw the initializer
on the floor, if TYPE_MIN_VALUE is equal to TYPE_MAX_VALUE, use just
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
_OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.
2022-04-25 Jakub Jelinek
PR fortran/103662
* lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
a var defini
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 comm
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
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
powerpc64le-linux, guess we'll need to test 3 configurations, glibc < 2.26,
glibc 2.26 to 2.31 and glibc 2.32 and later.
2022-06-23 Jakub Jelinek
gcc/fortran/
* gfortran.h (gfc_real_inf0: Add c__Float128 bitfield.
* trans-types.h (gfc_real16_is_float128): Updat
On Thu, Jun 23, 2022 at 10:49:55PM +0200, Harald Anlauf wrote:
> > We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
> > instead of *q) and library change.
>
> this is quite an important change in the gfortran ABI, as it will
> require recompilation of (library) code using
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
> We currently use
> %rename lib liborig
> *lib: %{static-libgfortran:--as-needed} -lquadmath
> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
> in libgfortran.spec (on targets where we
Hi!
Testing this on powerpc64le-linux revealed some problems
with the patch when gcc is configured against glibc 2.26 through 2.31.
Here is incremental patch (against the v2 patch) that fixes it.
Built and tested on powerpc64le-linux with glibc 2.28, ok for trunk?
2022-06-24 Jakub Jelinek
On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> I don’t like the _Float128 vs __float128 business, it’s confusing.
> And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> they seem to be basically the same thing, so it’s also redundant.
I thought __float128 and
On Mon, Jun 27, 2022 at 01:56:10PM +0200, Mikael Morin wrote:
> Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
> > Still, using __float128 when the APIs are declared for __float128 and
> > _Float128 when the APIs are declared for _Float128 can be better for
> > consistency
On Mon, Jun 27, 2022 at 03:30:49PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
> of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
> constants etc. when using libquadmath and f128/F128
On Tue, Jun 28, 2022 at 10:35:03AM +0200, Tobias Burnus wrote:
> On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote:
>
> > Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
> > of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
which determines whether
HAVE_FLOAT128 is defined or whether to use libquadmath, so that e.g. on
aarch64 where long double is IEEE quad we don't do that.
Tested by Tamar on aarch64 and by me on x86_64-linux, ok for trunk?
2022-06-29 Jakub Jelinek
PR bootstrap/106137
* ac
Hi!
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _Float128 in a comment.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128
On Thu, Jun 30, 2022 at 02:30:24PM +0200, Tobias Burnus wrote:
> OK for mainline - or should I put that patch into the bin?
Not sure, the other match* macros also aren't wrappers
around another macro and with the internal macro it means we'll
need to parse more many times (even when we then fold t
On Fri, Jul 01, 2022 at 05:41:27PM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.cc
> +++ b/gcc/fortran/dump-parse-tree.cc
> @@ -1414,6 +1414,11 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
> case OMP_MAP_TO: fputs ("to:", dumpfile); break;
> case OMP_
On Mon, Jul 04, 2022 at 04:10:03PM +0200, Tobias Burnus wrote:
> This patch adds support for the OpenMP 5.2 syntax for the linear clause,
> following the C/C++ patch. The testcases are modified versions from the
> C/C++ ones, plus one added one for duplicated modifiers.
>
> At least to me it is no
On Mon, Jul 04, 2022 at 06:09:31PM +0200, Tobias Burnus wrote:
> thanks for the comment & spec referral. I have now updated the patch –
> and included the new C/Fortran testcase.
Thanks.
> + while (true)
> + {
> + old_loc = gfc_current_locus;
> +
On Mon, Jul 04, 2022 at 08:29:37PM +0200, Tobias Burnus wrote:
> Fortran part to C/C++
> commit r13-1002-g03b71406323ddc065b1d7837d8b43b17e4b048b5
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (gfc_omp_namelist): Update by creating 'linear' struct,
> move 'linear_op' as 'op' to id and a
On Fri, Jul 29, 2022 at 11:47:54AM +0200, Tobias Burnus wrote:
> Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90
> checks essentially the same, except that it uses an array-descriptor array
> (assumed shape) while this testcase uses an assumed-size array.
>
> I decided f
ng point object.
Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk / 12.2?
2022-07-30 Jakub Jelinek
PR libfortran/106079
* io/transfer.c (formatted_transfer_scalar_read,
formatted_transf
-15 Jakub Jelinek
* ieee/ieee_helper.c: Don't include issignaling_fallback.h.
(CLASSMACRO): Use __builtin_issignaling instead of issignaling.
* ieee/issignaling_fallback.h: Removed.
--- libgfortran/ieee/ieee_helper.c.jj 2022-06-27 15:34:47.111928150 +0200
+++ libgfo
Hi!
The following patch expands IEEE_CLASS inline in the FE, using the
__builtin_fpclassify, __builtin_signbit and the new __builtin_issignaling
builtins.
Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux
and powerpc64-linux, ok for trunk?
2022-08-15 Jakub Jelinek
Hi!
The following patch expands IEEE_VALUE function inline in the FE.
Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux
and powerpc64-linux, ok for trunk?
2022-08-15 Jakub Jelinek
PR fortran/106579
* trans-intrinsic.cc: Include realmpfr.h
On Mon, Aug 15, 2022 at 09:47:45PM +0200, FX wrote:
> Question to the Fortran maintainers:
>
> Do you know if the standard allows IEEE_CLASS and IEEE_VALUE to be used as
> procedure pointers? I think not, because they do not follow (in F2008) the
> standard constraint C729 / R740.
>
> If so, we
On Mon, Aug 15, 2022 at 10:00:02PM +0200, FX wrote:
> I have two questions, on this and the ieee_class patch:
>
>
> > + tree type = TREE_TYPE (arg);
> > + gcc_assert (TREE_CODE (type) == RECORD_TYPE);
> > + tree field = NULL_TREE;
> > + for (tree f = TYPE_FIELDS (type); f != NULL_TREE; f = DE
d.
So far slightly tested on x86_64-linux (and will bootstrap/regtest
it there tonight), but I unfortunately don't have a way to test it
e.g. on Darwin.
Thoughts on this?
2022-08-16 Francois-Xavier Coudert
Jakub Jelinek
PR fortran/46539
gcc/
* common.opt (static-li
On Tue, Aug 16, 2022 at 04:31:03PM +0200, Jakub Jelinek via Gcc-patches wrote:
> So far slightly tested on x86_64-linux (and will bootstrap/regtest
> it there tonight), but I unfortunately don't have a way to test it
FYI, successfully bootstrapped/regtested on x86_64-linux and i686-lin
e spec file.
Here is an updated version (but nothing relevant to Linux changed, so there
is no point for me to bootstrap/regtest it again):
2022-08-17 Francois-Xavier Coudert
Jakub Jelinek
PR fortran/46539
gcc/
* common.opt (static-libquadmath): New option.
* gcc.c
On Tue, Aug 16, 2022 at 04:45:07PM +0200, Tobias Burnus wrote:
> Fixed subject line: "absent linear" should be "absent linear step" in the
> subject line;
> i.e. with "step" added: "Fortran: OpenMP fix declare simd inside modules and
> absent linear step [PR106566]"
>
> I have also decided to mo
On Thu, Aug 18, 2022 at 11:35:06AM +0100, Iain Sandoe wrote:
> > --- gcc/fortran/options.cc.jj 2022-01-18 11:58:59.568982256 +0100
> > +++ gcc/fortran/options.cc 2022-08-16 14:56:22.807525218 +0200
> > @@ -692,6 +692,13 @@ gfc_handle_option (size_t scode, const c
> > #endif
> > break;
andle those options through other means.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-08-20 Jakub Jelinek
PR fortran/46539
* lang.opt (static-libgfortran, static-libquadmath): Change Fortran
to Driver.
* options.cc (gfc_handle_o
On Thu, Sep 01, 2022 at 10:04:58AM +0200, FX wrote:
> Fortran 2018 introduced intrinsic functions for all the IEEE-754 comparison
> operations, compareQuiet* and compareSignaling* I want to introduce those
> into the Fortran front-end, and make them emit the right code. But cannot
> find the co
On Thu, Sep 01, 2022 at 11:04:03AM +0200, FX wrote:
> Hi Jakub,
>
> >> 2. All the functions are available as GCC type-generic built-ins (yeah!),
> >> except there is no __builtin_ iseqsig
> >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a
> >> fundamental problem with creating
On Fri, Aug 26, 2022 at 08:21:26PM +0200, Tobias Burnus wrote:
> I did run into some issues related to this; those turned out to be
> unrelated, but I end ended up implementing this feature.
>
> Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
> now, but I guess that's an un
101 - 200 of 367 matches
Mail list logo
