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, 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: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 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
Hi!
The pr96024.f90 testcase ICEs on big-endian hosts. The problem is
that length->val.integer is accessed after checking
length->expr_type == EXPR_CONSTANT, but it is a CHARACTER constant
which uses length->val.character union member instead and on big-endian
we end up reading constant 0x100
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
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 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 does this
transf
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 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 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 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 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 as upper value for the domain for the
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 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 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 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
Hi!
The first testcase in the PR (which I haven't included in the patch because
it is unclear to me if it is supposed to be valid or not) ICEs since extra
hash table checking has been added recently. The problem is that
gfc_trans_use_stmts does
tree *slot = entry->decls->find_slot_with_
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
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 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, Jan 25, 2023 at 03:47:18PM +0100, Tobias Burnus wrote:
> updated patch included, i.e. avoiding 'count' for 'j' when a 'j.0' would
> do (i.e. only local var without the different step calculation). I also
> now reject if there is a non-unit step on the loop using an outer var.
>
> Eventuall
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
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 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 for the !VAR_P ca
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 (TREE_CODE (t) == INDIRECT_REF)
> > + t = TREE_OPERAN
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 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
Hi!
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad which changed
- tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
- tmp = tree_cons (NULL_TREE, size_type_node, tmp);
- ftype = build_function_type (pvoid_typ
On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote:
> The attached patch fixes a regression and is a patch from Steve. I have
> regression tested it and provided a test case. It is fairly simple and I
> will commit under the "simple" rule in a little while.
>
> Thanks Steve
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
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 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 cherry pick some commits from LLVM [to
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 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
> > being actually added, [...] And I think it is
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 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
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 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 (arrdescr.data, 0);
> else
>
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 some ideas.
> The problem is that withou
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 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 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, Oct 06, 2022 at 06:15:52PM +0200, Tobias Burnus wrote:
> Like as attached? – It did survive regtesting.
Like in other spots in trans-openmp.cc that create a TARGET_EXPR, the
slot has to be created with create_tmp_var_raw, because gfc_create_var
adds the var to BLOCK_VARS and that ICEs duri
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.pre/se.post being nonempty – and,
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 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 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,9 @@ have support for @option{
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 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 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 just pointer to the hash map initialized to N
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 following two
> > > patches:
> > >
> > > "Op
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 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 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 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: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: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: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: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: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: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: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 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 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 all t
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 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 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
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors below are reported only when one
runs ./f951 -static-libgfortran
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;
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 Wed, Aug 17, 2022 at 10:28:29AM +0200, Mikael Morin wrote:
> Tobias approved it already, but I spotted what looks like typos.
> See below.
Thanks for catching that.
> > --- gcc/config/darwin.h.jj 2022-08-16 14:51:14.529544492 +0200
> > +++ gcc/config/darwin.h 2022-08-16 14:53:54.402460097
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-linux.
> 2022-
Hi!
The following patch is a revival of the
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html
patch. While trunk configured against recent glibc and with linker
--as-needed support doesn't really need to link against -lquadmath
anymore, there are still other targets where libquadmat
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
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
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.
(conv_in
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 makes use of the new __builtin_issignaling,
so it no longer needs the fallback implementation and can use
the builtin even where glibc provides the macro.
Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux
and powerpc64le-linux, ok for trunk?
2022-08-15
Hi!
The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use
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
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 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 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 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 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
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): A
Hi!
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which i
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
> > constants etc.
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 otherwise.
> T
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.
> >
> I agree with that
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
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 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 do configure in li
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
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
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
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 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 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
1 - 100 of 297 matches
Mail list logo
