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
On Thu, Sep 08, 2022 at 05:21:08PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Otherwise LGTM.
Oh, and what Harald wrote, it might be better to split the nowait-4.f90 test
into 2, one for all the valid nowait cases and one for the invalid ones,
such that the first one can be compile tested
On Mon, Aug 29, 2022 at 11:24:52AM +0200, Tobias Burnus wrote:
> PR fortran/106670
>
> gcc/fortran/ChangeLog:
>
> * scanner.cc (skip_fixed_omp_sentinel): Add -Wsurprising warning
> for 'omx' sentinels with -fopenmp.
> * invoke.texi (-Wsurprising): Document additional warni
On Tue, Sep 13, 2022 at 02:01:42PM -0700, Julian Brown wrote:
> --- a/gcc/omp-low.cc
> +++ b/gcc/omp-low.cc
> @@ -1599,8 +1599,11 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> {
> /* If this is an offloaded region, an attach operation should
>only
On Tue, Sep 13, 2022 at 02:01:43PM -0700, Julian Brown wrote:
> This patch has been split out from the previous one to avoid a
> confusingly-interleaved diff. The two patches will be committed squashed
> together.
>
> 2022-09-13 Julian Brown
>
> gcc/
> * gimplify.c (omp_target_reorder_c
On Tue, Sep 13, 2022 at 02:01:44PM -0700, Julian Brown wrote:
> static tree
> -insert_struct_comp_map (enum tree_code code, tree c, tree struct_node,
> - tree prev_node, tree *scp)
> +build_struct_comp_nodes (enum tree_code code, tree grp_start, tree grp_end,
> +
On Tue, Sep 13, 2022 at 02:01:45PM -0700, Julian Brown wrote:
> @@ -9443,6 +9499,41 @@ omp_containing_struct (tree expr)
>return expr;
> }
>
Missing function comment here.
> +static bool
> +omp_mapped_by_containing_struct (hash_map + omp_mapping_group
On Tue, Sep 13, 2022 at 02:03:15PM -0700, Julian Brown wrote:
> This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes to
> the end of the clause list, for offload regions. This ensures that when
> we do the attach operation, both the "attachment point" and the target
> region have bot
On Tue, Sep 13, 2022 at 02:03:16PM -0700, Julian Brown wrote:
> @@ -3440,6 +3437,50 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
> {
> if (pointer || (openacc && allocatable))
> {
> + gfc
On Tue, Sep 13, 2022 at 02:03:17PM -0700, Julian Brown wrote:
> This patch trivially adds braces and reindents the
> OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
> c_finish_omp_clause and finish_omp_clause, in preparation for the
> following patch (to clarify the diff a little).
>
>
On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> This patch is an extension and rewrite/rethink of the following two patches:
>
> "OpenMP/OpenACC: Add inspector class to unify mapped address analysis"
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591977.html
>
> "Ope
On Tue, Sep 13, 2022 at 02:04:30PM -0700, Julian Brown wrote:
> This patch implements OpenMP 5.0 "declare mapper" support for C++.
> This hasn't been fully revised yet following previous review comments,
> but I am including it in this series to demonstrate the new approach to
> gimplifying map cla
On Sun, Sep 18, 2022 at 08:10:00PM +0100, Julian Brown wrote:
> I don't think any ATTACH clauses can appear during
> the gimplify_adjust_omp_clause_1 walk. So, how about this?
LGTM, thanks.
Jakub
On Sun, Sep 18, 2022 at 08:19:29PM +0100, Julian Brown wrote:
> @@ -2609,6 +2672,9 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
>if (clauses == NULL)
> return NULL_TREE;
>
> + hash_map sym_rooted_nl;
Isn't hash_map ctor pretty costly (allocates memory etc.
On Mon, Sep 19, 2022 at 08:40:34PM +0100, Julian Brown wrote:
> On Wed, 14 Sep 2022 15:24:12 +0200
> Jakub Jelinek wrote:
>
> > On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> > > This patch is an extension and rewrite/rethink of the fol
On Fri, Sep 23, 2022 at 08:29:46AM +0100, Julian Brown wrote:
> On Thu, 22 Sep 2022 15:17:08 +0200
> Jakub Jelinek wrote:
>
> > > + bool built_sym_hash = false;
> >
> > So, I think usually we don't construct such hash_maps right away,
> > but have ju
On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:
> While has_device_addr has been implemented (in GCC 12), updating
> use_device_ptr for Fortran was missed.
>
> This patch fixes it: Removing the restrictions and mapping to
> has_device_addr where applicable.
>
> For use_device_ptr s
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi (-fopenmp-simd): Document that also 'assume'
> is enabled.
>
> libgomp/ChangeLog:
>
> * libgomp.texi (OpenMP 5.1 Impl. Status): Mark 'assume' as 'Y'.
>
> gcc/fortran/ChangeLog
On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 04.10.22 12:19, Jakub Jelinek wrote:
>
> On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
>
>
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2749,9 +2749
On Wed, Oct 05, 2022 at 02:29:56PM +0200, Tobias Burnus wrote:
> + gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
s/!OMP/!$OMP/
Otherwise LGTM.
Jakub
On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
> Same as for C/C++, albeit a tiny bit longer patch.
>
> I don't know whether it makes sense to handle – in the long run – the
> case of se.pre/se.post being nonempty – and, if so, how.
I think it is essential not to throw those away,
On Thu, Oct 06, 2022 at 06:15:52PM +0200, Tobias Burnus wrote:
> On 06.10.22 14:17, Jakub Jelinek wrote:
> > On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
> > > I don't know whether it makes sense to handle – in the long run – the
> > > case of se.
i686-linux, committed to trunk.
2022-10-10 Jakub Jelinek
* trans-openmp.cc (gfc_trans_omp_assume): Use create_tmp_var_raw
instead of gfc_create_var for TARGET_EXPR slot creation. Create it
with boolean_type_node and convert.
--- gcc/fortran/trans-openmp.cc.jj 2022-
On Sun, Oct 09, 2022 at 02:51:37PM -0700, Julian Brown wrote:
> This patch adds support for non-constant component offsets in "map"
> clauses for OpenMP (and the equivalants for OpenACC), which are not able
> to be sorted into order at compile time. Normally struct accesses in
> such clauses are g
On Thu, Jan 13, 2022 at 02:53:16PM +, Hafiz Abid Qadeer wrote:
> Currently we only make use of this directive when it is associated
> with an allocate statement.
Sorry for the delay.
I'll start with a comment that allocate directive in 5.0/5.1
for Fortran is a complete mess that has been fixe
On Thu, Jan 13, 2022 at 02:53:17PM +, Hafiz Abid Qadeer wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
> (gfc_trans_omp_allocate): New function.
> (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
>
> gcc/ChangeLog
On Tue, Oct 11, 2022 at 03:22:02PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 11.10.22 14:24, Jakub Jelinek wrote:
>
> There is another issue besides what I wrote in my last review,
> and I'm afraid I don't know what to do about it, hoping Tobias
> has so
On Tue, Oct 11, 2022 at 04:15:25PM +0200, Jakub Jelinek wrote:
> Well, it can use a weak symbol, if not linked against libgomp, the bit
> that it is OpenMP shouldn't be set and so realloc/free will be used
> and do
> if (arrdescr.gomp_alloced_bit)
> GOMP_free (arrdesc
Hi!
Thanks for working on this!
On Tue, Nov 01, 2022 at 09:50:38PM +, Julian Brown wrote:
> > I think we should figure out when we should temporarily disable
> > parser->omp_array_section_p = false;
> > and restore it afterwards to a saved value. E.g.
> > cp_parser_lambda_expression seems
On Wed, Nov 02, 2022 at 12:20:11PM +, Julian Brown wrote:
> > But we can't forbid lambdas inside of the map clause expressions,
> > they are certainly valid in OpenMP, and IMNSHO shouldn't disallow
> > statement expressions, people might not even know they use a
> > statement expression, they c
On Mon, Oct 31, 2022 at 03:46:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: 'target update' with strides + DT components
>
> OpenMP 5.0 permits to use arrays with strides and derived
> type components for the list items to the 'from'/'to' clauses
> of the 'target update' directive.
>
> gcc/f
On Thu, Nov 03, 2022 at 02:35:03PM +0100, Tobias Burnus wrote:
> On 03.11.22 13:44, Jakub Jelinek wrote:
> > [...]
> > Otherwise LGTM, assuming it actually works correctly.
> >
> > I don't remember support for non-contiguous copying to/from devices
> > bein
On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> > Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> > like to cherry pick some commits from LLVM [to fix some stupid errors
> > I've made in LoongArch libasan :(].
>
> I'm sorry but I was really busy with the por
On Tue, Nov 15, 2022 at 01:49:36PM +0100, Martin Liška wrote:
> On 11/15/22 11:07, Jakub Jelinek wrote:
> > On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> >>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> >>> like to
On Tue, Nov 08, 2022 at 02:36:17PM +, Julian Brown wrote:
> @@ -3258,6 +3273,7 @@ c_omp_address_inspector::get_origin (tree t)
> || TREE_CODE (t) == SAVE_EXPR)
> t = TREE_OPERAND (t, 0);
>else if (TREE_CODE (t) == INDIRECT_REF
> +&& TREE_TYPE (TREE_OPERAND
On Fri, Dec 09, 2022 at 09:14:55PM +0100, Tobias Burnus wrote:
> Implementing the 5.1 syntax inside the 'allocate' clause. That's a
> fallout of working on something else...
>
> OK for mainline?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 20
other dg-error there was no space between the string and closing
}, so it was completely ignored and the error was an excess
error.
2022-12-19 Jakub Jelinek
PR fortran/107397
* gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and
add space between dg-err
ve changed.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2023-01-11 Jakub Jelinek
PR fortran/108349
* f95-lang.cc (gfc_init_builtin_function): Fix up function types
for BUILT_IN_REALLOC and BUILT_IN_SINCOS{F,,L}. Formatting fixes.
--- gcc/fortran/f
On Thu, Jan 12, 2023 at 11:22:40AM +0100, Tobias Burnus wrote:
> Rather obvious fix for that ICE.
>
> Comments? If there are none, I will commit it later as obvious.
I think the spec should be clarified, unlike clauses like if, novariants,
nocontext, indirect, final clause operands where we speci
On Thu, Jan 19, 2023 at 03:40:19PM +0100, Tobias Burnus wrote:
> + gfc_symbol *var = code->ext.iterator->var->symtree->n.sym;
> +
> + gfc_se se;
> + tree tree_var, a1, a2;
> + a1 = integer_one_node;
> + a2 = integer_zero_node;
> +
> + gfc_init_se (&se, NULL);
> + gfc_conv_expr_lhs (&se, code
On Fri, Jan 20, 2023 at 06:39:04PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > + The issue is that for those a 'count' variable is used. */
> > +dovar_init *di;
> > +unsigned ix;
> > +tree t = tree_var;
> > +while (TRE
On Fri, Jan 20, 2023 at 07:00:18PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Though, I wonder if we shouldn't for GCC 13 just sorry_at about
> steps other than constant 1/-1 (in both outer loop with var-outer referenced
> in inner loop and on inner loop that references it) and
On Fri, Jan 27, 2023 at 10:19:42AM +0100, Tobias Burnus wrote:
> Rather obvious fix. Hence, I intent to commit it later as obvious,
> unless there are any comments.
Yeah, this is obviously correct.
Have you checked the function if we don't miss other clauses in there
(e.g. compared to the C imple
On Tue, Jan 24, 2023 at 04:24:07PM +0100, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/108512
> * openmp.cc (gfc_resolve_omp_do_blocks): Don't check 'inscan'
> restrictions for loop as rejected elsewhere.
> (gfc_resolve_do_iterator): Set a source location fo
nit step on the loop using an outer var.
>
> Eventually still to be done: replace the 'sorry' by working code, i.e.
> implement the suggestions to handle some/all non-unit iteration steps as
> proposed in this thread.
>
> On 20.01.23 18:39, Jakub Jelinek wrote:
> > I think inste
On Tue, Dec 13, 2022 at 05:38:22PM +0100, Tobias Burnus wrote:
> I missed that 'align' needs to be a power of 2 - contrary to 'aligned',
> which does not have this restriction for some odd reason.
Yeah, odd. The C and C++ FEs indeed diagnose non-pow2p constants
for align (and not for aligned clau
On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
> I recently discovered that libquadmath registers custom printf callbacks
> on load. As far as I can tell, this is done so that the Q format flag
> can be used to print floating point numbers, using format strings such
> as "
On Wed, Feb 01, 2023 at 12:29:02PM +0100, Florian Weimer via Gcc wrote:
> >> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
> >> depends on libquadmath.
> >
> > Not anymore.
> > If GCC is configured against new enough glibc (with _Float128 support)
> > libgfortran.so.5 is no
t, so the following patch does the same.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2023-02-03 Jakub Jelinek
PR fortran/108451
* trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
doing continue.
--- gcc/fortran/trans-decl.cc.jj
On Thu, Feb 09, 2023 at 09:56:09AM +0100, Tobias Burnus wrote:
> Found by chance recently; I thought about a couple of ways to handle it
> but then settled to the proposed solution.
>
> OK for mainline?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfs
On Thu, Feb 09, 2023 at 03:46:35PM +0100, Tobias Burnus wrote:
> I think the test coverage should be sufficient. Any further test idea?
> Otherwise, I would commit it now.
LGTM, thanks.
Jakub
On Fri, Feb 10, 2023 at 12:52:47PM +0100, Tobias Burnus wrote:
> > I'm afraid this is needed but insufficient.
> > I think
> > case EXEC_OMP_MASKED_TASKLOOP:
> > case EXEC_OMP_MASKED_TASKLOOP_SIMD:
> > case EXEC_OMP_MASTER_TASKLOOP:
> > case EXEC_
On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> As mentioned in the TODO for 'deferred', I think we really want
> to have NULL as upper value for the domain for the type, but that
> requires literally hundred of changes to the compiler, which
> I do not want to due during Stage 4,
On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote:
> On 20.02.23 12:15, Jakub Jelinek wrote:
> > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote:
> > > As mentioned in the TODO for 'deferred', I think we really want
> > > to have NULL
On Tue, Feb 21, 2023 at 08:30:50AM +0100, Richard Biener wrote:
> > I think this mostly helps with access inside the FE of the type 'size =
> > TYPE_SIZE_UNIT(type)', which is used surprisingly often and is often
> > directly evaluated (i.e. assigned to a temporary).
>
> that's what I thought
So,
On Tue, Feb 28, 2023 at 05:18:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
>
> For is_device_ptr, optional checks should only be done before calling
> libgomp, afterwards they are NULL either because of absent or, by
> chance, becau
On Fri, Mar 10, 2023 at 06:54:10PM +0100, Thomas Koenig via Gcc-patches wrote:
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
>
> Best r
On Fri, Mar 24, 2023 at 04:30:38PM +0100, Frederik Harwath wrote:
> this patch series implements the OpenMP 5.1 "unroll" and "tile"
> constructs. It includes changes to the C,C++, and Fortran front end
> for parsing the new constructs and a new middle-end
> "omp_transform_loops" pass which impleme
On Mon, May 15, 2023 at 12:19:00PM +0200, Jakub Jelinek via Gcc-patches wrote:
> For C++ in templates we obviously need to defer that until instantiations,
> the constants in the clauses etc. could be template parameters etc.
Even in C++ the how many canonical loop nest form loops doe
On Tue, May 16, 2023 at 11:45:16AM +0200, Frederik Harwath wrote:
> The place where different compilers implement the loop transformations
> was discussed in an OpenMP loop transformation meeting last year. Two
> compilers (another one and GCC with this patch series) transformed the loops
> in the
On Wed, May 17, 2023 at 01:55:00PM +0200, Frederik Harwath wrote:
> Thanks for the explanation. But actually doing this would require a
> complete rewrite which would almost certainly imply that mainline GCC
> would not support the loop transformations for a long time.
I don't think it needs compl
and 13, 12, 11 and 10 release branches.
2023-06-09 Jakub Jelinek
PR fortran/96024
* primary.cc (gfc_convert_to_structure_constructor): Only do
constant string ctor length verification and truncation/padding
if constant length has INTEGER type.
--- gcc/fortran
On Mon, Jul 24, 2023 at 09:43:10PM +0200, Tobias Burnus wrote:
> This patch adds diagnostic for additional code alongside a nested teams
> in a target region.
>
> The diagnostic is happening soon after parsing such that expressions
> in clauses are not yet expanded - those would end up before TEAM
On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote:
> the following works for me. I have only tried a normal build (where it
> does silence the same warning) and not an LTO build and I just believed
> the comment - see attached patch. Comments?
>
> On 28.09.23 08:25, Richard Biener via
On Thu, Sep 28, 2023 at 01:00:41PM +0200, Tobias Burnus wrote:
> I am not aware of any logigal/integer/real(+comples)/character kind > 16,
> except for this PPC one. And complex numbers are pairs of BT_REAL.
>
> Thus, I think that patch should be fine - except:
>
> > Does anything error earlier i
On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote:
> > > The full question of "lto-ing" run time libraries is more
> > > complicated than just "whether it works" as those who attended the
> > > BoF will recall.
> >
> > I didn't attend the Cauldron (but that discussion would have been
> >
On Thu, Mar 11, 2021 at 02:44:38PM +0100, Tobias Burnus wrote:
> Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
>
> gcc/ChangeLog:
>
> PR fortran/98858
> * gimplify.c (omp_add_variable): Handle NULL_TREE as size
> occuring for assumed-size arrays in
On Wed, Mar 10, 2021 at 03:20:51PM +0100, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/99514
> * resolve.c (resolve_symbol): Accept vars which are in DATA
> and hence (either) implicit SAVE (or in common).
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/99514
On Wed, Mar 10, 2021 at 03:20:42PM +0100, Tobias Burnus wrote:
> The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
> the attribute 'omp declare target implicit'.
>
> That's later processed (for C++) in decl.c - which remove that attribute
> and either keeps and explicit 'o
On Mon, Mar 15, 2021 at 09:17:47AM +0100, Tobias Burnus wrote:
> gcc/c/ChangeLog:
>
> PR c++/99509
> * c-decl.c (finish_decl): For 'omp declare target implicit' vars,
> ensure that the varpool node is marked as offloadable.
>
> gcc/cp/ChangeLog:
>
> PR c++/99509
> *
On Wed, Mar 17, 2021 at 07:19:29PM +0100, Tobias Burnus wrote:
> @@ -1831,6 +1852,7 @@ show_omp_node (int level, gfc_code *c)
> case EXEC_OMP_FLUSH: name = "FLUSH"; break;
> case EXEC_OMP_MASTER: name = "MASTER"; break;
> case EXEC_OMP_ORDERED: name = "ORDERED"; break;
> +case EX
On Tue, Apr 20, 2021 at 11:58:32AM +0200, Tobias Burnus wrote:
> is there a reason why you did not apply the patch to mainline ('master')
> but only to GCC 11 ('releases/gcc-11')?
>
> While GCC 11 is okay, I had expected it to be (only) on mainline!
r11-8255 is before the branchpoint, so is both
On Tue, Apr 27, 2021 at 03:36:38PM +0200, Tobias Burnus wrote:
> OpenMP 5's iterator can be used for
> - depend clause
> - affinity clause
> - mapping (unsupported and not touched)
>
> (a) This patch add the iterator support to the Fortran FE
> and adds support for it to the depend clause.
>
> (b
On Wed, Apr 28, 2021 at 10:26:44PM +0200, Tobias Burnus wrote:
> On 28.04.21 15:41, Jakub Jelinek wrote:
> > > @@ -261,6 +263,7 @@ gfc_match_omp_variable_list (const char *str,
> > > gfc_omp_namelist **list,
> > > + gfc_gobble_whitespace ();
&g
On Fri, May 14, 2021 at 06:15:15PM +0200, Tobias Burnus wrote:
> (Testcase requires just posted "Fortran/OpenMP: Handle
> implicit SAVE for variables in main" patch.)
> (Found when looking the testcases generated for PR 99928
> but otherwise not related to that PR.)
>
>
> "omp parallel master"
On Fri, May 14, 2021 at 06:13:55PM +0200, Tobias Burnus wrote:
> Found when working on another patch. Variables in the specification
> part of a module – but also in a main program are implicitly SAVE.
>
> Likewise for variables with initialization - but that was already
> handled.
>
> OK for mai
On Mon, May 17, 2021 at 12:27:22PM +0200, Tobias Burnus wrote:
> OK for mainline?
> It is an ice-on-invalid; does a GCC 11 backport nonetheless make sense?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955
On Thu, May 20, 2021 at 10:47:52AM +0200, Marcel Vollweiler wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1710,10 +1710,21 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
> && gfc_match ("map ( ") == MATCH_YES)
> {
>
On Thu, May 20, 2021 at 04:11:10PM +0200, Marcel Vollweiler wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1710,27 +1710,62 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
> && gfc_match ("map ( ") == MATCH_YES)
> {
>
On Wed, Mar 10, 2021 at 11:55:43AM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -360,6 +360,39 @@ gfc_has_alloc_comps (tree type, tree decl)
>return false;
> }
>
> +/* Return true if TYPE is polymorphic but not with pointer attribute.
On Thu, May 27, 2021 at 08:30:33PM +0200, Tobias Burnus wrote:
> + if (c_parser_next_token_is (parser, CPP_NAME))
> +{
> + const char *p = IDENTIFIER_POINTER (c_parser_peek_token
> (parser)->value);
> + bool parse_iter = (strcmp ("iterator", p) == 0);
> + if (parse_iter)
I'd a
On Thu, May 27, 2021 at 07:58:03PM +, Joseph Myers wrote:
> On Thu, 27 May 2021, Tobias Burnus wrote:
>
> > @Joseph: I CC'ed you in case you have comments regarding
> > c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
> > and c_parser_check_tight_balanced_raw_token_sequ
On Fri, May 28, 2021 at 12:59:20AM +0200, Tobias Burnus wrote:
> * gfortran.dg/gomp/depend-iterator-1.f90: New test.
> * gfortran.dg/gomp/depend-iterator-2.f90: New test.
Something I've missed during the review but it shows up during testing:
> diff --git a/gcc/testsuite/gfortran.dg/g
On Mon, May 31, 2021 at 10:14:34AM +0200, Christophe Lyon wrote:
> > Something I've missed during the review but it shows up during testing:
> >
> > > diff --git a/gcc/testsuite/gfortran.dg/gomp/depend-iterator-1.f90
> > > b/gcc/testsuite/gfortran.dg/gomp/depend-iterator-1.f90
> > > new file mode
On Tue, Jun 01, 2021 at 11:53:12AM +0200, Tobias Burnus wrote:
> Fortran/OpenMP: Support (parallel) master taskloop (simd) [PR99928]
>
> PR middle-end/99928
>
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_node, show_code_node): Handle
> (parallel) master taskloop (
On Thu, Jun 03, 2021 at 12:30:50AM +0200, Tobias Burnus wrote:
> This patch adds support for 'omp loop' to gfortran including the combined
> constructs. It also fixes some splitting issues with clauses in
> combined constructs.
>
> It does not attempt to clean up all remaining Fortran issues with
On Thu, Jun 03, 2021 at 05:07:22PM +0200, Jakub Jelinek via Gcc-patches wrote:
> I think best would be just to remove that part of the testcase
> in the loop patch and handle the !$omp with !$acc continuations
> and vice versa in a separate change. That seems to be a preexisting
> bu
On Fri, Jun 04, 2021 at 05:28:37PM +0200, Tobias Burnus wrote:
> Fortran: Fix OpenMP/OpenACC continue-line parsing
>
> gcc/fortran/ChangeLog:
>
> * scanner.c (skip_fixed_omp_sentinel): Set openacc_flag if
> this is not an (OpenMP) continuation line.
> (skip_fixed_oacc_sentinel):
On Mon, Jun 07, 2021 at 03:21:10PM +0200, Tobias Burnus wrote:
> +static void
> +gfc_add_clause_implicitly (gfc_omp_clauses *clauses_out,
> +gfc_omp_clauses *clauses_in,
> +bool is_target, bool is_parallel_do)
> +{
> + int clauselist_to_add = is_targ
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:
201 - 300 of 374 matches
Mail list logo
