Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
Hi Tobias, Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'declare variant' was not. It is easily missed in single-file testcases (esp. after the commitr15-7595-g8268c8256) as the whole-file handling mostly hides it. Just one question - as this will change the module file, will we still be compatible with reading gfortran 8 to gfortran 14-written module files? Or, in other words, will PR118337 not rear its ugly head again? Best regards Thomas
[Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since
r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was
already handled in the .mod file, 'declare variant' was not. It is
easily missed in single-file testcases (esp. after the
commitr15-7595-g8268c8256) as the
whole-file handling mostly hides it.
It is also not directly visible in real-world code as the base
function usually works, albeit not as good as the variant
(hence, there is variant).I hope that I have covered everything that is needed, but I am sure that
there are bugs lurking. Hence, I wouldn't mind if someone would glance
at it - or even proof read it. Tested on x86-64-gnu-linux. Comments,
remarks, suggestions before I eventually commit it relatively soonish?
Tobias PS: I think we should also eventually add some more testcases
like for the device or target_device selectors sets; I also have not
used the 'condition' selector or ...
Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
Write the 'omp declare variant' data into the .mod file: Base function,
variant function(s), supporting the clauses match, append_args, and
adjust_args.
gcc/fortran/ChangeLog:
* module.cc (mio_omp_declare_simd_clauses): New, moved from ...
(mio_omp_declare_simd): ... here. Update call, write empty '( )'
if there is no declare simd but a declare variant.
(mio_omp_declare_variant): New.
(mio_symbol): Call it.
* openmp.cc (gfc_match_omp_context_selector): Add comment about
module.cc to TODO note.
* trans-stmt.h (gfc_trans_omp_declare_variant): Take additional
parent_ns argument.
* trans-decl.cc (create_function_arglist,
gfc_create_function_decl): Update call.
* trans-openmp.cc (gfc_trans_omp_declare_variant): Take new
argument, add some special case handling for attr.use_assoc.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-variant-mod-1-use.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-1.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-2-use.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-2.f90: New test.
gcc/fortran/module.cc | 405 ++---
gcc/fortran/openmp.cc | 3 +-
gcc/fortran/trans-decl.cc | 4 +-
gcc/fortran/trans-openmp.cc| 17 +-
gcc/fortran/trans-stmt.h | 2 +-
.../gfortran.dg/gomp/declare-variant-mod-1-use.f90 | 81 +
.../gfortran.dg/gomp/declare-variant-mod-1.f90 | 83 +
.../gfortran.dg/gomp/declare-variant-mod-2-use.f90 | 47 +++
.../gfortran.dg/gomp/declare-variant-mod-2.f90 | 74
9 files changed, 650 insertions(+), 66 deletions(-)
diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index 490eaa97a49..070b3164ea3 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -4381,75 +4381,58 @@ static const mstring omp_declare_simd_clauses[] =
minit (NULL, -1)
};
-/* Handle !$omp declare simd. */
+/* Handle OpenMP's declare-simd clauses. */
static void
-mio_omp_declare_simd (gfc_namespace *ns, gfc_omp_declare_simd **odsp)
+mio_omp_declare_simd_clauses (gfc_omp_clauses **clausesp)
{
if (iomode == IO_OUTPUT)
{
- if (*odsp == NULL)
- return;
-}
- else if (peek_atom () != ATOM_LPAREN)
-return;
-
- gfc_omp_declare_simd *ods = *odsp;
+ gfc_omp_clauses *clauses = *clausesp;
+ gfc_omp_namelist *n;
- mio_lparen ();
- if (iomode == IO_OUTPUT)
-{
write_atom (ATOM_NAME, "OMP_DECLARE_SIMD");
- if (ods->clauses)
+ if (clauses->inbranch)
+ mio_name (0, omp_declare_simd_clauses);
+ if (clauses->notinbranch)
+ mio_name (1, omp_declare_simd_clauses);
+ if (clauses->simdlen_expr)
{
- gfc_omp_namelist *n;
-
- if (ods->clauses->inbranch)
- mio_name (0, omp_declare_simd_clauses);
- if (ods->clauses->notinbranch)
- mio_name (1, omp_declare_simd_clauses);
- if (ods->clauses->simdlen_expr)
- {
- mio_name (2, omp_declare_simd_clauses);
- mio_expr (&ods->clauses->simdlen_expr);
- }
- for (n = ods->clauses->lists[OMP_LIST_UNIFORM]; n; n = n->next)
- {
- mio_name (3, omp_declare_simd_clauses);
- mio_symbol_ref (&n->sym);
- }
- for (n = ods->clauses->lists[OMP_LIST_LINEAR]; n; n = n->next)
- {
- if (n->u.linear.op == OMP_LINEAR_DEFAULT)
- mio_name (4, omp_declare_simd_clauses);
- else
- mio_name (32 + n->u.linear.op, omp_declare_simd_clauses);
- mio_symbol_ref (&n->sym);
- mio_expr (&n->expr);
- }
- for (n = ods->clauses->lists[OMP_LIST_ALIGNED]; n; n = n->next)
- {
- mio_name (5, omp_declare_simd_clauses);
- mio_symbol_ref (&n->sym);
- mio_expr (&n->expr);
- }
+ mio_name (2, omp_declare_simd_clauses);
+ mio_expr (&clauses->simdlen_expr);
+ }
+ for (n = clauses->lists[OMP_LIST_UNIFORM]; n; n = n
Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping
Hi Harald and Jerry, thanks for taking the time to read my false assumptions ;-) The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer remapping is wrong. (F2018 §10.2.2.3 paragraph 9). The rhs is neither simply contiguous nor of rank one and therefore rejected. I spent some time to compose a better example, but failed. Given this, I assume that with the ok'ed patch the issue is sufficiently fixed. I therefore commit it. Should there be some corner case I/we did not find, then I am sure we get a bug report about it. While examining the code I figured that the test I've added, checked the input and not the output as it was intended to do. I fixed this and committed as gcc-15-7925-gf2339cefd69. Attached is the fixed patch just for reference. Thanks for the review and discussion, Andre On Thu, 6 Mar 2025 22:29:11 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 06.03.25 um 09:15 schrieb Andre Vehreschild: > > Hi Harald, > > > > I try to explain why I think my patch although solving the issue for this > > case, does not do so in every case: > > > > My patch lets dependency analysis figure that the two objects can not have > > any dependencies on each other or memory they are pointing to when the > > types are different. Lets assume a simple list with a head node: > > > > type node > >type(node), pointer :: prev, next > > end type > > > > type head > >type(node), pointer :: first, last > > end type > > > > (Just as an example; this might not be correct Fortran). Setting up a node > > > >type(head) :: h > >type(node), allocatable, target :: n > > > >allocate(n) > >n%prev = n%next = NULL() > >h%first => n > >h%last => n > > > > The patched dependency analysis will deem `h%first => n` operands to be > > independent of each other based on both having different types. Note, > > dependency analysis looks at the object's type first, i.e. `head` vs. `node` > > where I patched it! > > > > While the patch may be correct for the example, it may not be for every > > case. Just look one ref further: `h%first`'s type is `node` this would be > > deemed having (potentially) a dependency on the type of the target `n`, > > because both are of type `node`. Just having the same type is enough here! > > > > So much just for the consequences of my change. Now let me try to explain, > > why I think the patch is insufficient: > > > > Assume a type (again pseudo-Fortran): > > > > type T > >type(T), pointer :: n(:,:) > > end type > > > > Now doing something like > > > > type(T) :: v1, v2 > > > > v1%n(n:m, m:n) => v2%n(m:n, n:m) > > > > The types on lhs and rhs need to be the same. Then even the patched > > dependency analysis concludes that in a `forall` a temporary is needed, > > because the pointer assignment may overlap (trans-stmt.cc:5411): > > > > need_temp = gfc_check_dependency (c->expr1, c->expr2, 0); > > > > The indexes don't really matter here. They just need to be complicated, > > i.e.not just a AR_FULL or AR_ELEMENT. Now > > `gfc_trans_pointer_assign_need_temp()` is chosen. That routine in line > > trans-stmt.cc:5072 converts the lhs into a descriptor. But because of the > > non-full/complicated array addressing (note, the non-contiguous indexes !) > > `gfc_conv_expr_descriptor()` creates a `parm.12` (in my case) temporary > > descriptor. That temporary descriptor, hence the name, is usually used as > > actual argument to call a function. But the next line in > > `gfc_trans_pointer_assign_need_temp` just assigns the rhs` temporary to > > that `parm.12` (I have omitted only some casts, but in the code generated > > there are *no* member-references): > > > > parm.12 = lhs-temp > > > > This leads to the gimplification error, because the types of the rhs > > temporary and the temporary `parm.12` are not compatible. Furthermore is > > the assignment as it is done there non-sense in my eyes, because it is > > literally `parm.12 = rhs-temp`. I.e. in the code generated just before > > that, `parm.12` is constructed an initialized laboriously and then shall be > > overwritten completely. I assume that we would rather need something like > > (pseudo-pseudo code): > > > > for (n = 1: #elem(rhs-temp)) > >parm.12.data[i] = rhs-temp.data[i] > > end for > > > > But I have no clue how to easily accomplish that. I tried putting the > > rhs-temp into the se of the `gfc_conv_expr_descriptor()` and setting > > `se.direct_byref = 1`, but that does it the wrong way around, i.e. rhs = > > lhs (Side note: having a routine doing an assignment, that is otherwise > > just delivering a descriptor, is some odd design decision). So I am at a > > loss here. > > > > I hope to not have confused everyone. The possibility that I am mislead or > > overlooking something or even thinking to complicated here is very likely. > > So please correct me! > > > > Therefore let's discuss this a bit more. I hold the patch back until we > > come to a conclusion, that it is worth merging w/o breaki
[PATCH] Fortran: fix bogus dependency check in ALLOCATE statement [PR60560]
Dear all,
the attached patch fixes a bogus error due to a cyclic dependency that
is found because gfc_traverse_expr also descends into the length type
of character variables. If the length is determined by the variable
declaration (e.g. assumed-length), it is pre-determined and cannot
be relevant for the dependency check.
(Other brands (e.g. NAG, Intel) all behave as expected.)
The solution is to use the auxiliary parameter of gfc_traverse_expr
to control whether to descend into character length or not.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4fa9af7adb7a828daf39d822bb8c1244b31c3c1c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 15 Mar 2025 15:11:22 +0100
Subject: [PATCH] Fortran: fix bogus dependency check in ALLOCATE statement
[PR60560]
Restrict dependency check of ALLOCATE object to variables in the same
statement, but exclude check of length type parameter that might be
set in the declaration and could lead to a bogus cyclic dependency.
PR fortran/60560
gcc/fortran/ChangeLog:
* expr.cc (gfc_traverse_expr): Do not descend into length type
parameter for negative values of auxiliary parameter f.
* resolve.cc (gfc_find_var_in_expr): New helper function to check
dependence of an expression on given variable.
(resolve_allocate_expr): Use it to determine if array bounds in an
ALLOCATE statement depend explicitly on a variable.
gcc/testsuite/ChangeLog:
* gfortran.dg/allocate_error_8.f90: New test.
---
gcc/fortran/expr.cc | 28 +++
gcc/fortran/resolve.cc| 12 ++--
.../gfortran.dg/allocate_error_8.f90 | 17 +++
3 files changed, 43 insertions(+), 14 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/allocate_error_8.f90
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 9d84e761576..0753667e061 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -5488,11 +5488,14 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym,
if ((*func) (expr, sym, &f))
return true;
- if (expr->ts.type == BT_CHARACTER
- && expr->ts.u.cl
- && expr->ts.u.cl->length
- && expr->ts.u.cl->length->expr_type != EXPR_CONSTANT
- && gfc_traverse_expr (expr->ts.u.cl->length, sym, func, f))
+ /* Descend into length type parameter of character expressions only for
+ non-negative f. */
+ if (f >= 0
+ && expr->ts.type == BT_CHARACTER
+ && expr->ts.u.cl
+ && expr->ts.u.cl->length
+ && expr->ts.u.cl->length->expr_type != EXPR_CONSTANT
+ && gfc_traverse_expr (expr->ts.u.cl->length, sym, func, f))
return true;
switch (expr->expr_type)
@@ -5572,13 +5575,14 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym,
break;
case REF_COMPONENT:
- if (ref->u.c.component->ts.type == BT_CHARACTER
- && ref->u.c.component->ts.u.cl
- && ref->u.c.component->ts.u.cl->length
- && ref->u.c.component->ts.u.cl->length->expr_type
- != EXPR_CONSTANT
- && gfc_traverse_expr (ref->u.c.component->ts.u.cl->length,
- sym, func, f))
+ if (f >= 0
+ && ref->u.c.component->ts.type == BT_CHARACTER
+ && ref->u.c.component->ts.u.cl
+ && ref->u.c.component->ts.u.cl->length
+ && ref->u.c.component->ts.u.cl->length->expr_type
+ != EXPR_CONSTANT
+ && gfc_traverse_expr (ref->u.c.component->ts.u.cl->length,
+sym, func, f))
return true;
if (ref->u.c.component->as)
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 34c8210f66a..d64edff8507 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -8629,6 +8629,14 @@ gfc_find_sym_in_expr (gfc_symbol *sym, gfc_expr *e)
return gfc_traverse_expr (e, sym, sym_in_expr, 0);
}
+/* Same as gfc_find_sym_in_expr, but do not descend into length type parameter
+ of character expressions. */
+static bool
+gfc_find_var_in_expr (gfc_symbol *sym, gfc_expr *e)
+{
+ return gfc_traverse_expr (e, sym, sym_in_expr, -1);
+}
+
/* Given the expression node e for an allocatable/pointer of derived type to be
allocated, get the expression node to be initialized afterwards (needed for
@@ -9190,9 +9198,9 @@ check_symbols:
continue;
if ((ar->start[i] != NULL
- && gfc_find_sym_in_expr (sym, ar->start[i]))
+ && gfc_find_var_in_expr (sym, ar->start[i]))
|| (ar->end[i] != NULL
- && gfc_find_sym_in_expr (sym, ar->end[i])))
+ && gfc_find_var_in_expr (sym, ar->end[i])))
{
gfc_error ("%qs must not appear in the array specification at "
"%L in the same ALLOCATE statement where it is "
diff --git a/gcc/testsuite/gfortran.dg/allocate_error_8.f90 b/gcc/testsuite/gfortran.dg/allocate_error_8.f90
new file mode 100644
index 000..5637f9fae4d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_error_8.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/60560
+!
+! Original test case by Marco Restelli.
+
+module mstr
+ implicit none
+contains
+ subroutine sub(s)
+
Fwd: GCC GSoC 2025: Call for project ideas and mentors
Chenlu, You appear to be quite knowledgeable. It would be great to have you do this. I am forwarding additional information. Our most knowledgeable person in the DO_CONCURRENT area is probably Tobias (copied on this email). I certainly cannot speak for Tobias. I do think the gfortran team could mentor you as a whole. Perhaps Martin, copied here will have more information on the process. Martin, parallelization of DO_CONCURRENT would be a most excellent project. Regards, Jerry Forwarded Message Subject: GCC GSoC 2025: Call for project ideas and mentors Date: Wed, 29 Jan 2025 17:20:57 +0100 From: Martin Jambor To: GCC Mailing List , Gfortran mailing list , libstd...@gcc.gnu.org, gcc-r...@gcc.gnu.org CC: David Edelsohn , Thomas Schwinge Hello, another year has passed, Google has announced there will be again Google Summer of Code (GsoC) in 2025 and the deadline for organizations to apply is already approaching (February 11th). I'd like to volunteer to be the main org-admin for GCC again but let me know if you think I shouldn't or that someone else should or if you want to do it instead. Otherwise I'll assume that I will and I hope that I can continue to rely on David Edelsohn and Thomas Schwinge to back me up and help me with some decision making along the way as my co-org-admins. The most important bit: I would like to ask all (moderately) seasoned GCC contributors to consider mentoring a contributor this year and ideally also come up with a project that they would like to lead. We are collecting proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the top list there. Or, if you are unsure, post your offer and project idea as a reply here to the mailing list. Additionally, if you have added an idea to the list in the recent years, please review it whether it is still up-to-date or needs adjusting or should be removed altogether. = At this point, we need to collect list of project ideas. Eventually, each listed project idea should have: a) a project title, b) more detailed description of the project (2-5 sentences), c) expected outcomes (we do have a catch-almost-all formulation that outcome is generally patches at the bottom of the list on the wiki), d) skills required/preferred, e) project size - whether it is expected to take approximately 350, 175 or just 90 hours (see below about the last option), f) difficulty (easy, hard or medium, but we don't really have easy projects), and g) expected mentors. Project ideas that come without an offer to also mentor them are always fun to discuss, by all means feel free to reply to this email with yours and I will attempt to find a mentor, but please be aware that we can only use the suggestion it if we actually find one or ideally two. Everybody in the GCC community is invited to go over https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or otherwise bad project suggestions and help improve viable ones. Finally, please continue helping (prospective) students figure stuff out about GCC like you have always done in the past. As far as I know, GSoC 2025 should be quite similar to the last year, the most important parameters probably are these: - Contributors (formerly students) must either be full-time students or be "beginners to open source." - There are now three project sizes: roughly 90 hors (small), roughly 175 hours (medium-sized) and roughly 350 hours (large) of work in total. The small option was introduced in 2024 but because our projects usually have a lengthy learning period, I think we will usually want to stick to the medium and large variants. - Timing should be pretty much as flexible as last year. The recommended "standard" duration is 12 weeks but depending on contributor's and mentor's needs and circumstances, projects can take anywhere between 10 and 22 weeks. There will be one mid-term and one final evaluation. For further details you can see: - The announcement of GSoC 2025: https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html - GSoC rules: https://summerofcode.withgoogle.com/rules - The detailed GSoC 2025 timeline: https://developers.google.com/open-source/gsoc/timeline - Elaborate project idea guidelines: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list Thank you very much for your participation and help. Let's hope we attract some great contributors again this year. Martin
Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
Hi Thomas,
Thomas Koenig wrote:
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021).
(and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp
declare simd' was already handled in the .mod file, 'declare variant'
was not. It is easily missed in single-file testcases (esp. after the
commitr15-7595-g8268c8256) as the
whole-file handling mostly hides it.
Just one question - as this will change the module file, will we
still be compatible with reading gfortran 8 to gfortran 14-written
module files?
It shouldn't. On writing there is:
* mio_omp_declare_simd [old function, additional condition]: if (*odsp
== NULL) { if (ns->omp_declare_variant) { mio_lparen (); mio_rparen ();
} return; 4439,4-11 55% Thus, on writing, it only writes '(' if there is
a 'declare simd' (with its context, unchanged) - or (new) an empty '( )'
if there is a 'declare variant'. * mio_omp_declare_variant itself has
code: if (iomode == IO_OUTPUT) { if (*odvp == NULL) return;
Thus, if there is no 'declare variant', the output for 'declare simd'
should the same as before - and the code is simple enough that I would
even claim 'is' (unless the memory is corrupted). And as the output
remains the same in that case, there should be also no problem reading
both old .mod files with new compiler - and even the reverse, i.e.
reading .mod files, written by after this patch, with an old GCC
version. [The latter will fail due to the recent version bump, but
that's unrelated to this patch.] The only potentially failing cases are:
* Code that contains 'declare variant' that is written by a new
compiler, but read by an old compiler (missing downward compatibility).
- But due to the version bump in GCC 15 (r15-6704-g21ee71afa72746;Jan
25, 2025), this only affects GCC 15 version between January and March -
and only when the module contained 'declare variant'. [The mode-reading
error is that the code stumbles over the '(' [ followed by some items
and ')'] - while expecting the outer ')'.] * Some bug in the added code.
This is very unlikely to hit code without 'declare variant', but there
is some chance that I missed some corner case with 'declare variant'
present - which might either cause missing data, wrong data (that might
cause later fails [ICE, bogus diagnostic, wrong code]) or even a .mod
reading issue. - While I ran into all those issues (with declare variant
present) - fund in course of writing the test cases, I hope that I found
most if not all such bugs. Thus, we should be all fine. I guess, we
eventually will have some additions to the context selectors in the
'match' clauses, which will break downward (but not upward)
compatibility. At least the TODO in openmp.cc implies that some work is
needed and there is some chance that the current code will not handle
it. (That's tracked as https://gcc.gnu.org/PR113067 ) Cheers, Tobias
Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
I wonder why sometimes my line breaks are preserved and at other times all
eaten.
Next try ...
Tobias Burnus wrote:
Hi Thomas,
Thomas Koenig wrote:
Just one question - as this will change the module file, will we still
be compatible with reading gfortran 8 to gfortran 14-written module
files?
It shouldn't. On writing there is:
* mio_omp_declare_simd [old function, additional condition]:
if (*odsp == NULL)
{
if (ns->omp_declare_variant)
{
mio_lparen ();
mio_rparen ();
}
return;
Thus, on writing, it only writes '(' if there is
a 'declare simd' (with its context, unchanged) - or (new) an empty '( )'
if there is a 'declare variant'.
* mio_omp_declare_variant itself has the code:
if (iomode == IO_OUTPUT)
{
if (*odvp == NULL) return;
Thus, if there is no 'declare variant', the output for 'declare simd'
should the same as before - and the code is simple enough that I would
even claim 'is' (unless the memory is corrupted).
And as the output remains the same in that case, there should be also
no problem reading both old .mod files with new compiler - and even
the reverse, i.e. reading .mod files, written by after this patch, with
an old GCC version. [The latter will fail due to the recent version bump, but
that's unrelated to this patch.]
The only potentially failing cases are:
* Code that contains 'declare variant' that is written by a new
compiler, but read by an old compiler (missing downward compatibility).
But due to the version bump in GCC 15 (r15-6704-g21ee71afa72746;Jan
25, 2025), this only affects GCC 15 version between January and March -
and only when the module contained 'declare variant'. [The mode-reading
error is that the code stumbles over the '(' [ followed by some items
and ')'] - while expecting the outer ')'.]
* Some bug in the added code.
This is very unlikely to hit code without 'declare variant', but there
is some chance that I missed some corner case with 'declare variant'
present - which might either cause missing data, wrong data (that might
cause later fails [ICE, bogus diagnostic, wrong code]) or even a .mod
reading issue. - While I ran into all those issues (with declare variant
present) - fund in course of writing the test cases, I hope that I found
most if not all such bugs.
Thus, we should be all fine. I guess, we
eventually will have some additions to the context selectors in the
'match' clauses, which will break downward (but not upward)
compatibility. At least the TODO in openmp.cc implies that some work is
needed and there is some chance that the current code will not handle
it. (That's tracked as https://gcc.gnu.org/PR113067 )
Cheers,
Tobias
[patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch
Hello world,
the attached patch, tested with "tidy -e", puts the two parts
mentioning UNSSIGNED into a single paragraph, mentions
extensions to -fc-prototypes and mentions -Wexternal-interface-mismatch.
Comments, suggestions for better wording?
If not, I'll probably commit tomorrow.
Best regards
Thomas
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 7e5da369..1dcef49b 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -182,6 +182,7 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
either add
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-std-1";>-std=
to your build flags, or port your code; see the porting notes.
+
Some more C23 features have been implemented:
#embed preprocessing directive support.
@@ -427,15 +428,18 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
Fortran
- Fortran 2023: The selected_logical_kind intrinsic function
- and, in the ISO_FORTRAN_ENV module, the named constants
- logical{8,16,32,64} and real16 were added.
- Experimental support for unsigned integers, enabled by
- -funsigned; see https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html";
- >gfortran documentation for details. These have been proposed
- (https://j3-fortran.org/doc/year/24/24-116.txt";>J3/24-116)
- for inclusion in the next Fortran standard.
+
+Experimental support for unsigned integers, enabled by
+-funsigned;
+see https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html";>
+gfortran documentation for details. This follows
+(https://j3-fortran.org/doc/year/24/24-116.txt";>J3/24-116).
+With this option in force, the selected_logical_kind
+intrinsic function and, in the ISO_FORTRAN_ENV
+module, the named constants logical{8,16,32,64} and
+real16 were added. The ISO_C_BINDING
+module has been extended accordingly.
+
Missing commas separating descriptors in input/output format strings are no
longer permitted by default and are rejected at run-time unless -std=legacy
is used when compiling the main program unit. See Fortran 2023 constraint C1302.
@@ -453,6 +457,18 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
it is recommended to recompile all artifacts. The OpenCoarrays library
is not affected, because it provides backwards compatibility with the
older ABI.
+
+The -Wexternal-interface-mismatch option has been
+added. This checks for mismatches between the argument lists in
+dummy external arguments, and is implied by -Wall
+and -fc-prototypes-external options.
+
+
+The -fc-prototypes now also generates prototypes for
+interoperable procedures with assumed shape and assumed rank
+arguments that require the header file
+.
+
Re: [PATCH] Fortran: fix bogus dependency check in ALLOCATE statement [PR60560]
Hi Harald, The solution is to use the auxiliary parameter of gfc_traverse_expr to control whether to descend into character length or not. Regtested on x86_64-pc-linux-gnu. OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas
