Re: [PATCH, Fortran] Use _Float128 rather than __float128 for c_float128 kind
On 17.09.21 06:02, Sandra Loosemore wrote: On 9/5/21 11:20 PM, Sandra Loosemore wrote: Unless the aarch64 maintainers think it is a bug that __float128 is not supported, I think the right solution here is [...] to tie the C_FLOAT128 kind to _Float128 rather than __float128, [...] Here's a new patch that does this. I've tested it on x86_64-linux-gnu, powerpc64le-linux-gnu, and aarch64-linux-gnu, and it does fix the previously reported failure compiling gfortran.dg/PR100914.c on aarch64. OK to commit? LGTM – thanks! Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[PATCH, OpenMP, Fortran] Support in_reduction for Fortran
Hi Jakub, and Fortran folks,
this patch does the required adjustments to let 'in_reduction' work for Fortran.
Not just for the target directive actually, task directive is also working after
this patch.
There is a little bit of adjustment in omp-low.c:scan_sharing_clauses:
RTL expand of the copy of the OMP_CLAUSE_IN_REDUCTION decl was failing
for Fortran by-reference arguments, which seems to work after placing them
under the outer ctx (when it exists). This also now needs checking the field_map
for existence of the field before inserting.
Tested without regressions on mainline trunk, is this okay?
(testing for devel/omp/gcc-11 is in progress)
Thanks,
Chung-Lin
2021-09-17 Chung-Lin Tang
gcc/fortran/ChangeLog:
* openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
false parameter. Add 'always,tofrom' map for OMP_LIST_IN_REDUCTION case.
(gfc_match_omp_clauses): Add 'openmp_target' default false parameter,
adjust call to gfc_match_omp_clause_reduction.
(match_omp): Adjust call to gfc_match_omp_clauses
* trans-openmp.c (gfc_trans_omp_taskgroup): Add call to
gfc_match_omp_clause, create and return block.
gcc/ChangeLog:
* omp-low.c (scan_sharing_clauses): Place in_reduction copy of variable
in outer ctx if if exists. Check if non-existent in field_map before
installing OMP_CLAUSE_IN_REDUCTION decl.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/reduction4.f90: Adjust omp target in_reduction' scan
pattern.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/target-in-reduction-1.f90: New test.
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index a64b7f5aa10..8179b5aa8bc 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1138,7 +1138,7 @@ failed:
static match
gfc_match_omp_clause_reduction (char pc, gfc_omp_clauses *c, bool openacc,
- bool allow_derived)
+ bool allow_derived, bool openmp_target = false)
{
if (pc == 'r' && gfc_match ("reduction ( ") != MATCH_YES)
return MATCH_NO;
@@ -1285,6 +1285,19 @@ gfc_match_omp_clause_reduction (char pc, gfc_omp_clauses
*c, bool openacc,
n->u2.udr = gfc_get_omp_namelist_udr ();
n->u2.udr->udr = udr;
}
+ if (openmp_target && list_idx == OMP_LIST_IN_REDUCTION)
+ {
+ gfc_omp_namelist *p = gfc_get_omp_namelist (), **tl;
+ p->sym = n->sym;
+ p->where = p->where;
+ p->u.map_op = OMP_MAP_ALWAYS_TOFROM;
+
+ tl = &c->lists[OMP_LIST_MAP];
+ while (*tl)
+ tl = &((*tl)->next);
+ *tl = p;
+ p->next = NULL;
+ }
}
return MATCH_YES;
}
@@ -1353,7 +1366,7 @@ gfc_match_dupl_atomic (bool not_dupl, const char *name)
static match
gfc_match_omp_clauses (gfc_omp_clauses **cp, const omp_mask mask,
bool first = true, bool needs_space = true,
- bool openacc = false)
+ bool openacc = false, bool openmp_target = false)
{
bool error = false;
gfc_omp_clauses *c = gfc_get_omp_clauses ();
@@ -2057,8 +2070,8 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
omp_mask mask,
goto error;
}
if ((mask & OMP_CLAUSE_IN_REDUCTION)
- && gfc_match_omp_clause_reduction (pc, c, openacc,
-allow_derived) == MATCH_YES)
+ && gfc_match_omp_clause_reduction (pc, c, openacc, allow_derived,
+openmp_target) == MATCH_YES)
continue;
if ((mask & OMP_CLAUSE_INBRANCH)
&& (m = gfc_match_dupl_check (!c->inbranch && !c->notinbranch,
@@ -3496,7 +3509,8 @@ static match
match_omp (gfc_exec_op op, const omp_mask mask)
{
gfc_omp_clauses *c;
- if (gfc_match_omp_clauses (&c, mask) != MATCH_YES)
+ if (gfc_match_omp_clauses (&c, mask, true, true, false,
+(op == EXEC_OMP_TARGET)) != MATCH_YES)
return MATCH_ERROR;
new_st.op = op;
new_st.ext.omp_clauses = c;
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index e55e0c81868..08483951066 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -6391,12 +6391,17 @@ gfc_trans_omp_task (gfc_code *code)
static tree
gfc_trans_omp_taskgroup (gfc_code *code)
{
+ stmtblock_t block;
+ gfc_start_block (&block);
tree body = gfc_trans_code (code->block->next);
tree stmt = make_node (OMP_TASKGROUP);
TREE_TYPE (stmt) = void_type_node;
OMP_TASKGROUP_BODY (stmt) = body;
- OMP_TASKGROUP_CLAUSES (stmt) = NULL_TREE;
- return stmt;
+ OMP_TASKGROUP_CLAUSES (stmt) = gfc_trans_omp_clauses (&block,
+ code->ext.omp_clauses,
+ code->loc);
+ gfc_add_expr_to_block (&block, s
[Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]
Short version:
* -Wno-missing-include-dirs had no effect as the warning was always on
* For CPP-only options like -idirafter, no warning was shown.
This patch tries to address both, i.e. cpp's include-dir diagnostics are
shown as well – and silencing the diagnostic works as well.
OK for mainline?
Tobias
PS: BACKGROUND and LONG DESCRIPTION
C/C++ by default have disabled the -Wmissing-include-dirs warning.
Fortran by default has that warning enabled.
The value is actually stored at two places (cf. c-family/c.opt):
Wmissing-include-dirs
... CPP(warn_missing_include_dirs) Var(cpp_warn_missing_include_dirs) Init(0)
For CPP, that value always needs to initialized – and it is used
in gcc/incpath.c as
cpp_options *opts = cpp_get_options (pfile);
if (opts->warn_missing_include_dirs && cur->user_supplied_p)
cpp_warning (pfile, CPP_W_MISSING_INCLUDE_DIRS, "%s: %s",
Additionally, there is cpp_warn_missing_include_dirs which is used by
Fortran – and which consists of
global_options.x_cpp_warn_missing_include_dirs
global_options_set._cpp_warn_missing_include_dirs
The flag processing happens as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534#c11
in short:
- First gfc_init_options is called
- Then for reach command-line option gfc_handle_option
- Finally gfc_post_options
Currently:
- gfc_init_options: Sets cpp_warn_missing_include_dirs
(unconditionally as unset)
- gfc_handle_option: Always warns about the missing include dir
- before gfc_post_options: set_option is called, which sets
cpp_warn_missing_include_dirs – but that's too late.
Additionally, as mentioned above – pfile's warn_missing_include_dirs
is never properly set.
* * *
This patch fixes those issues:
* Now -Wno-missing-include-dirs does silence the warnings
* CPP now also properly does warn.
Example (initial version):
$ gfortran-trunk ../empty.f90 -c -cpp -idirafter /fdaf/ -I bar/
-Wmissing-include-dirs
f951: Warning: Nonexistent include directory ‘bar//’ [-Wmissing-include-dirs]
: Warning: /fdaf/: No such file or directory
: Warning: bar/: No such file or directory
In order to avoid the double output for -I, I disabled the Fortran output if
CPP is enabled. Additionally, I had to use the cpp_reason_option_codes to
print the flag in brackets.
Fixed/final output is:
: Warning: /fdaf/: No such file or directory [-Wmissing-include-dirs]
: Warning: bar/: No such file or directory [-Wmissing-include-dirs]
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran: Fix -Wno-missing-include-dirs handling [PR55534]
gcc/fortran/ChangeLog:
PR fortran/55534
* cpp.c: Define GCC_C_COMMON_C for #include "options.h" to make
cpp_reason_option_codes available.
(gfc_cpp_register_include_paths): Make static, set pfile's
warn_missing_include_dirs and move before caller.
(gfc_cpp_init_cb): New, cb code moved from ...
(gfc_cpp_init_0): ... here.
(gfc_cpp_post_options): Call gfc_cpp_init_cb.
(cb_cpp_diagnostic_cpp_option): New. As implemented in c-family
to match CppReason flags to -W... names.
(cb_cpp_diagnostic): Use it to replace single special case.
* cpp.h (gfc_cpp_register_include_paths): Remove as now static.
* gfortran.h (gfc_check_include_dirs): New prototype.
* options.c (gfc_init_options): Don't set -Wmissing-include-dirs.
(gfc_post_options): Set it here after commandline processing.
* scanner.c (gfc_do_check_include_dirs, gfc_check_include_dirs):
New. Diagnostic moved from ...
(add_path_to_list): ... here, which came before cmdline processing.
* scanner.h (struct gfc_directorylist): Reorder for alignment issues,
add new 'bool warn'.
gcc/fortran/cpp.c | 106 ++---
gcc/fortran/cpp.h | 2 -
gcc/fortran/gfortran.h | 1 +
gcc/fortran/options.c | 14 +++
gcc/fortran/scanner.c | 58 +++
gcc/fortran/scanner.h | 2 +-
6 files changed, 116 insertions(+), 67 deletions(-)
diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index 83c4517acdb..3ff895455e9 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -19,11 +19,15 @@ along with GCC; see the file COPYING3. If not see
#include "config.h"
#include "system.h"
#include "coretypes.h"
+
+#define GCC_C_COMMON_C
+#include "options.h" /* For cpp_reason_option_codes. */
+#undef GCC_C_COMMON_C
+
#include "target.h"
#include "gfortran.h"
#include "diagnostic.h"
-
#include "toplev.h"
#include "../../libcpp/internal.h"
@@ -240,6 +244,18 @@ gfc_cpp_temporary_file (void)
return gfc_cpp_option.temporary_filename;
}
+static void
+gfc_cpp_register_include_paths (void)
+{
+ int cxx_stdinc = 0;
+ cpp_get_options (cpp_in)->warn_missing_include_dirs
+= global_options.x_cpp_warn_missing_include_dirs;
+
[committed] Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h (was: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h)
On 17.09.21 08:03, Gerald Pfeifer wrote:
On Tue, 14 Sep 2021, Gerald Pfeifer wrote:
And, related, does the following make sense and fixes the issue?
--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *,
const CFI_index_t []);
/* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
+#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \
&& LDBL_MIN_EXP == -16381 \
&& LDBL_MAX_EXP == 16384)
Yes, with this patch (on top of current trunk) i586-freebsd-* is back
in bootstrap land. :)
Neither this (which fixes the bootstrap) nor Sandra's rewrite (which
does not, but seemed generally liked) has been committed.
I have now committed the attached patch as r12-3621. It includes the
patch by Sandra
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579372.html
(approved 3 days ago) plus adding the "== 53" similar to above.
Hopefully, we can now close this issue.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 654187d05376f08667c8ba88309073e0345431c2
Author: Tobias Burnus
Date: Fri Sep 17 15:43:30 2021 +0200
Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h.
2021-09-17 Sandra Loosemore
Tobias Burnus
libgfortran/
* ISO_Fortran_binding.h: Only include float.h if the C compiler
doesn't have predefined __LDBL_* and __DBL_* macros. Handle
LDBL_MANT_DIG == 53 for FreeBSD.
diff --git a/libgfortran/ISO_Fortran_binding.h b/libgfortran/ISO_Fortran_binding.h
index 9c42464affa..50b02d27c9c 100644
--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -32,7 +32,6 @@ extern "C" {
#include /* Standard ptrdiff_t tand size_t. */
#include /* Integer types. */
-#include /* Macros for floating-point type characteristics. */
/* Constants, defined as macros. */
#define CFI_VERSION 1
@@ -217,40 +216,82 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []);
#endif
/* The situation with long double support is more complicated; we need to
- examine the type in more detail to figure out its kind. */
+ examine the type in more detail to figure out its kind.
+ GCC and some other compilers predefine the __LDBL* macros; otherwise
+ get the parameters we need from float.h. */
+
+#if (defined (__LDBL_MANT_DIG__) \
+ && defined (__LDBL_MIN_EXP__) \
+ && defined (__LDBL_MAX_EXP__) \
+ && defined (__DBL_MANT_DIG__) \
+ && defined (__DBL_MIN_EXP__) \
+ && defined (__DBL_MAX_EXP__))
+#define __CFI_LDBL_MANT_DIG__ __LDBL_MANT_DIG__
+#define __CFI_LDBL_MIN_EXP__ __LDBL_MIN_EXP__
+#define __CFI_LDBL_MAX_EXP__ __LDBL_MAX_EXP__
+#define __CFI_DBL_MANT_DIG__ __DBL_MANT_DIG__
+#define __CFI_DBL_MIN_EXP__ __DBL_MIN_EXP__
+#define __CFI_DBL_MAX_EXP__ __DBL_MAX_EXP__
+
+#else
+#include
+
+#if (defined (LDBL_MANT_DIG) \
+ && defined (LDBL_MIN_EXP) \
+ && defined (LDBL_MAX_EXP) \
+ && defined (DBL_MANT_DIG) \
+ && defined (DBL_MIN_EXP) \
+ && defined (DBL_MAX_EXP))
+#define __CFI_LDBL_MANT_DIG__ LDBL_MANT_DIG
+#define __CFI_LDBL_MIN_EXP__ LDBL_MIN_EXP
+#define __CFI_LDBL_MAX_EXP__ LDBL_MAX_EXP
+#define __CFI_DBL_MANT_DIG__ DBL_MANT_DIG
+#define __CFI_DBL_MIN_EXP__ DBL_MIN_EXP
+#define __CFI_DBL_MAX_EXP__ DBL_MAX_EXP
+
+#else
+#define CFI_no_long_double 1
+
+#endif /* Definitions from float.h. */
+#endif /* Definitions from compiler builtins. */
+
+/* Can't determine anything about long double support? */
+#if (defined (CFI_no_long_double))
+#define CFI_type_long_double -2
+#define CFI_type_long_double_Complex -2
/* Long double is the same kind as double. */
-#if (LDBL_MANT_DIG == DBL_MANT_DIG \
- && LDBL_MIN_EXP == DBL_MIN_EXP \
- && LDBL_MAX_EXP == DBL_MAX_EXP)
+#elif (__CFI_LDBL_MANT_DIG__ == __CFI_DBL_MANT_DIG__ \
+ && __CFI_LDBL_MIN_EXP__ == __CFI_DBL_MIN_EXP__ \
+ && __CFI_LDBL_MAX_EXP__ == __CFI_DBL_MAX_EXP__)
#define CFI_type_long_double CFI_type_double
#define CFI_type_long_double_Complex CFI_type_double_Complex
/* This is the 80-bit encoding on x86; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
- && LDBL_MIN_EXP == -16381 \
- && LDBL_MAX_EXP == 16384)
+#elif ((__CFI_LDBL_MANT_DIG__ == 64 || __CFI_LDBL_MANT_DIG__ == 53) \
+ && __CFI_LDBL_MIN_EXP__ == -16381 \
+ && __CFI_LDBL_MAX_EXP__ == 16384)
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
/* This is the 96-bit encoding on m68k; Fortran assigns it kind 10. */
-#elif (LDBL_MANT_DIG == 64 \
Re: [PATCH, OpenMP, Fortran] Support in_reduction for Fortran
On Fri, Sep 17, 2021 at 07:57:38PM +0800, Chung-Lin Tang wrote:
> 2021-09-17 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
> false parameter. Add 'always,tofrom' map for OMP_LIST_IN_REDUCTION case.
> (gfc_match_omp_clauses): Add 'openmp_target' default false parameter,
> adjust call to gfc_match_omp_clause_reduction.
> (match_omp): Adjust call to gfc_match_omp_clauses
> * trans-openmp.c (gfc_trans_omp_taskgroup): Add call to
> gfc_match_omp_clause, create and return block.
>
> gcc/ChangeLog:
>
> * omp-low.c (scan_sharing_clauses): Place in_reduction copy of variable
> in outer ctx if if exists. Check if non-existent in field_map before
> installing OMP_CLAUSE_IN_REDUCTION decl.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/gomp/reduction4.f90: Adjust omp target in_reduction' scan
> pattern.
>
> libgomp/ChangeLog:
>
> * testsuite/libgomp.fortran/target-in-reduction-1.f90: New test.
> @@ -3496,7 +3509,8 @@ static match
> match_omp (gfc_exec_op op, const omp_mask mask)
> {
>gfc_omp_clauses *c;
> - if (gfc_match_omp_clauses (&c, mask) != MATCH_YES)
> + if (gfc_match_omp_clauses (&c, mask, true, true, false,
> + (op == EXEC_OMP_TARGET)) != MATCH_YES)
The ()s around op == EXEC_OMP_TARGET are unnecessary.
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -6391,12 +6391,17 @@ gfc_trans_omp_task (gfc_code *code)
> static tree
> gfc_trans_omp_taskgroup (gfc_code *code)
> {
> + stmtblock_t block;
> + gfc_start_block (&block);
>tree body = gfc_trans_code (code->block->next);
>tree stmt = make_node (OMP_TASKGROUP);
>TREE_TYPE (stmt) = void_type_node;
>OMP_TASKGROUP_BODY (stmt) = body;
> - OMP_TASKGROUP_CLAUSES (stmt) = NULL_TREE;
> - return stmt;
> + OMP_TASKGROUP_CLAUSES (stmt) = gfc_trans_omp_clauses (&block,
> + code->ext.omp_clauses,
> + code->loc);
> + gfc_add_expr_to_block (&block, stmt);
If this was missing, then I'm afraid we lack a lot of testsuite coverage for
Fortran task reductions. It doesn't need to be covered in this patch, but
would be
good to cover it incrementally. Because the above means nothing with
taskgroup with task_reduction clause(s) could work properly at runtime.
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -1317,9 +1317,13 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> if (is_omp_target (ctx->stmt))
> {
> tree at = decl;
> + omp_context *scan_ctx = ctx;
> if (ctx->outer)
> - scan_omp_op (&at, ctx->outer);
> - tree nt = omp_copy_decl_1 (at, ctx);
> + {
> + scan_omp_op (&at, ctx->outer);
> + scan_ctx = ctx->outer;
> + }
> + tree nt = omp_copy_decl_1 (at, scan_ctx);
> splay_tree_insert (ctx->field_map,
>(splay_tree_key) &DECL_CONTEXT (decl),
>(splay_tree_value) nt);
You're right that the var remembered with &DECL_CONTEXT (whatever) key is
used outside of the target construct rather than inside of it.
So, if ctx->outer is non-NULL, it seems right to create the var in that
outer context. But, if ctx->outer is NULL, which can happen if the
target construct is orphaned, consider e.g.
extern int &x;
extern int &y;
void
foo ()
{
#pragma omp target in_reduction (+: x, y)
{
x = x + 8;
y = y + 16;
}
}
void
bar ()
{
#pragma omp taskgroup task_reduction (+: x, y)
foo ();
}
then those artificial decls (copies of x and y) should appear
to be at the function scope and not inside of the target region.
Therefore, I wonder if omp_copy_decl_2 shouldn't do the
DECL_CONTEXT (copy) = current_function_decl;
DECL_CHAIN (copy) = ctx->block_vars;
ctx->block_vars = copy;
(the last one can be moved next to the others) only if ctx != NULL
and otherwise call gimple_add_tmp_var (copy); instead
and then just call omp_copy_decl_1 at that spot with unconditional
ctx->outer.
Also, this isn't the only place that should have such a change,
there is also
if (ctx->outer)
scan_omp_op (&at, ctx->outer);
tree nt = omp_copy_decl_1 (at, ctx);
splay_tree_insert (ctx->field_map,
(splay_tree_key) &DECL_CONTEXT (t),
(splay_tree_value) nt);
a few lines above this and I'd expect that it should be (at, ctx->outer)
as well.
> @@ -1339,7 +1343,9 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> if (!is_global_var (maybe_lookup_decl_in_outer_ctx (decl, ctx)))
> {
> by_ref = use_pointer_for_field (decl, ctx);
> - if (OMP_CLAUSE_CODE
Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]
I seemingly messed up a bit in previous patch – corrected version attached. OK? Tobias PS: Due to now enabling the missing-include-dir warning also for cpp,the following warning show up during build. This seems to be specific to libgfortran building, libgomp works and real-world code also does not seem to be affected: : Error: /x86_64-pc-linux-gnu/include: No such file or directory [-Werror=missing-include-dirs] : Error: /x86_64-pc-linux-gnu/sys-include: No such file or directory [-Werror=missing-include-dirs] : Error: finclude: No such file or directory [-Werror=missing-include-dirs] The latter is due to the driver adding '-fintrinsic-modules-path finclude' when calling f951. I think the rest is a side effect of running with -B and other build trickery. The warnings do not trigger when compiling the Fortran file in libgomp nor for a quick real-world case (which uses gfortran in a normal way not with -B etc.). Thus, I think it should be fine. Alternatively, we could think of reducing the noisiness. Thoughts? PPS: Besides this, the following still applies: On 17.09.21 15:02, Tobias Burnus wrote: Short version: * -Wno-missing-include-dirs had no effect as the warning was always on * For CPP-only options like -idirafter, no warning was shown. This patch tries to address both, i.e. cpp's include-dir diagnostics are shown as well – and silencing the diagnostic works as well. OK for mainline? Tobias PS: BACKGROUND and LONG DESCRIPTION C/C++ by default have disabled the -Wmissing-include-dirs warning. Fortran by default has that warning enabled. The value is actually stored at two places (cf. c-family/c.opt): Wmissing-include-dirs ... CPP(warn_missing_include_dirs) Var(cpp_warn_missing_include_dirs) Init(0) For CPP, that value always needs to initialized – and it is used in gcc/incpath.c as cpp_options *opts = cpp_get_options (pfile); if (opts->warn_missing_include_dirs && cur->user_supplied_p) cpp_warning (pfile, CPP_W_MISSING_INCLUDE_DIRS, "%s: %s", Additionally, there is cpp_warn_missing_include_dirs which is used by Fortran – and which consists of global_options.x_cpp_warn_missing_include_dirs global_options_set._cpp_warn_missing_include_dirs The flag processing happens as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534#c11 in short: - First gfc_init_options is called - Then for reach command-line option gfc_handle_option - Finally gfc_post_options Currently: - gfc_init_options: Sets cpp_warn_missing_include_dirs (unconditionally as unset) - gfc_handle_option: Always warns about the missing include dir - before gfc_post_options: set_option is called, which sets cpp_warn_missing_include_dirs – but that's too late. Additionally, as mentioned above – pfile's warn_missing_include_dirs is never properly set. * * * This patch fixes those issues: * Now -Wno-missing-include-dirs does silence the warnings * CPP now also properly does warn. Example (initial version): $ gfortran-trunk ../empty.f90 -c -cpp -idirafter /fdaf/ -I bar/ -Wmissing-include-dirs f951: Warning: Nonexistent include directory ‘bar//’ [-Wmissing-include-dirs] : Warning: /fdaf/: No such file or directory : Warning: bar/: No such file or directory In order to avoid the double output for -I, I disabled the Fortran output if CPP is enabled. Additionally, I had to use the cpp_reason_option_codes to print the flag in brackets. Fixed/final output is: : Warning: /fdaf/: No such file or directory [-Wmissing-include-dirs] : Warning: bar/: No such file or directory [-Wmissing-include-dirs] - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 Fortran: Fix -Wno-missing-include-dirs handling [PR55534] gcc/fortran/ChangeLog: PR fortran/55534 * cpp.c: Define GCC_C_COMMON_C for #include "options.h" to make cpp_reason_option_codes available. (gfc_cpp_register_include_paths): Make static, set pfile's warn_missing_include_dirs and move before caller. (gfc_cpp_init_cb): New, cb code moved from ... (gfc_cpp_init_0): ... here. (gfc_cpp_post_options): Call gfc_cpp_init_cb. (cb_cpp_diagnostic_cpp_option): New. As implemented in c-family to match CppReason flags to -W... names. (cb_cpp_diagnostic): Use it to replace single special case. * cpp.h (gfc_cpp_register_include_paths): Remove as now static. * gfortran.h (gfc_check_include_dirs): New prototype. * options.c (gfc_init_options): Don't set -Wmissing-include-dirs. (gfc_post_options): Set it here after commandline processing. * scanner.c (gfc_do_check_include_dirs, gfc_check_include_dirs): New. Diagnostic moved from ... (add_path_to_list): ... here, which came before cmdline processing. * scanner.h (struct gfc_directorylist): Reorder for alignment issues, add new 'bool warn'. libgfort
[PATCH, committed] PR fortran/102366] [10/11/12 Regression] large arrays no longer become static
The attempt to fix a misleading warning lead to a regression that prevented
putting large variables in the main into static storage. So instead of
preventing the move, we now disable the useless warning for variables in
the main.
Regtested on x86_64-pc-linux-gnu. The patch was ok'ed in the PR by Jakub.
Pushed to mainline; will backport to affected branches.
Note, however, that the Fortran 2018 standard has:
F2018 8.5.16 SAVE attribute
(4) A variable, common block, or procedure pointer declared in the scoping
unit of a main program, [...] implicitly has the SAVE attribute
We already have code that sets IMPLICIT_SAVE for variables e.g. in
(sub)modules, but for code such as
real(kind=4) :: a(10)
a=1.0
end
(with and without PROGRAM statement) the array turns out to be too small to
currently get moved to static storage. I get in decl.c::match_attr_spec:
gfc_state_stack->state == COMP_NONE, which defeated my attempts to an
ultimate solution.
I have opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102390
to track this.
Thanks,
Harald
commit 51166eb2c534692c3c7779def24f83c8c3811b98
Author: Harald Anlauf
Date: Fri Sep 17 21:45:33 2021 +0200
Fortran - (large) arrays in the main shall be static
gcc/fortran/ChangeLog:
PR fortran/102366
* trans-decl.c (gfc_finish_var_decl): Disable the warning message
for variables moved from stack to static storange if they are
declared in the main, but allow the move to happen.
gcc/testsuite/ChangeLog:
PR fortran/102366
* gfortran.dg/pr102366.f90: New test.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index bed61e2325d..3bd8a0fe935 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -743,7 +743,6 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
/* Keep variables larger than max-stack-var-size off stack. */
if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive)
- && !(sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program)
&& !sym->attr.automatic
&& sym->attr.save != SAVE_EXPLICIT
&& sym->attr.save != SAVE_IMPLICIT
@@ -757,7 +756,9 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
|| sym->attr.allocatable)
&& !DECL_ARTIFICIAL (decl))
{
- if (flag_max_stack_var_size > 0)
+ if (flag_max_stack_var_size > 0
+ && !(sym->ns->proc_name
+ && sym->ns->proc_name->attr.is_main_program))
gfc_warning (OPT_Wsurprising,
"Array %qs at %L is larger than limit set by "
"%<-fmax-stack-var-size=%>, moved from stack to static "
diff --git a/gcc/testsuite/gfortran.dg/pr102366.f90 b/gcc/testsuite/gfortran.dg/pr102366.f90
new file mode 100644
index 000..d002f64a8ae
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102366.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original -Wall" }
+! { dg-final { scan-tree-dump-times "static real" 1 "original" } }
+! PR fortran/102366 - large arrays no longer become static
+
+program p
+ real(kind=4) :: a(16776325)
+ a=1.0
+end
[Patch] Fortran/OpenMP: unconstrained/reproducible ordered modifier
This patch adds Fortran support for the new OpenMP 5.1 unconstrained and
reproducible
modifiers to ordered(concurrent).
This patch requires Jakub's patch to handle the middle-end (and C/C++) part,
which still has to be committed. The testcases are based on the C/C++ ones.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran/OpenMP: unconstrained/reproducible ordered modifier
gcc/fortran/ChangeLog:
* gfortran.h (gfc_omp_clauses): Add order_unconstrained.
* dump-parse-tree.c (show_omp_clauses): Dump it.
* openmp.c (gfc_match_omp_clauses): Match unconstrained/reproducible
modifiers to ordered(concurrent).
(OMP_DISTRIBUTE_CLAUSES): Accept ordered clause.
(resolve_omp_clauses): Reject ordered + order on same directive.
* trans-openmp.c (gfc_trans_omp_clauses, gfc_split_omp_clauses): Pass
on unconstrained modifier of ordered(concurrent).
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/order-5.f90: New test.
* gfortran.dg/gomp/order-6.f90: New test.
* gfortran.dg/gomp/order-7.f90: New test.
* gfortran.dg/gomp/order-8.f90: New test.
* gfortran.dg/gomp/order-9.f90: New test.
gcc/fortran/dump-parse-tree.c | 7 +-
gcc/fortran/gfortran.h | 3 +-
gcc/fortran/openmp.c | 25 +-
gcc/fortran/trans-openmp.c | 7 +
gcc/testsuite/gfortran.dg/gomp/order-5.f90 | 129 +
gcc/testsuite/gfortran.dg/gomp/order-6.f90 | 436 +
gcc/testsuite/gfortran.dg/gomp/order-7.f90 | 59
gcc/testsuite/gfortran.dg/gomp/order-8.f90 | 61
gcc/testsuite/gfortran.dg/gomp/order-9.f90 | 35 +++
9 files changed, 756 insertions(+), 6 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index a1df47c2f82..28eb09e261d 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1630,7 +1630,12 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
if (omp_clauses->independent)
fputs (" INDEPENDENT", dumpfile);
if (omp_clauses->order_concurrent)
-fputs (" ORDER(CONCURRENT)", dumpfile);
+{
+ fputs (" ORDER(", dumpfile);
+ if (omp_clauses->order_unconstrained)
+ fputs ("UNCONSTRAINED:", dumpfile);
+ fputs ("CONCURRENT)", dumpfile);
+}
if (omp_clauses->ordered)
{
if (omp_clauses->orderedc)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index fdf556eef3d..8b91225d659 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1491,7 +1491,8 @@ typedef struct gfc_omp_clauses
unsigned inbranch:1, notinbranch:1, nogroup:1;
unsigned sched_simd:1, sched_monotonic:1, sched_nonmonotonic:1;
unsigned simd:1, threads:1, depend_source:1, destroy:1, order_concurrent:1;
- unsigned capture:1, grainsize_strict:1, num_tasks_strict:1;
+ unsigned order_unconstrained:1, capture:1, grainsize_strict:1;
+ unsigned num_tasks_strict:1;
ENUM_BITFIELD (gfc_omp_sched_kind) sched_kind:3;
ENUM_BITFIELD (gfc_omp_device_type) device_type:2;
ENUM_BITFIELD (gfc_omp_memorder) memorder:3;
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index a64b7f5aa10..9ee52d6b0ea 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2369,9 +2369,23 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const omp_mask mask,
break;
case 'o':
if ((mask & OMP_CLAUSE_ORDER)
- && !c->order_concurrent
- && gfc_match ("order ( concurrent )") == MATCH_YES)
+ && (m = gfc_match_dupl_check (!c->order_concurrent, "order ("))
+ != MATCH_NO)
{
+ if (m == MATCH_ERROR)
+ goto error;
+ if (gfc_match (" reproducible : concurrent )") == MATCH_YES
+ || gfc_match (" concurrent )") == MATCH_YES)
+ ;
+ else if (gfc_match (" unconstrained : concurrent )") == MATCH_YES)
+ c->order_unconstrained = true;
+ else
+ {
+ gfc_error ("Expected ORDER(CONCURRENT) at %C "
+ "with optional % or "
+ "% modifier");
+ goto error;
+ }
c->order_concurrent = true;
continue;
}
@@ -3475,7 +3489,8 @@ cleanup:
| OMP_CLAUSE_SHARED | OMP_CLAUSE_REDUCTION)
#define OMP_DISTRIBUTE_CLAUSES \
(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE \
- | OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_COLLAPSE | OMP_CLAUSE_DIST_SCHEDULE)
+ | OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_COLLAPSE | OMP_CLAUSE_DIST_SCHEDULE \
+ | OMP_CLAUSE_ORDER)
#define OMP_SINGLE_CLAUSES \
(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE)
#define OMP_ORDERED_CLAUSES \
@@ -5643,7 +5658,9 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
if (omp_clauses->orderedc && omp_clauses->orderedc < omp_clauses->collapse)
gfc_error ("ORDERED clause parameter is less than COLLAPSE at %L",
&code->loc);
-
+ if (om
Re: [committed] Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h (was: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h)
On Fri, 17 Sep 2021, Tobias Burnus wrote: > I have now committed the attached patch as r12-3621. It includes the > patch by Sandra > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579372.html > (approved 3 days ago) plus adding the "== 53" similar to above. Thank you, Tobias; thank you, everyone! > Hopefully, we can now close this issue. My nightly tester passed the build and is currently running the testsuite, so looks good. Gerald
