On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote:
> If approved, I suggest committing this foundational change first. Constant
> folding for these builtins will be addressed in subsequent patches.
Note, not just constant folding is needed, but I think the builtins should
be handled in
tree-
stcase fails under valgrind without the libgfortran changes and
succeeds with those.
Tested on x86_64-linux and i686-linux, ok for trunk?
2025-05-13 Jakub Jelinek
PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather than
i >=
obably not worth it. */
dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.
Tested on x86_64-linux and i686-linux, ok for trunk?
2025-05-12 Jakub Jelinek
frequently used path so probably not worth it. */
dest -= dstride[n] * extent[n];
So, I believe the easiest fix would be to somehow arrange for the
" * string_len" subtrings to be omitted twice, but am not sure where and
how.
2025-05-12 Jakub Jelinek
PR fortran/12
ibrary side, so I'll post it incrementally.
2025-05-12 Jakub Jelinek
Daniil Kochergin
Tobias Burnus
PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actua
ned(kind=1). I've made sure TYPE_CANONICAL of the unsigned(kind=1)
type is still character(kind=1), so they are considered compatible by
the middle-end also e.g. for aliasing etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and later on for 15.2?
2025-05-09
On Fri, May 09, 2025 at 06:18:40PM +0300, Daniil Kochergin wrote:
> PR fortran/120191
>
> * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc):
>
> Call strip_kind_from_actual unconditionally.
>
>
> * gfortran.dg/pr120191.f90: New test.
This unfortunately only fixes some of the cases in the new
in expands to 0 for atype_name
GFC_UINTEGER*.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
*
symbol version as they've never been there, so the patch
adds them to a new GFORTRAN_15.2 symbol version instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120153
* Makefile.am (i_maxloc1_c): Add gen
/regtested on x86_64-linux and i686-linux, ok for trunk
and 15.2?
2025-05-07 Jakub Jelinek
PR libfortran/120152
* Makefile.am (i_maxloc1_c): Readd generated/maxloc1_4_i8.c,
generated/maxloc1_8_i8.c, generated/maxloc1_16_i8.c,
generated/maxloc1_4_i16.c, generated
On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
>
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
>
> Regards,
>
> Jerry
>
> See attached diff.
>
> 2025-04-18 Steven G
hing. Note, you'd need
to drop the -O3 from dg-options in that case for sure, because with explicit
-O3 option in there it cycles through -O0 -O3, -O1 -O3, -O2 -O3,
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O3,
-O3 -g -O3, -Os -O3.
Ok for trunk?
Or do you
ave a few occurrences, but not too much).
Ok for trunk?
2025-03-28 Jakub Jelinek
* lib/gfortran-dg.exp: Don't cycle through the option list if
dg-options or dg-additional-options contains -O after space, tab,
double quote or open curly bracket.
* gfortran
On Thu, Mar 27, 2025 at 07:34:14PM +0100, Jakub Jelinek wrote:
> The following patch runs the test only in the -O3 -g case (just using -O3
> there would run it twice, once with
> -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions
> and once with
&g
Hi!
ICE on this test was fixed by r15-2131. This just adds test for it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-03-06 Jakub Jelinek
PR fortran/104826
* gfortran.dg/gomp/pr104826.f90: New test.
--- gcc/testsuite/gfortran.dg
On Thu, Jan 09, 2025 at 06:12:51PM +0100, Andre Vehreschild wrote:
> Yes, that is what I had in mind. Being German I don't see any problem with the
> explanation, but that is better judged by a native English speaker.
>
> Is the send patch hunk intentional where only indentation is changed? I
> h
On Thu, Jan 09, 2025 at 03:28:28PM +0100, Jakub Jelinek wrote:
> So like this?
Thomas mentioned bad wording in a private mail. Here is a better patch:
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
27;ve also added an assert, I think it isn't really needed to assert that
symbol[i].id == a in each case, just that we increment i for all the cases.
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/118337
> * module.cc (use_iso_fortran_env_module): Prevent additional run
> over (un-)signed ints and assign kind directly.
> ---
> gcc/fortran/module.cc | 13 ++---
On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote:
> I'm testing for that instead:
> --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100
> +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100
> @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (voi
On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> One of the issues are lines:
>
> module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
> adjacent maybe?!
>
> I have changed this:
>
> diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
> index
On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> Hi,
>
> I have added this small patch (attached). Unfortunately I got regressions
>
> some in iso_fortran_env_8.f90
> and several in unsigned_NN.f90 tests.
>
> Just retesting w/o my patch and already seeing the iso_fortran_env
On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote:
> I think your patch is enough, we don't need to target same-bytes formats
> between module versions.
I can confirm the ICE on the small reproducer I've posted is gone with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
> Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
> >
> > The full list of changes with the posted patches is
> > (first a.mod, then b.mod, 14 -> 15) below.
> > I have no idea what adds those __copy_* elts
On Wed, Jan 08, 2025 at 12:42:39PM +0100, Andre Vehreschild wrote:
> Er, call me stupid, but what is the easiest way to apply your patch? 'git am'
> on
> the part from the date-line to the end stripping your greetings, always leads
> to unrecognized patch format. Using `patch -p1` did not work eit
On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> type
> getting the recursive marker enforces the generation of the vtype for it. I
> don't see yet, why the iso_c_binding_C_funptr should be marked as r
On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote:
> marking the vtypes as recursive is odd, but should not be taken as any
> incompatibility marker. Pre version 15 gfortran does not check the recursive
> attr on types. So whether it is set or not, is of no concern to gfortran <=
>
On Wed, Jan 08, 2025 at 10:47:39AM +0100, Richard Biener wrote:
> I wonder if we can somehow add some test coverage? Are .mod files
> target independent and thus can we include them in the testsuite?
They are, but they are compressed and having binary data in the testsuite
is a problem. But perh
59 -> 63, numeric_storage_size 60 -> 64, etc.
So, I really don't know if it is feasible to ensure backwards compatibility.
Plus how we would actually test whether we are able to accept the older
modules in newer compilers.
2025-01-08 Jakub Jelinek
PR fortran/118337
also MOD_VERSION "15",
but it is unfinished.
2025-01-08 Jakub Jelinek
PR fortran/118337
* module.cc (MOD_VERSION): Bump to "16".
--- gcc/fortran/module.cc.jj2025-01-02 11:47:31.697201637 +0100
+++ gcc/fortran/module.cc 2025-01-07 21:41:46.866494776 +010
On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > So, this patch is an alternative to the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > patch, which had the major problem that it required changing all the
> > DWARF consumers to be able to debug C17 or
On Tue, Dec 03, 2024 at 10:34:34AM +0100, Tobias Burnus wrote:
> --- a/gcc/testsuite/c-c++-common/gomp/allocate-18.c
> +++ b/gcc/testsuite/c-c++-common/gomp/allocate-18.c
> @@ -17,14 +17,14 @@ typedef enum omp_allocator_handle_t
>
> void test0 ()
> {
> - int A1[5];
> + int A1[5], B1[1];
I'd
On Fri, Nov 15, 2024 at 07:45:32AM +, Paul Richard Thomas wrote:
> Hi Jakub,
Honza's catch.
> Good catch! Does it fix any specific PR?
Dunno. I think even without a PR it can be backported after a while.
Jakub
On Thu, Nov 14, 2024 at 08:58:26PM +0100, Jan Hubicka wrote:
> fortran produces malloc call with signed size instead of unsigned. This
> in turn makes gimple_call_builtin_p to fail type checking and we do not
> treat the call as malloc call.
>
> regtested x86_64-linux, OK?
>
> gcc/fortran/ChangeL
On Sun, Sep 22, 2024 at 11:47:09PM +0200, Andreas Schwab wrote:
> On Sep 22 2024, Jakub Jelinek wrote:
>
> > On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
> >> On Sep 22 2024, Mikael Morin wrote:
> >>
> >> > @@ -370,7 +370,7 @@ Set th
On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
> On Sep 22 2024, Mikael Morin wrote:
>
> > @@ -370,7 +370,7 @@ Set the default accessibility of module entities to
> > @code{PRIVATE}.
> > Use-associated entities will not be accessible unless they are explicitly
> > declared as @
On Sun, Sep 22, 2024 at 04:17:11PM +0200, Mikael Morin wrote:
> -@opindex @code{std=}@var{std} option
> +@opindex std=@var{std} option
IMHO this one should be just
@opindex std=@var{std}
The option part is superfluous.
> -@opindex @code{idirafter @var{dir}}
> +@opindex idirafter @var{dir}
> -@op
On Sat, Sep 21, 2024 at 04:32:38PM +0200, Mikael Morin wrote:
> Thanks for the tip.
> The Makefile dependencies seem to be incomplete.
> Here is what I get:
AFAIK right now one needs to configure at least c,c++,fortran,d
in --enable-languages (or some superset thereof) and
make -C gcc html
make -C
On Mon, Sep 16, 2024 at 10:52:43AM +0200, Mikael Morin wrote:
> > While I understand the intent of 'positive form' vs 'negative form', the
> > above might be clearer as
> >
> > Usage of intrinsics can be implemented either by generating a call
> > to the libgfortran library function or by
Hi!
On Thu, Aug 15, 2024 at 08:50:38PM +0200, Jakub Jelinek wrote:
> > whoopsie, I am sorry for that.
> >
> > What I don't get is, why this has not been reported during my bootstrap. I
> > am
> > doing this to bootstrap:
> >
On Thu, Aug 15, 2024 at 08:30:12PM +0200, Andre Vehreschild wrote:
> Hi Harald,
>
> whoopsie, I am sorry for that.
>
> What I don't get is, why this has not been reported during my bootstrap. I am
> doing this to bootstrap:
>
> LANG=C "${SRCPATH}/configure" \
> --disable
On Wed, Aug 07, 2024 at 06:58:23PM +0200, Jakub Jelinek wrote:
> > For Fortran, this plus into gfc_get_extern_function_decl, i.e. that name
> > appears as external declaration. While the user could mess around, it checks
> > that it is a function and the return type is th
On Wed, Aug 07, 2024 at 05:57:05PM +0200, Tobias Burnus wrote:
> for C/C++, -fno-builtin-omp_is_initial_device already disabled the
> expansion.
Good idea.
> RFC: Should be document this new built-in some where? If so, where? As part
> of the routine description in libgomp.texi? Or in extend.texi
On Wed, Aug 07, 2024 at 02:08:42PM +0200, Tobias Burnus wrote:
> On Aug 1, 2024, Jakub Jelinek wrote:
> > On Tue, Jul 30, 2024 at 10:51:56PM +0200, Tobias Burnus wrote:
> > > - char id[sizeof (SSDF_IDENTIFIER) + 1 /* '\0' */ + 32];
> > > + tree name;
>
On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote:
> I agree with all of that. Sure keeping the condition around would be the
> safest. I'm just afraid of keeping code that would remain dead.
>
> > > > And the pasto fix would guess fix
> > > > aliasing_dummy_5.f90 with
> > > > a
On Fri, Aug 02, 2024 at 04:58:09PM +0200, Mikael Morin wrote:
> > But the function actually returns 0 rather than 1 that PR45019 meant.
> > So I bet in addition to fixing the pasto we should move that conditional
> > from where it is right now to the return 0; location after
> > check_data_pointer_
On Thu, Aug 01, 2024 at 09:03:39PM +0200, Mikael Morin wrote:
> Le 01/08/2024 à 12:00, Jakub Jelinek a écrit :
> > Hi!
> >
> > A static analyzer found what seems like a pasto in the PR45019 changes,
> > the second branch of || only accesses sym2 while the first one s
ase_decl;
if (!integer_zerop (data_off))
t = fold_build_pointer_plus (t, data_off);
earlier in, because at least in the current ABI data_off is always 0 and
integer_zerop is less expensive than getting through match.pd to find out
that POINTER_PLUS_EXPR something 0 is something, there are no other
inte
linux
successfully, ok for trunk?
2024-08-01 Jakub Jelinek
* dependency.cc (gfc_check_dependency): Fix a pasto, check
sym1->as->type for AS_ASSUMED_SHAPE rather than sym2->as->type.
Formatting fix.
--- gcc/fortran/dependency.cc.jj2024-07-01 11:28:2
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-01 Jakub Jelinek
* trans-types.cc (gfc_get_array_descr_info): Add rank_off to t
if rank_off isn't zero rather than dtype_off.
--- gcc/fortran/trans-types.cc.jj 2024-07-19 17:22:59.4050970
On Mon, Jul 29, 2024 at 09:53:47AM +0200, Tobias Burnus wrote:
> Hi Andre, hi all,
>
> Andre Vehreschild wrote:
> > yes, I could have looked harder 🙂
>
> I wrote ;-) on purpose as this feature is somewhat hidden and writing 'dg-do
> compile' doesn't harm.
I think an explicit dg-do is better, oth
On Sun, Apr 28, 2024 at 10:37:06PM +0100, Paul Richard Thomas wrote:
> Could this be looked at quickly? The timing of this regression is more than
> a little embarrassing on the eve of the 14.1 release. The testcase and the
> comment in gfc_trans_class_init_assign explain what this problem is all
>
On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote:
> Using dummy procedures in a target region with 'defaultmap(none)' leads to:
>
> Error: 'g' not specified in enclosing 'target'
>
> and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
> are rejected as "E
On Fri, Feb 23, 2024 at 12:25:54PM +0100, Tobias Burnus wrote:
> When checking something else, I noticed that there was one warning in
> openmp.cc that did not use OPT_Wopenmp.
>
> I intent to commit the attached patch later today as obvious.
>
> Tobias
> Fortran/Openmp: Use OPT_Wopenmp for gfc_
On Sat, Feb 17, 2024 at 04:05:16PM +0100, Harald Anlauf wrote:
> > +program pr113503
> > + implicit none
> > + type :: T
> > +character(len=:), allocatable :: u
> > + end type
> > + character(len=20) :: us(1) = 'foobar'
> > + type(T) :: x
> > + x = T(u = trim (us(1))) ! { dg-bogus "is us
nd_decl expressions, so hacks like save the previous
value, overwrite it temporarily over some call that will use expr2 and
restore afterwards aren't needed - there are no such calls, so the
following patch fixes it just by not messing up with
expr2->ts.u.cl->backend_decl, only set
On Thu, Jan 04, 2024 at 08:43:26PM -0500, Lipeng Zhu wrote:
> This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
> not defined in dec_waiting_unlocked function. As io.h does
> not include async.h, the WRLOCK and RWUNLOCK macros are
> undefined.
>
> libgfortran/ChangeLog:
>
> * io/i
On Fri, Jan 05, 2024 at 12:23:26PM +, Julian Brown wrote:
> * g++.dg/gomp/bad-array-section-10.C: New test.
This test FAILs in C++23/C++26 modes, just try
make check-g++ GXX_TESTSUITE_STDS=98,11,14,17,20,23,26
RUNTESTFLAGS=gomp.exp=bad-array-section-10.C
While in C++20 comma in ar
On Thu, Dec 14, 2023 at 01:29:01PM +0100, Thomas Schwinge wrote:
> > Sure, I will look into that.
> >
> > BTW, I didn’t have the PowerPC in hands, do you mind granting the access of
> > your
> > test environment to me to help reproduce the issue?
>
> That's unfortunately not possible: it's behind
16 multiplication only works on the
former.
Tested on x86_64-linux -m32/-m64, committed to trunk.
2023-12-14 Jakub Jelinek
* c-c++-common/gomp/target-enter-data-1.c: Match also sizeof bar on
32-bit targets - 8 bytes - rather than just 16 bytes.
--- gcc/testsuite/c-c++-common/g
On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit
On Sat, Dec 09, 2023 at 12:19:10PM +0100, Thomas Schwinge wrote:
> > --- a/gcc/omp-builtins.def
> > +++ b/gcc/omp-builtins.def
> > @@ -467,6 +467,9 @@ DEF_GOMP_BUILTIN
> > (BUILT_IN_GOMP_WORKSHARE_TASK_REDUCTION_UNREGISTER,
> > DEF_GOMP_BUILTIN (BUILT_IN_GOMP_ALLOC,
> > "GOMP_allo
On Tue, Nov 28, 2023 at 12:28:05PM +0100, Tobias Burnus wrote:
> I stumbled over this omission when looking at Sandra's patch. It turned out
> that this is
> a new OpenMP 5.2 feature - probably added to simplify/unify the syntax. I
> guess the reason
> that release/acquire wasn't added before is
On Mon, Nov 20, 2023 at 11:42:02AM +0100, Tobias Burnus wrote:
> 2023-11-19 Tobias Burnus
> Chung-Lin Tang
>
> gcc/ChangeLog:
>
> * builtin-types.def (BT_FN_VOID_PTRMODE):
> (BT_FN_PTRMODE_PTRMODE_INT_PTR): Add.
> * gimplify.cc (gimplify_bind_expr): Diagnose missin
On Wed, Nov 08, 2023 at 05:58:10PM +0100, Tobias Burnus wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -11739,6 +11739,7 @@ builtin_fnspec (tree callee)
> return ".cO ";
>/* Realloc serves both as allocation point and deallocation point. */
>case BUILT_IN_REALLOC
On Fri, Aug 18, 2023 at 11:18:19AM +0800, Zhu, Lipeng wrote:
> From: Lipeng Zhu
>
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to s
On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote:
> On 05/12/2023 10:51, Jakub Jelinek wrote:
> > On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
> > > > The following patch makes libgfortran build on i686-linux after hacking
> > &g
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
> > The following patch makes libgfortran build on i686-linux after hacking up
> > --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
> > +++ kinds.h 2023-12-05 11:19:24.409679808 +0100
> > @@ -10,8 +10,8 @@ typedef GFC_INTEGER_
FC_LOGICAL_2
#define HAVE_GFC_INTEGER_2
-typedef int32_t GFC_INTEGER_4;
-typedef uint32_t GFC_UINTEGER_4;
+typedef long GFC_INTEGER_4;
+typedef unsigned long GFC_UINTEGER_4;
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4
in the build dir to em
On Mon, Nov 27, 2023 at 11:20:20AM +0100, Christophe Lyon wrote:
> On Fri, 24 Nov 2023 at 15:08, Jakub Jelinek wrote:
> > > Comments or remarks before I commit it?
> >
> > LGTM, thanks for working on it.
> >
> > Jakub
> >
>
> I thin
On Fri, Nov 24, 2023 at 02:51:28PM +0100, Tobias Burnus wrote:
> Following the general trend to add a "[-W...]" to the warning messages
> for both better grouping of the warnings and - more importantly - for
> providing
> a means to silence such a warning (or to -Werror= them explicitly), this pat
On Thu, Nov 23, 2023 at 04:59:16PM +0100, Tobias Burnus wrote:
> > There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
> > The question is if we want to consider say
> > #pragma depobj (a[++i]) destroy (a[++i])
> > as same or different (similarly a[foo ()] in both cases).
>
>
On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:
> @@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
> clause = error_mark_node;
> }
>else if (!strcmp ("destroy", p))
> - kind = OMP_CLAUSE_DEPEND_LAST;
> + {
> + matching_parens c_par
On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:
> I stumbled over this trivial omission which blocks some testcases.
>
> I am not sure whether I have solved the is-same-expr most elegantly,
> but I did loosely follow the duplicated-entry check for 'map'. As that's
> a restriction to
On Wed, Oct 18, 2023 at 12:56:01PM +0200, Tobias Burnus wrote:
> On 18.10.23 11:36, Jakub Jelinek wrote:
> > On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote:
> > > +FAIL: gfortran.dg/gomp/allocate-13.f90 -O (internal compiler
> > > error: tree c
On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote:
> Hi Tobias!
>
> On 2023-10-13T15:29:52+0200, Tobias Burnus wrote:
> > => Updated patch attached
>
> When cherry-picking this commit 2d3dbf0eff668bed5f5f168b3cafd8590c54
> "Fortran: Support OpenMP's 'allocate' directive for sta
On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
> * parse.cc (check_omp_allocate_stmt): Permit procedure pointers
> here (rejected later) for less mislreading diagnostic.
s/misl/mis/
> libgomp/ChangeLog:
>
> * libgomp.texi:
Fill in something here.
> @@ -7220,8
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
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 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 doe
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
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
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 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
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, 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
1 - 100 of 374 matches
Mail list logo
