Re: Adding a new thread model to GCC
在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道: No, sorry for my brevity. Using __gthread_t like in your patch is correct. I see. In 'libgfortran/io/async.c' there is ``` async_unit *au = u->au; LOCK (&au->lock); thread_unit = u; au->thread = __gthread_self (); ``` so indeed `thread` should be `__gthread_t`. By the way I reported this issue four months ago and haven't received any response so far: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764 -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
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:
>
> * dump-parse-tree.cc (show_omp_assumes): New.
> (show_omp_clauses, show_namespace): Call it.
> (show_omp_node, show_code_node): Handle OpenMP ASSUME.
> * gfortran.h (enum gfc_statement): Add ST_OMP_ASSUME,
> ST_OMP_END_ASSUME and ST_OMP_ASSUMES.
> (gfc_exec_op): Add EXEC_OMP_ASSUME.
> (gfc_omp_assumptions): New struct.
> (gfc_get_omp_assumptions): New XCNEW #define.
> (gfc_omp_clauses, gfc_namespace): Add assume member.
> (gfc_resolve_omp_assumptions): New prototype.
> * match.h (gfc_match_omp_assume, gfc_match_omp_assumes): New.
> * openmp.cc (omp_code_to_statement): Declare.
> (gfc_free_omp_clauses): Free assume member and its struct data.
> (enum omp_mask2): Add OMP_CLAUSE_ASSUMPTIONS.
> (gfc_omp_absent_contains_clause): New.
> (gfc_match_omp_clauses): Call it; optionally use passed
> omp_clauses argument.
> (gfc_match_omp_assume, gfc_match_omp_assumes): New.
> (gfc_resolve_omp_assumptions): New.
> (resolve_omp_clauses): Call it.
> (gfc_resolve_omp_directive, omp_code_to_statement): Handle
> EXEC_OMP_ASSUME.
> * parse.cc (decode_omp_directive): Parse OpenMP ASSUME(S).
> (next_statement, parse_executable, parse_omp_structured_block):
> Handle ST_OMP_ASSUME.
> (case_omp_decl): Add ST_OMP_ASSUMES.
> (gfc_ascii_statement): Handle Assumes, optional return
> string without '!$OMP '/'!$ACC ' prefix.
> (is_omp_declarative_stmt, is_omp_informational_stmt): New.
> * parse.h (gfc_ascii_statement): Add optional bool arg to prototype.
> (is_omp_declarative_stmt, is_omp_informational_stmt): New prototype.
> * resolve.cc (gfc_resolve_blocks, gfc_resolve_code): Add
> EXEC_OMP_ASSUME.
> (gfc_resolve): Resolve ASSUMES directive.
> * symbol.cc (gfc_free_namespace): Free omp_assumes member.
> * st.cc (gfc_free_statement): Handle EXEC_OMP_ASSUME.
> * trans-openmp.cc (gfc_trans_omp_directive): Likewise.
> * trans.cc (trans_code): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/gomp/assume-1.f90: New test.
> * gfortran.dg/gomp/assume-2.f90: New test.
> * gfortran.dg/gomp/assumes-1.f90: New test.
> * gfortran.dg/gomp/assumes-2.f90: New test.
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2749,9 +2749,9 @@ have support for @option{-pthread}. @option{-fopenmp}
> implies
> @opindex fopenmp-simd
> @cindex OpenMP SIMD
> @cindex SIMD
> -Enable handling of OpenMP's SIMD directives with @code{#pragma omp}
> -in C/C++ and @code{!$omp} in Fortran. Other OpenMP directives
> -are ignored.
> +Enable handling of OpenMP's SIMD directives and OPENMP's @code{assume}
> directive
s/OPENMP/OpenMP/
We actually handle more directives, @code{declare reduction},
@code{ordered}, @code{scan}, @code{loop} and combined/composite directives
with @code{simd} as constituent.
> +with @code{#pragma omp} in C/C++ and @code{!$omp} in Fortran. Other OpenMP
> +directives are ignored.
And now in C++ we handle also the attribute syntax (guess we should update
the text for that here as well as in -fopenmp entry).
> @@ -3531,6 +3565,14 @@ show_namespace (gfc_namespace *ns)
> }
> }
>
> + if (ns->omp_assumes)
> +{
> + show_indent ();
> + fprintf (dumpfile, "!$OMP ASSUMES");
> + show_omp_assumes (ns->omp_assumes);
> +}
> +
> +
Just one empty line?
>fputc ('\n', dumpfile);
>show_indent ();
>fputs ("code:", dumpfile);
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 4babd77924b..29a443dcd44 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -316,7 +316,7 @@ enum gfc_statement
>ST_OMP_END_PARALLEL_MASKED_TASKLOOP_SIMD, ST_OMP_MASKED_TASKLOOP,
>ST_OMP_END_MASKED_TASKLOOP, ST_OMP_MASKED_TASKLOOP_SIMD,
>ST_OMP_END_MASKED_TASKLOOP_SIMD, ST_OMP_SCOPE, ST_OMP_END_SCOPE,
> - ST_OMP_ERROR, ST_NONE
> + ST_OMP_ERROR, ST_OMP_ASSUME, ST_OMP_END_ASSUME, ST_OMP_ASSUMES, ST_NONE
> };
>
> /* Types of interfaces that we can have. Assignment interfaces are
> @@ -1506,6 +1506,19 @@ enum gfc_omp_bind_type
>OMP_BIND_THREAD
> };
>
> +typedef struct gfc_omp_assumptions
> +{
> + int n_absent, n_contains;
> + enum gfc_statement *absent, *contains;
> + gfc_expr_list *holds;
> + locus where;
> + bool no_openmp:1, no_openmp_routines:1, no_parallelism:1;
> +}
> +gfc_omp_assumptions;
> +
> +#define gfc_get_omp_assumptions() XCNEW (gfc_omp_assumptions)
> +
> +
> typedef struct gfc_omp_clauses
> {
>gfc_omp_namelist *lists[OMP_LIST_NUM];
> @@ -1529,6 +1542,7 @@ typedef struct gfc_omp_clauses
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
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{-pthread}. @option{-fopenmp}
implies
@opindex fopenmp-simd
@cindex OpenMP SIMD
@cindex SIMD
-Enable handling of OpenMP's SIMD directives with @code{#pragma omp}
-in C/C++ and @code{!$omp} in Fortran. Other OpenMP directives
-are ignored.
+Enable handling of OpenMP's SIMD directives and OPENMP's @code{assume}
directive
s/OPENMP/OpenMP/
We actually handle more directives, @code{declare reduction},
@code{ordered}, @code{scan}, @code{loop} and combined/composite directives
with @code{simd} as constituent.
...
And now in C++ we handle also the attribute syntax (guess we should update
the text for that here as well as in -fopenmp entry).
Updated suggestion attached – I still need to update the main patch.
(I also added 'declare simd' to the list. And I updated Fortran for scan +
loop.)
OK?
* * *
Wouldn't this be better table driven (like c_omp_directives
in c-family, though guess for Fortran you can just use spaces
in the name, don't need 3 strings for the separate tokens)?
Because I think absent/contains isn't the only spot where
you need directive names, metadirective is another.
Maybe – I think there are already way to many string repetitions. One problem
is that metadirectives permit combined/composite constructs while 'assume(s)'
does not. I on purpose did not parse them, but probably in light of
Metadirectives, I should.
I will take a look.
+ if (is_omp_declarative_stmt (st) || is_omp_informational_stmt (st))
+ {
+ gfc_error ("Invalid %qs directive at %L in %s clause: declarative, "
+"informational and meta directives not permitted",
+gfc_ascii_statement (st, true), &old_loc,
+is_absent ? "ABSENT" : "CONTAINS");
Do you think we should do the same for C/C++?
Right now it doesn't differentiate between invalid directive names and
names of declarative, informational or meta directives.
Maybe - it might help users to understand why something went wrong, on the
other hand, I do not really think that a user adds 'absent(declare variant)',
but I might be wrong.
+ = (gfc_statement *) xrealloc ((*assume)->absent,
+ sizeof (gfc_statement)
+ * (*assume)->n_absent);
XRESIZEVEC?
Aha, that's the macro name!
But also, resizing each time a single entry is added to the list isn't
good for compile time, would be nice to grow the allocation size in
powers of 2 or so.
I only expect a very small number – and did not want to keep track of yet
another number.
However, the following should work:
if (old_n_absent = 0)
absent = ... sizeof() * 1
else if (popcount (old_n_absent) == 1)
absent = ... sizeof() * (old_n_absent) * 2)
that allocates: 1, 2, 4, 8, 16, 32, ... without keeping track of the number.
+gfc_match_omp_assumes (void)
+{
+ locus loc = gfc_current_locus;
+ gfc_omp_clauses *c = gfc_get_omp_clauses ();
+ c->assume = gfc_current_ns->omp_assumes;
+ if (!gfc_current_ns->proc_name
+ || (gfc_current_ns->proc_name->attr.flavor != FL_MODULE
+ && !gfc_current_ns->proc_name->attr.subroutine
+ && !gfc_current_ns->proc_name->attr.function))
+{
+ gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
+"subprogram or module");
+ return MATCH_ERROR;
+}
+ if (gfc_match_omp_clauses (&c, omp_mask (OMP_CLAUSE_ASSUMPTIONS), true, true,
+false, false, false, false) != MATCH_YES)
+{
+ gfc_current_ns->omp_assumes = NULL;
+ return MATCH_ERROR;
+}
I don't understand the point of preallocation of gfc_omp_clauses here,
can't it be allocated inside of gfc_match_omp_clauses like everywhere else?
Because otherwise it e.g. leaks if the first error is reported.
This is supposed to handle:
subroutine foo()
!$omp assumes absent(target)
!$omp assumes absent(teams)
end
I did not spot anything which states that it is invalid.
(I might have missed it, however.) And if it is valid,
I assume it is equivalent to:
subroutine foo()
!$omp assumes absent(target, teams)
end
And the simplest way to do the merge seems to use gfc_match_omp_clauses,
which already handles merging 'absent(target) absent(teams)'.
Thus, I pre-populate the clause list with the assumption values from
the previous directive.
Additionally, there shouldn't be a leak as inside gfc_omp_match_clauses is:
gfc_free_omp_clauses (c);
return MATCH_ERROR;
which frees the memory. To avoid double freeing, a possibly pre-existing
'gfc_current_ns->omp_assumes' has to be set to NULL.
The other question is whether the spec is clear, e.g. is the following valid?
!$omp assumes no_openmp
!$omp assumes no_openmp
In each directive, no_ope
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
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{-pthread}. @option{-fopenmp}
> implies
> @opindex fopenmp-simd
> @cindex OpenMP SIMD
> @cindex SIMD
> -Enable handling of OpenMP's SIMD directives with @code{#pragma omp}
> -in C/C++ and @code{!$omp} in Fortran. Other OpenMP directives
> -are ignored.
> +Enable handling of OpenMP's SIMD directives and OPENMP's @code{assume}
> directive
>
>
> s/OPENMP/OpenMP/
>
> We actually handle more directives, @code{declare reduction},
> @code{ordered}, @code{scan}, @code{loop} and combined/composite directives
> with @code{simd} as constituent.
> ...
> And now in C++ we handle also the attribute syntax (guess we should update
> the text for that here as well as in -fopenmp entry).
>
> Updated suggestion attached – I still need to update the main patch.
>
> (I also added 'declare simd' to the list. And I updated Fortran for scan +
> loop.)
>
> OK?
Ok, thanks.
> Wouldn't this be better table driven (like c_omp_directives
> in c-family, though guess for Fortran you can just use spaces
> in the name, don't need 3 strings for the separate tokens)?
> Because I think absent/contains isn't the only spot where
> you need directive names, metadirective is another.
>
> Maybe – I think there are already way to many string repetitions. One problem
> is that metadirectives permit combined/composite constructs while 'assume(s)'
> does not. I on purpose did not parse them, but probably in light of
> Metadirectives, I should.
>
> I will take a look.
It is true that metadirective supports combined/composite constructs,
and so do we in the C++ attribute case, still we IMHO can use the C/C++
table as is.and it doesn't need to include combined/composite constructs.
The thing is that for the metadirective/C++ attribute case, all we need to
know is to discover the directive category (declarative, stand-alone,
construct, informational, ...) and for that it is enough to parse the
first directive-name in combined/composite constructs. Both metadirectives
and C++ attributes then have the name of the directive followed by clauses
so we effectively have to use the normal parsing of directives/clauses
there (except perhaps not end on end of directive but on unbalanced closing
paren). And then there is the absent/contains case, where we only
allow non-combined/composite, so there we need to try to match the directive
name from the table and make sure it is followed by , or ).
> But also, resizing each time a single entry is added to the list isn't
> good for compile time, would be nice to grow the allocation size in
> powers of 2 or so.
>
> I only expect a very small number – and did not want to keep track of yet
> another number.
>
> However, the following should work:
>
>
> if (old_n_absent = 0)
>absent = ... sizeof() * 1
> else if (popcount (old_n_absent) == 1)
>absent = ... sizeof() * (old_n_absent) * 2)
Yeah. Or for 0 allocate say 8 and
use (pow2p_hwi (old_n_absent) && old_n_absent >= 8)
in the else if.
> that allocates: 1, 2, 4, 8, 16, 32, ... without keeping track of the number.
>
>
>
> +gfc_match_omp_assumes (void)
> +{
> + locus loc = gfc_current_locus;
> + gfc_omp_clauses *c = gfc_get_omp_clauses ();
> + c->assume = gfc_current_ns->omp_assumes;
> + if (!gfc_current_ns->proc_name
> + || (gfc_current_ns->proc_name->attr.flavor != FL_MODULE
> + && !gfc_current_ns->proc_name->attr.subroutine
> + && !gfc_current_ns->proc_name->attr.function))
> +{
> + gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
> +"subprogram or module");
> + return MATCH_ERROR;
> +}
> + if (gfc_match_omp_clauses (&c, omp_mask (OMP_CLAUSE_ASSUMPTIONS), true,
> true,
> +false, false, false, false) != MATCH_YES)
> +{
> + gfc_current_ns->omp_assumes = NULL;
> + return MATCH_ERROR;
> +}
>
>
>
> I don't understand the point of preallocation of gfc_omp_clauses here,
> can't it be allocated inside of gfc_match_omp_clauses like everywhere else?
> Because otherwise it e.g. leaks if the first error is reported.
>
> This is supposed to handle:
> subroutine foo()
>!$omp assumes absent(target)
>!$omp assumes absent(teams)
> end
>
> I did not spot anything which states that it is invalid.
> (I might have missed it, however.) And if it is valid,
> I assume it is equivalent to:
>
> subroutine foo()
>!$omp assumes absent(target, teams)
> end
It is not equivalent to that, because while we have the restriction
that the same list item can't appear multiple times on the same directive,
it can appear multiple times on multiple directives.
So,
subroutine foo()
!$omp assumes absent(target, target)
end
o
[PATCH RESEND 0/1] RFC: P1689R5 support
This patch adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to ensure that `import some_module;` can be satisfied in time by making sure that the TU with `export import some_module;` is compiled first. [P1689R5]: https://isocpp.org/files/papers/P1689R5.html I'd like feedback on the approach taken here with respect to the user-visible flags. I'll also note that header units are not supported at this time because the current `-E` behavior with respect to `import ;` is to search for an appropriate `.gcm` file which is not something such a "scan" can support. A new mode will likely need to be created (e.g., replacing `-E` with `-fc++-module-scanning` or something) where headers are looked up "normally" and processed only as much as scanning requires. Testing is currently happening in CMake's CI using a prior revision of this patch (the differences are basically the changelog, some style, and `trtbd` instead of `p1689r5` as the format name). For testing within GCC, I'll work on the following: - scanning non-module source - scanning module-importing source (`import X;`) - scanning module-exporting source (`export module X;`) - scanning module implementation unit (`module X;`) - flag combinations? Are there existing tools for handling JSON output for testing purposes? Basically, something that I can add to the test suite that doesn't care about whitespace, but checks the structure (with sensible replacements for absolute paths where relevant)? For the record, Clang has patches with similar flags and behavior by Chuanqi Xu here: https://reviews.llvm.org/D134269 with the same flags (though using my old `trtbd` spelling for the format name). Thanks, --Ben Ben Boeckel (1): p1689r5: initial support gcc/ChangeLog | 9 ++ gcc/c-family/ChangeLog | 6 + gcc/c-family/c-opts.cc | 40 ++- gcc/c-family/c.opt | 12 ++ gcc/cp/ChangeLog| 5 + gcc/cp/module.cc| 3 +- gcc/doc/invoke.texi | 15 +++ gcc/fortran/ChangeLog | 5 + gcc/fortran/cpp.cc | 4 +- gcc/genmatch.cc | 2 +- gcc/input.cc| 4 +- libcpp/ChangeLog| 11 ++ libcpp/include/cpplib.h | 12 +- libcpp/include/mkdeps.h | 17 ++- libcpp/init.cc | 14 ++- libcpp/mkdeps.cc| 235 ++-- 16 files changed, 368 insertions(+), 26 deletions(-) base-commit: d812e8cb2a920fd75768e16ca8ded59ad93c172f -- 2.37.3
[PATCH RESEND 1/1] p1689r5: initial support
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the output. Currently named
`p1689r5`.
- `-fdeps-file=` specifies the path to the file to write the format to.
- `-fdep-output=` specifies the `.o` that will be written for the TU
that is scanned. This is required so that the build system can
correlate the dependency output with the actual compilation that will
occur.
CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0)
using an experimental feature selection (to allow for future usage
evolution without committing to how it works today). While it remains
experimental, docs may be found in CMake's documentation for
experimental features.
Future work may include using this format for Fortran module
dependencies as well, however this is still pending work.
[P1689R5]: https://isocpp.org/files/papers/P1689R5.html
[cmake-experimental]:
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst
TODO:
- header-unit information fields
Header units (including the standard library headers) are 100%
unsupported right now because the `-E` mechanism wants to import their
BMIs. A new mode (i.e., something more workable than existing `-E`
behavior) that mocks up header units as if they were imported purely
from their path and content would be required.
- non-utf8 paths
The current standard says that paths that are not unambiguously
represented using UTF-8 are not supported (because these cases are rare
and the extra complication is not worth it at this time). Future
versions of the format might have ways of encoding non-UTF-8 paths. For
now, this patch just doesn't support non-UTF-8 paths (ignoring the
"unambiguously represetable in UTF-8" case).
- figure out why junk gets placed at the end of the file
Sometimes it seems like the file gets a lot of `NUL` bytes appended to
it. It happens rarely and seems to be the result of some
`ftruncate`-style call which results in extra padding in the contents.
Noting it here as an observation at least.
Signed-off-by: Ben Boeckel
---
gcc/ChangeLog | 9 ++
gcc/c-family/ChangeLog | 6 +
gcc/c-family/c-opts.cc | 40 ++-
gcc/c-family/c.opt | 12 ++
gcc/cp/ChangeLog| 5 +
gcc/cp/module.cc| 3 +-
gcc/doc/invoke.texi | 15 +++
gcc/fortran/ChangeLog | 5 +
gcc/fortran/cpp.cc | 4 +-
gcc/genmatch.cc | 2 +-
gcc/input.cc| 4 +-
libcpp/ChangeLog| 11 ++
libcpp/include/cpplib.h | 12 +-
libcpp/include/mkdeps.h | 17 ++-
libcpp/init.cc | 14 ++-
libcpp/mkdeps.cc| 235 ++--
16 files changed, 368 insertions(+), 26 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6dded16c0e3..2d61de6adde 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2022-09-20 Ben Boeckel
+
+ * doc/invoke.texi: Document -fdeps-format=, -fdep-file=, and
+ -fdep-output= flags.
+ * genmatch.cc (main): Add new preprocessor parameter used for C++
+ module tracking.
+ * input.cc (test_lexer): Add new preprocessor parameter used for C++
+ module tracking.
+
2022-09-19 Torbjörn SVENSSON
* targhooks.cc (default_zero_call_used_regs): Improve sorry
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index ba3d76dd6cb..569dcd96e8c 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2022-09-20 Ben Boeckel
+
+ * c-opts.cc (c_common_handle_option): Add fdeps_file variable and
+ -fdeps-format=, -fdep-file=, and -fdep-output= parsing.
+ * c.opt: Add -fdeps-format=, -fdep-file=, and -fdep-output= flags.
+
2022-09-15 Richard Biener
* c-common.h (build_void_list_node): Remove.
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index babaa2fc157..617d0e93696 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -77,6 +77,9 @@ static bool verbose;
/* Dependency output file. */
static const char *deps_file;
+/* Enhanced dependency output file. */
+static const char *fdeps_file;
+
/* The prefix given by -iprefix, if any. */
static const char *iprefix;
@@ -360,6 +363,23 @@ c_common_handle_option (size_t scode, const char *arg,
HOST_WIDE_INT value,
deps_file = arg;
break;
+case OPT_fdep_format_:
+ if (!strcmp (arg, "p1689r5"))
+ cpp_opts->deps.format = DEPS_FMT_P1689R5;
+ else
+ error ("%<-fdep-format=%> unknown format %s", arg);
+ break;
+
+case OPT_fdep_file_:
+ deps_seen = true;
+ fdeps_file = arg;
+ break;
+
+case OPT_fdep_output_:
+ deps_seen = true;
+ defer_opt (code, arg);
+ break;
+
case OPT_MF:
deps_seen = true;
d
Re: [PATCH RESEND 1/1] p1689r5: initial support
Am 04.10.22 um 17:12 schrieb Ben Boeckel:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Is there a reason that you are touching so many frontends?
diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
index 364bd0d2a85..0b9df9c02cd 100644
--- a/gcc/fortran/cpp.cc
+++ b/gcc/fortran/cpp.cc
@@ -712,7 +712,7 @@ gfc_cpp_done (void)
FILE *f = fopen (gfc_cpp_option.deps_filename, "w");
if (f)
{
- cpp_finish (cpp_in, f);
+ cpp_finish (cpp_in, f, NULL);
fclose (f);
}
else
@@ -721,7 +721,7 @@ gfc_cpp_done (void)
xstrerror (errno));
}
else
- cpp_finish (cpp_in, stdout);
+ cpp_finish (cpp_in, stdout, NULL);
}
cpp_undef_all (cpp_in);
Couldn't you simply default the third argument of cpp_finish() to NULL?
diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index 2db1e9cbdfb..90787230a9e 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -298,6 +298,9 @@ typedef CPPCHAR_SIGNED_T cppchar_signed_t;
/* Style of header dependencies to generate. */
enum cpp_deps_style { DEPS_NONE = 0, DEPS_USER, DEPS_SYSTEM };
+/* Format of header dependencies to generate. */
+enum cpp_deps_format { DEPS_FMT_NONE = 0, DEPS_FMT_P1689R5 };
+
/* The possible normalization levels, from most restrictive to least. */
enum cpp_normalize_level {
/* In NFKC. */
@@ -581,6 +584,9 @@ struct cpp_options
/* Style of header dependencies to generate. */
enum cpp_deps_style style;
+/* Format of header dependencies to generate. */
+enum cpp_deps_format format;
+
/* Assume missing files are generated files. */
bool missing_files;
@@ -1104,9 +1110,9 @@ extern void cpp_post_options (cpp_reader *);
extern void cpp_init_iconv (cpp_reader *);
/* Call this to finish preprocessing. If you requested dependency
- generation, pass an open stream to write the information to,
- otherwise NULL. It is your responsibility to close the stream. */
-extern void cpp_finish (cpp_reader *, FILE *deps_stream);
+ generation, pass open stream(s) to write the information to,
+ otherwise NULL. It is your responsibility to close the stream(s). */
+extern void cpp_finish (cpp_reader *, FILE *deps_stream, FILE *fdeps_stream);
^^^
/* Call this to release the handle at the end of preprocessing. Any
use of the handle after this function returns is invalid. */
[PATCH] Fortran: reject procedures and procedure pointers as output item [PR107074]
Dear all,
when looking at output item lists we didn't catch procedures
and procedure pointers and ran into a gfc_internal_error().
Such items are not allowed by the Fortran standard, e.g. for
procedure pointers there is
C1233 (R1217) An expression that is an output-item shall not
have a value that is a procedure pointer.
Attached patch generates an error instead.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 3b15fe83830c1e75339114e0241e9d2158393017 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 21:19:21 +0200
Subject: [PATCH] Fortran: reject procedures and procedure pointers as output
item [PR107074]
gcc/fortran/ChangeLog:
PR fortran/107074
* trans-io.cc (transfer_expr): A procedure or a procedure pointer
cannot be output items.
gcc/testsuite/ChangeLog:
PR fortran/107074
* gfortran.dg/pr107074.f90: New test.
---
gcc/fortran/trans-io.cc| 14 ++
gcc/testsuite/gfortran.dg/pr107074.f90 | 11 +++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr107074.f90
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..c4e1537eed6 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2430,6 +2430,20 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree addr_expr,
break;
+case BT_PROCEDURE:
+ if (code->expr1
+ && code->expr1->symtree
+ && code->expr1->symtree->n.sym)
+ {
+ if (code->expr1->symtree->n.sym->attr.proc_pointer)
+ gfc_error ("Procedure pointer at %C cannot be an output item");
+ else
+ gfc_error ("Procedure at %C cannot be an output item");
+ return;
+ }
+ /* If a PROCEDURE item gets through to here, fall through and ICE. */
+ gcc_fallthrough ();
+
case_bt_struct:
case BT_CLASS:
if (gfc_bt_struct (ts->type) || ts->type == BT_CLASS)
diff --git a/gcc/testsuite/gfortran.dg/pr107074.f90 b/gcc/testsuite/gfortran.dg/pr107074.f90
new file mode 100644
index 000..a09088c2e9d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107074.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/107074 - ICE: Bad IO basetype (8)
+! Contributed by G.Steinmetz
+
+program p
+ implicit none
+ integer, external:: a
+ procedure(real), pointer :: b
+ print *, merge (a, a, .true.) ! { dg-error "Procedure" }
+ print *, merge (b, b, .true.) ! { dg-error "Procedure pointer" }
+end
--
2.35.3
Re: Adding a new thread model to GCC
On 4 October 2022 10:06:00 CEST, LIU Hao wrote: >在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道: >> >> No, sorry for my brevity. >> Using __gthread_t like in your patch is correct. >> > >I see. In 'libgfortran/io/async.c' there is > > ``` >async_unit *au = u->au; >LOCK (&au->lock); >thread_unit = u; >au->thread = __gthread_self (); > ``` > >so indeed `thread` should be `__gthread_t`. Yes. > By the way I reported this issue four months ago and haven't received any > response so far: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764 So, ideally, you would mention this PR in your patch. LGTM (obvious even) but I cannot formally approve it. thanks,
[PATCH] Fortran: error recovery for invalid types in array constructors [PR107000]
Dear all,
we did not recover well from bad expressions in array constructors,
especially when there was a typespec and a unary '+' or '-', and
when the array constructor was used in an arithmetic expression.
The attached patch introduces an ARITH_INVALID_TYPE that is used
when we try to recover from these errors, and tries to handle
all unary and binary arithmetic expressions.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From ad892a270c504def2f8f84494d5c7bcba9aef27f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 23:04:06 +0200
Subject: [PATCH] Fortran: error recovery for invalid types in array
constructors [PR107000]
gcc/fortran/ChangeLog:
PR fortran/107000
* arith.cc (gfc_arith_error): Define error message for
ARITH_INVALID_TYPE.
(reduce_unary): Catch arithmetic expressions with invalid type.
(reduce_binary_ac): Likewise.
(reduce_binary_ca): Likewise.
(reduce_binary_aa): Likewise.
(gfc_real2complex): Source expression must be of type REAL.
* gfortran.h (enum arith): Add ARITH_INVALID_TYPE.
gcc/testsuite/ChangeLog:
PR fortran/107000
* gfortran.dg/pr107000.f90: New test.
---
gcc/fortran/arith.cc | 19 ++
gcc/fortran/gfortran.h | 2 +-
gcc/testsuite/gfortran.dg/pr107000.f90 | 50 ++
3 files changed, 70 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr107000.f90
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index d57059a375f..e6e35ef3c42 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -118,6 +118,9 @@ gfc_arith_error (arith code)
case ARITH_WRONGCONCAT:
p = G_("Illegal type in character concatenation at %L");
break;
+case ARITH_INVALID_TYPE:
+ p = G_("Invalid type in arithmetic operation at %L");
+ break;
default:
gfc_internal_error ("gfc_arith_error(): Bad error code");
@@ -1261,6 +1264,9 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
gfc_expr *r;
arith rc;
+ if (op->expr_type == EXPR_OP && op->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
if (op->expr_type == EXPR_CONSTANT)
return eval (op, result);
@@ -1302,6 +1308,9 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
gfc_expr *r;
arith rc = ARITH_OK;
+ if (op1->expr_type == EXPR_OP && op1->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op1->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
@@ -1354,6 +1363,9 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
gfc_expr *r;
arith rc = ARITH_OK;
+ if (op2->expr_type == EXPR_OP && op2->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op2->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
@@ -1414,6 +1426,10 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
if (!gfc_check_conformance (op1, op2, _("elemental binary operation")))
return ARITH_INCOMMENSURATE;
+ if ((op1->expr_type == EXPR_OP && op1->ts.type == BT_UNKNOWN)
+ || (op2->expr_type == EXPR_OP && op2->ts.type == BT_UNKNOWN))
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op1->value.constructor);
for (c = gfc_constructor_first (head),
d = gfc_constructor_first (op2->value.constructor);
@@ -2238,6 +2254,9 @@ gfc_real2complex (gfc_expr *src, int kind)
arith rc;
bool did_warn = false;
+ if (src->ts.type != BT_REAL)
+return NULL;
+
result = gfc_get_constant_expr (BT_COMPLEX, kind, &src->where);
mpc_set_fr (result->value.complex, src->value.real, GFC_MPC_RND_MODE);
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 4babd77924b..fc0aa51df57 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -226,7 +226,7 @@ enum gfc_intrinsic_op
enum arith
{ ARITH_OK = 1, ARITH_OVERFLOW, ARITH_UNDERFLOW, ARITH_NAN,
ARITH_DIV0, ARITH_INCOMMENSURATE, ARITH_ASYMMETRIC, ARITH_PROHIBIT,
- ARITH_WRONGCONCAT
+ ARITH_WRONGCONCAT, ARITH_INVALID_TYPE
};
/* Statements. */
diff --git a/gcc/testsuite/gfortran.dg/pr107000.f90 b/gcc/testsuite/gfortran.dg/pr107000.f90
new file mode 100644
index 000..c13627f556b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107000.f90
@@ -0,0 +1,50 @@
+! { dg-do compile }
+! PR fortran/107000 - ICE in gfc_real2complex, reduce_unary, reduce_binary_*
+! Contributed by G.Steinmetz
+
+program p
+ real:: y(1)
+ complex :: x(1)
+ x = (1.0, 2.0) * [real :: -'1'] ! { dg-error "Operand of unary numeric operator" }
+ x = (1.0, 2.0) * [complex :: +'1'] ! { dg-error "Invalid type" }
+ x = [complex :: -'1'] * (1.0, 2.0) ! { dg-error "Invalid type" }
+ y = [complex :: -'1'] * 2 ! { dg-error "Invalid type" }
+ y = 2 * [complex :: -'1']! { dg-error "Invalid type" }
+ y = 2 * [complex :
