Re: [PR fortran/83184] Fix matching code for clist/old-style initializers when encountering assumed-rank declarations
On Tue, Jul 17, 2018, 04:31 Janus Weil wrote: > Did someone actually approve this patch? Apparently it was committed > as r262744 and caused the following regression: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543 > > Cheers, > Janus > > > > 2018-06-27 23:07 GMT+02:00 Fritz Reese : > > The attached patch fixes PR fortran/83184, which is actually two > > distinct bugs as described in the PR. Passes regtests. > > > > The patch is attached. OK for trunk and 7/8-branch? > > > > From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001 > > From: Fritz Reese > > Date: Wed, 27 Jun 2018 16:16:31 -0400 > > Subject: [PATCH 2/3] PR fortran/83184 > > > > Fix handling of invalid assumed-shape/size arrays in legacy initializer > > lists. > > > > gcc/fortran/ > > > > * decl.c (match_old_style_init): Initialize locus of variable > expr when > > creating a data variable. > > (match_clist_expr): Verify array is explicit shape/size before > > attempting to allocate constant array constructor. > > > > gcc/testsuite/ > > > > * gfortran.dg/assumed_rank_14.f90: New testcase. > > * gfortran.dg/assumed_rank_15.f90: New testcase. > > * gfortran.dg/dec_structure_8.f90: Update error messages. > > * gfortran.dg/dec_structure_23.f90: Update error messages. > > --- > > gcc/fortran/decl.c | 63 > +++--- > > gcc/testsuite/gfortran.dg/assumed_rank_14.f90 | 11 + > > gcc/testsuite/gfortran.dg/assumed_rank_15.f90 | 11 + > > gcc/testsuite/gfortran.dg/dec_structure_23.f90 | 6 +-- > > gcc/testsuite/gfortran.dg/dec_structure_8.f90 | 6 +-- > > 5 files changed, 64 insertions(+), 33 deletions(-) > > create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_14.f90 > > create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_15.f90 > The patch touches only code which I introduced originally. However apparently my revision of trunk when I tested this patch was before the error message was changed for dec_structure_23.f90 by Steve in r257971 (I had trouble bootstrapping the latest at the time). Therefore the committing of this patch “reverted” the change to the testcase. The error message should match “array with nonconstant bounds”. I’ll fix the testcase later today when I am in a place where I can do so. Fritz >
Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions
On Tue, Jul 17, 2018 at 10:32 AM Janus Weil wrote:
>
> 2018-07-17 9:52 GMT+02:00 Janus Weil :
> >> 2018-07-16 21:50 GMT+02:00 Thomas Koenig :
> >>> What I would suggest is to enable -Wfunction-eliminiation with
> >>> -Wextra and also use that for your new warning.
> >>
> >> Thanks for the comments. Makes sense. Updated patch attached.
> >
> >
> > Huh, after actually trying -Wfunction-elimination, I'm not so sure any
> > more if it really makes sense to throw the new warnings in there,
> > mainly for two reasons:
[...]
> > In other words: Does it make sense to tone down
> > -Wfunction-elimination, by only warning about impure functions?
>
> Here is an update of the patch which does that. Regtesting now ...
>
> Cheers,
> Janus
Would not this break the testcase function_optimize_5.f90 :
write (unit=line, fmt='(4F7.2)') matmul(a,b) & ! { dg-warning
"Removing call to function 'matmul'" }
& + matmul(a,b)
z = sin(x) + 2.0 + sin(x) ! { dg-warning "Removing call to function 'sin'" }
print *,z
x = ext_func(a) + 23 + ext_func(a)
print *,d,x
z = element(x) + element(x) ! { dg-warning "Removing call to
function 'element'" }
print *,z
i = mypure(x) - mypure(x) ! { dg-warning "Removing call to function
'mypure'" }
The docs for -Wfunction-elimination would read:
> Warn if any calls to functions are eliminated by the optimizations
> enabled by the @option{-ffrontend-optimize} option.
> This option is implied by @option{-Wextra}.
However, with your patch, it should probably read something like "warn
if any calls to impure functions are eliminated..." Possibly with an
explicit remark indicating that pure functions are not warned.
Additionally:
$ ./contrib/check_GNU_style.sh pr85599_v6.diff
Lines should not exceed 80 characters.
33:+ if (e->expr_type == EXPR_FUNCTION && !gfc_pure_function (e,
&name) && !gfc_implicit_pure_function (e))
36:+ gfc_warning (OPT_Wfunction_elimination, "Removing call to
impure function %qs at %L", name, &(e->where));
38:+ gfc_warning (OPT_Wfunction_elimination, "Removing call to
impure function at %L", &(e->where));
201:+ if (f != last && !gfc_pure_function (f, &name) &&
!gfc_implicit_pure_function (f))
Blocks of 8 spaces should be replaced with tabs.
36:+ gfc_warning (OPT_Wfunction_elimination, "Removing call to
impure function %qs at %L", name, &(e->where));
38:+ gfc_warning (OPT_Wfunction_elimination, "Removing call to
impure function at %L", &(e->where));
230:+ with impure function as second operand. */
Dot, space, space, new sentence.
79:+expression, if they do not contribute to the final result. For logical
82:+result of the expression can be established without them. However, since not
Have you considered using levels for the flag, such that the original
behavior of -Wfunction-elimination would be retained with e.g.
-Wfunction-elimination=2 whereas one could use
-Wfunction-elimination=1 (or similar) to omit warnings about impure
functions?
- Fritz
Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions
On Tue, Jul 17, 2018 at 2:36 PM Janus Weil wrote: > > 2018-07-17 19:34 GMT+02:00 Thomas Koenig : > > Am 17.07.2018 um 19:19 schrieb Janus Weil: [...] > > I do hope that things have converged by now and that this will be the > last incarnation of the patch. If there is no more feedback in the > next 24 hours, I'll commit this tomorrow. > > Cheers, > Janus I hate to be pedantic but it is still worth fixing the style discrepancies: $ ./contrib/check_GNU_style.sh pr85599_v7.diff > > Lines should not exceed 80 characters. > 209:+ if (f != last && !gfc_pure_function (f, &name) && > !gfc_implicit_pure_function (f)) > > Blocks of 8 spaces should be replaced with tabs. > 37:+ gfc_warning (OPT_Wfunction_elimination, > 41:+ gfc_warning (OPT_Wfunction_elimination, > 238:+ with impure function as second operand. */ > > Dot, space, space, new sentence. > 84:+expression, if they do not contribute to the final result. For logical > 87:+result of the expression can be established without them. However, since > not My only other comment is I am not sure why you make pure_function()/gfc_implicit_pure_function() public... but I have no real problem with it. Just means rebuilding all of f951 instead of one object. :-( Otherwise if the patch does what it appears to do and passes tests then it seems fine to me. Fritz
RE: Fwd: DEC Extension Patches: Structure, Union, and Map
Please see the original message:
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html
I have to send the patches separately, as together they are blocked by
the spam filter. This is part 1:
---
Fritz Reese
From 00eaf54e4cc4bb63bfbcb1ffab97cb9b593f2c6d Mon Sep 17 00:00:00 2001
From: Fritz O. Reese
Date: Thu, 16 Oct 2014 15:35:54 -0400
Subject: [PATCH 1/4] 2014-10-16 Fritz Reese
* gcc/fortran/module.c (dt_upper_string): Rename to gfc_dt_upper_string
(dt_lower_string): Likewise.
* gcc/fortran/gfortran.h: Make new gfc_dt_upper/lower_string global.
* gcc/fortran/class.c: Use gfc_dt_upper_string.
* gcc/fortran/decl.c: Likewise.
* gcc/fortran/symbol.c: Likewise.
---
gcc/fortran/class.c|3 +--
gcc/fortran/decl.c | 12 +++-
gcc/fortran/gfortran.h |2 ++
gcc/fortran/module.c | 26 +-
gcc/fortran/symbol.c | 11 +++
5 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 6a7339f..b3e1b45 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -477,8 +477,7 @@ get_unique_type_string (char *string, gfc_symbol *derived)
if (derived->attr.unlimited_polymorphic)
strcpy (dt_name, "STAR");
else
-strcpy (dt_name, derived->name);
- dt_name[0] = TOUPPER (dt_name[0]);
+strcpy (dt_name, gfc_dt_upper_string (derived->name));
if (derived->attr.unlimited_polymorphic)
sprintf (string, "_%s", dt_name);
else if (derived->module)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index d3ddda2..2b92623 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2964,9 +2964,7 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
stored in a symtree with the first letter of the name capitalized; the
symtree with the all lower-case name contains the associated
generic function. */
- dt_name = gfc_get_string ("%c%s",
- (char) TOUPPER ((unsigned char) name[0]),
- (const char*)&name[1]);
+ dt_name = gfc_dt_upper_string (name);
sym = NULL;
dt_sym = NULL;
if (ts->kind != -1)
@@ -3480,9 +3478,7 @@ gfc_match_import (void)
letter of the name capitalized; the symtree with the all
lower-case name contains the associated generic function. */
st = gfc_new_symtree (&gfc_current_ns->sym_root,
- gfc_get_string ("%c%s",
-(char) TOUPPER ((unsigned char) name[0]),
-&name[1]));
+gfc_dt_upper_string (name));
st->n.sym = sym;
sym->refs++;
sym->attr.imported = 1;
@@ -8099,9 +8095,7 @@ gfc_match_derived_decl (void)
if (!sym)
{
/* Use upper case to save the actual derived-type symbol. */
- gfc_get_symbol (gfc_get_string ("%c%s",
- (char) TOUPPER ((unsigned char) gensym->name[0]),
- &gensym->name[1]), NULL, &sym);
+ gfc_get_symbol (gfc_dt_upper_string (gensym->name), NULL, &sym);
sym->name = gfc_get_string (gensym->name);
head = gensym->generic;
intr = gfc_get_interface ();
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 33fffd8..2e6ea4b 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3174,6 +3174,8 @@ void gfc_module_done_2 (void);
void gfc_dump_module (const char *, int);
bool gfc_check_symbol_access (gfc_symbol *);
void gfc_free_use_stmts (gfc_use_list *);
+const char *gfc_dt_lower_string (const char *);
+const char *gfc_dt_upper_string (const char *);
/* primary.c */
symbol_attribute gfc_variable_attr (gfc_expr *, gfc_typespec *);
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 32ee526..152574c 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -422,8 +422,8 @@ resolve_fixups (fixup_t *f, void *gp)
to convert the symtree name of a derived-type to the symbol name or to
the name of the associated generic function. */
-static const char *
-dt_lower_string (const char *name)
+const char *
+gfc_dt_lower_string (const char *name)
{
if (name[0] != (char) TOLOWER ((unsigned char) name[0]))
return gfc_get_string ("%c%s", (char) TOLOWER ((unsigned char) name[0]),
@@ -437,8 +437,8 @@ dt_lower_string (const char *name)
symtree/symbol name of the associated generic function start with a lower-
case character. */
-static const char *
-dt_upper_string (const char *name)
+const char *
+gfc_dt_upper_string (const char *name)
{
if (name[0] != (char) TOUPPER ((unsigned char) name[0]))
return gfc_get_string ("%c%s", (char) TOUPPER ((unsigned char) name[0]),
@@ -832,7 +832,7 @@ find_use_name_n (const char *name, int *inst, bool interface)
/* For derived types. */
if (name[0] != (char) TOLOWER ((unsigned char) name[0]))
-low_name = dt_lower_string (name);
+low_name = gfc_dt_lower_string (name);
i = 0;
for (u = gfc_re
RE: Fwd: DEC Extension Patches: Structure, Union, and Map
Please see the original thread
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html.
I have to send the patches separately, as together they cause me to be
blocked for spamming. This is patch 2:
---
Fritz Reese
From 2f7077c45fdcf2d05554d9d2e22fc5261bd95661 Mon Sep 17 00:00:00 2001
From: Fritz O. Reese
Date: Mon, 10 Nov 2014 13:34:06 -0500
Subject: [PATCH 2/4] 2014-11-10 Fritz Reese
gcc/fortran/
* resolve.c (resolve_component): New function.
(resolve_fl_derived0): Move component loop code to resolve_component.
---
gcc/fortran/resolve.c | 742 -
1 files changed, 365 insertions(+), 377 deletions(-)
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 556c846..1c3b814 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12899,438 +12899,426 @@ check_defined_assignments (gfc_symbol *derived)
}
-/* Resolve the components of a derived type. This does not have to wait until
- resolution stage, but can be done as soon as the dt declaration has been
- parsed. */
+/* Resolve a single component of a derived type. */
static bool
-resolve_fl_derived0 (gfc_symbol *sym)
+resolve_component (gfc_component *c, gfc_symbol *sym)
{
- gfc_symbol* super_type;
- gfc_component *c;
+ gfc_symbol *super_type;
- if (sym->attr.unlimited_polymorphic)
+ if (c->attr.artificial)
return true;
- super_type = gfc_get_derived_super_type (sym);
+ /* F2008, C442. */
+ if ((!sym->attr.is_class || c != sym->components)
+ && c->attr.codimension
+ && (!c->attr.allocatable || (c->as && c->as->type != AS_DEFERRED)))
+{
+ gfc_error ("Coarray component %qs at %L must be allocatable with "
+ "deferred shape", c->name, &c->loc);
+ return false;
+}
- /* F2008, C432. */
- if (super_type && sym->attr.coarray_comp && !super_type->attr.coarray_comp)
+ /* F2008, C443. */
+ if (c->attr.codimension && c->ts.type == BT_DERIVED
+ && c->ts.u.derived->ts.is_iso_c)
{
- gfc_error ("As extending type %qs at %L has a coarray component, "
- "parent type %qs shall also have one", sym->name,
- &sym->declared_at, super_type->name);
+ gfc_error ("Component %qs at %L of TYPE(C_PTR) or TYPE(C_FUNPTR) "
+ "shall not be a coarray", c->name, &c->loc);
return false;
}
- /* Ensure the extended type gets resolved before we do. */
- if (super_type && !resolve_fl_derived0 (super_type))
-return false;
+ /* F2008, C444. */
+ if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.coarray_comp
+ && (c->attr.codimension || c->attr.pointer || c->attr.dimension
+ || c->attr.allocatable))
+{
+ gfc_error ("Component %qs at %L with coarray component "
+ "shall be a nonpointer, nonallocatable scalar",
+ c->name, &c->loc);
+ return false;
+}
- /* An ABSTRACT type must be extensible. */
- if (sym->attr.abstract && !gfc_type_is_extensible (sym))
+ /* F2008, C448. */
+ if (c->attr.contiguous && (!c->attr.dimension || !c->attr.pointer))
{
- gfc_error ("Non-extensible derived-type %qs at %L must not be ABSTRACT",
- sym->name, &sym->declared_at);
+ gfc_error ("Component %qs at %L has the CONTIGUOUS attribute but "
+ "is not an array pointer", c->name, &c->loc);
return false;
}
- c = (sym->attr.is_class) ? sym->components->ts.u.derived->components
- : sym->components;
+ if (c->attr.proc_pointer && c->ts.interface)
+{
+ gfc_symbol *ifc = c->ts.interface;
- bool success = true;
+ if (!sym->attr.vtype
+ && !check_proc_interface (ifc, &c->loc))
+return false;
- for ( ; c != NULL; c = c->next)
+ if (ifc->attr.if_source || ifc->attr.intrinsic)
+{
+ /* Resolve interface and copy attributes. */
+ if (ifc->formal && !ifc->formal_ns)
+resolve_symbol (ifc);
+ if (ifc->attr.intrinsic)
+gfc_resolve_intrinsic (ifc, &ifc->declared_at);
+
+ if (ifc->result)
+{
+ c->ts = ifc->result->ts;
+ c->attr.allocatable = ifc->result->attr.allocatable;
+ c->attr.pointer = ifc->result->attr.pointer;
+ c->attr.dimension = ifc->result->attr.dimension;
+ c->as = gfc_copy_array_spec (ifc->result->as);
+ c->attr.class_ok = ifc->result->attr.class_ok;
+}
+ else
+{
+
RE: Fwd: DEC Extension Patches: Structure, Union, and Map
Please see the original thread
https://gcc.gnu.org/ml/fortran/2016-03/msg2.html.
I have to send the patches separately, as together they cause me to be
blocked for spamming. This is patch 3:
---
Fritz Reese
From 93e96b8a9e62c0413e6d9d33c01fa7825ecd9ee4 Mon Sep 17 00:00:00 2001
From: Fritz O. Reese
Date: Thu, 13 Nov 2014 14:41:04 -0500
Subject: [PATCH 3/4] 2014-11-13 Fritz Reese
gcc/fortran/
* parse.c (check_component): New function.
(parse_derived): Move loop code to check_component.
---
gcc/fortran/parse.c | 343 +++
1 files changed, 179 insertions(+), 164 deletions(-)
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 7bce47f..1374c13 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -2646,6 +2646,184 @@ error:
}
+/* Set attributes for the parent symbol based on the attributes of a component
+ and raise errors if conflicting attributes are found for the component. */
+
+static void
+check_component (gfc_symbol *sym, gfc_component *c, gfc_component **lockp,
+gfc_component **eventp)
+{
+ bool coarray, lock_type, event_type, allocatable, pointer;
+ coarray = lock_type = event_type = allocatable = pointer = false;
+ gfc_component *lock_comp, *event_comp;
+
+ lock_comp = *lockp;
+ event_comp = *eventp;
+
+ /* Look for allocatable components. */
+ if (c->attr.allocatable
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->attr.allocatable)
+ || (c->ts.type == BT_DERIVED && !c->attr.pointer
+ && c->ts.u.derived->attr.alloc_comp))
+{
+ allocatable = true;
+ sym->attr.alloc_comp = 1;
+}
+
+ /* Look for pointer components. */
+ if (c->attr.pointer
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->attr.class_pointer)
+ || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.pointer_comp))
+{
+ pointer = true;
+ sym->attr.pointer_comp = 1;
+}
+
+ /* Look for procedure pointer components. */
+ if (c->attr.proc_pointer
+ || (c->ts.type == BT_DERIVED
+ && c->ts.u.derived->attr.proc_pointer_comp))
+sym->attr.proc_pointer_comp = 1;
+
+ /* Looking for coarray components. */
+ if (c->attr.codimension
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->attr.codimension))
+{
+ coarray = true;
+ sym->attr.coarray_comp = 1;
+}
+
+ if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.coarray_comp
+ && !c->attr.pointer)
+{
+ coarray = true;
+ sym->attr.coarray_comp = 1;
+}
+
+ /* Looking for lock_type components. */
+ if ((c->ts.type == BT_DERIVED
+ && c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
+ && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE)
+ || (c->ts.type == BT_CLASS && c->attr.class_ok
+ && CLASS_DATA (c)->ts.u.derived->from_intmod
+ == INTMOD_ISO_FORTRAN_ENV
+ && CLASS_DATA (c)->ts.u.derived->intmod_sym_id
+ == ISOFORTRAN_LOCK_TYPE)
+ || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.lock_comp
+ && !allocatable && !pointer))
+{
+ lock_type = 1;
+ lock_comp = c;
+ sym->attr.lock_comp = 1;
+}
+
+/* Looking for event_type components. */
+if ((c->ts.type == BT_DERIVED
+&& c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
+&& c->ts.u.derived->intmod_sym_id == ISOFORTRAN_EVENT_TYPE)
+|| (c->ts.type == BT_CLASS && c->attr.class_ok
+&& CLASS_DATA (c)->ts.u.derived->from_intmod
+ == INTMOD_ISO_FORTRAN_ENV
+&& CLASS_DATA (c)->ts.u.derived->intmod_sym_id
+ == ISOFORTRAN_EVENT_TYPE)
+|| (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.event_comp
+&& !allocatable && !pointer))
+ {
+event_type = 1;
+event_comp = c;
+sym->attr.event_comp = 1;
+ }
+
+ /* Check for F2008, C1302 - and recall that pointers may not be coarrays
+ (5.3.14) and that subobjects of coarray are coarray themselves (2.4.7),
+ unless there are nondirect [allocatable or pointer] components
+ involved (cf. 1.3.33.1 and 1.3.33.3). */
+
+ if (pointer && !coarray && lock_type)
+gfc_error ("Component %s at %L of type LOCK_TYPE must have a "
+ "codimension or be a subcomponent of a coarray, "
+ "which is not possible as the component has the "
+ "poin
RE: Fwd: DEC Extension Patches: Structure, Union, and Map
Please see the original thread https://gcc.gnu.org/ml/fortran/2016-03/msg2.html. I have to send the patches separately, as together they cause me to be blocked for spamming. This is the big one, patch 4. It is compressed with gzip since it is 150KB uncompressed. --- Fritz Reese 0004-2016-03-01-Fritz-Reese-fritzoreese-gmail.com.patch.gz Description: GNU Zip compressed data
[Patch, fortran] Initializing components of derived type variables
Greetings, Here I propose a patch to gfortran which allows initializing components of derived type variables with a new compile flag. Currently the options -finit-integer=, -finit-real=, -finit-logical=, and -finit-character= are avaialable to initialize variables of each respective type; however, there is no way (other than explicitly in source) to initialize derived type variables. In this patch I add the flag -finit-derived. This flag allows components of derived type variables to be initialized as with local variables. This flag obeys the values given to the other -finit-*= flags; with -finit-local-zero derived type variables are initialized to zero. The brunt of the work happens in expr.c (gfc_default_initializer). I add a boolean parameter to gfc_default_initializer which indicates whether or not to generate initializers for components that do not already have them. If true, an expression is generated for each component which does not already have an explicit initializer. This parameter is passed potentially as true in two places in resolve.c (apply_default_init and resolve_fl_variable_derived). Generation is guarded by can_create_initializer, which ensures similar conditions as in resolve.c (build_default_init_expr). To do the generation, gfc_default_initializer calls upon a new function component_init in expr.c. In order to use the -finit-* flags this calls upon the behavior formerly implemented in resolve.c (build_default_init_expr); I moved this behavior to the public function gfc_build_default_init_expr in expr.c; build_default_init_expr in resolve.c now simply wraps this function to protect it from being called on invalid symbols. I wrestled with whether to change the interface for gfc_default_initializer or create an entirely new function (like gfc_generate_derived_initializer). I decided to change the old function because their behaviors would be almost identical, and there are only a few calls to the former. The patch is based on trunk. It builds and passes all regression tests on x86-64-gnu-linux. --- Fritz Reese From c116c13e03b61deefd41ad548b019af467e91506 Mon Sep 17 00:00:00 2001 From: Fritz O. Reese Date: Fri, 17 Oct 2014 15:46:05 -0400 Subject: [PATCH] 2016-03-02 Fritz Reese gcc/fortran/ * lang.opt, invoke.texi, options.c: New option -finit-derived. * gfortran.h (gfc_option): New option -finit-derived. (gfc_default_initializer): Update prototype. (gfc_build_default_init_expr, gfc_apply_init): New prototypes. * expr.c (gfc_build_default_init_expr, gfc_apply_init, component_initializer): New functions. (gfc_default_initializer): Allow generation of initializers. * decl.c (build_struct): Use new function gfc_apply_init. (variable_decl): Use new interface for gfc_default_initializer. (gfc_match_derived_decl): Likewise. * trans-openmp.c (gfc_trans_omp_array_reduction_or_udr): Likewise. * trans-decl.c (gfc_generate_function_code): Likewise. * class.c (gfc_find_derived_vtab, find_intrinsic_vtab): Likewise. * resolve.c (resolve_allocate_expr): Likewise. (build_default_init_expr): Use new function gfc_build_default_init_expr. (can_generate_init): New function. (apply_default_init, resolve_fl_variable_derived): Use gfc_default_initializer to generate initializers. gcc/testsuite/gfortran.dg/ * assert.inc: Runtime assertions. * init_flag_13.f90, init_flag_14.f90: New testcases for -finit-derived. --- gcc/fortran/class.c|7 +- gcc/fortran/decl.c | 50 +- gcc/fortran/expr.c | 267 ++-- gcc/fortran/gfortran.h |6 +- gcc/fortran/invoke.texi|9 +- gcc/fortran/lang.opt |4 + gcc/fortran/options.c |5 + gcc/fortran/resolve.c | 194 + gcc/fortran/trans-decl.c |3 +- gcc/fortran/trans-openmp.c |2 +- gcc/testsuite/gfortran.dg/assert.inc | 62 +++ gcc/testsuite/gfortran.dg/init_flag_13.f90 | 36 gcc/testsuite/gfortran.dg/init_flag_14.f90 | 36 13 files changed, 460 insertions(+), 221 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/assert.inc create mode 100644 gcc/testsuite/gfortran.dg/init_flag_13.f90 create mode 100644 gcc/testsuite/gfortran.dg/init_flag_14.f90 diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 6a7339f..cfcf4f6 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -2325,7 +2325,8 @@ gfc_find_derived_vtab (gfc_symbol *derived) gfc_set_sym_referenced (def_init); def_init->ts.type = BT_DERIVED; def_init->ts.u.derived = derived; - def_init->value = gfc_default_initializer (&def_init->ts); + def_init->value = gfc_default_initializer (&def_init->ts, + false); c->initializer = gfc_lval_expr_from_sy
Re: PATCH -- Fix degree trignometric functions
On Sat, Mar 7, 2020 at 1:32 PM Steve Kargl wrote: > > Fix the simplification and handling of the degree trigonometric functions. > This includes fixing a number of ICEs. See PR 93871. > > ChangeLog and patch attached. As the author of the original degree-trig functions I intend to review this patch soon, and... > On Fri, Mar 06, 2020 at 03:18:19PM -0800, Steve Kargl wrote: > > > > 3. Simplification routines do the following mappings: > > sind(x) = sin((pi/180) * x) asind(x) = (180/pi) * asin(x) > > cosd(x) = cos((pi/180) * x) acosd(x) = (180/pi) * acos(x) > > tand(x) = tan((pi/180) * x) atand(x) = (180/pi) * atan(x) > > atan2d(y,x) = (180/pi) * atan2(y,x) > > cotand(x) = cotan((pi/180) * x) > > All computations are carried out by MPFR or MPC. > > In looking at some basic tests, the above simplification will > need to be modified to do what ... > > > > 5. New functions have been added to libgfortran to handle sind, cosd, > > and tand. > > ... these functions do. Otherwise, things like cos(real(60+123*360)) > give wrong values. Modifications are so easy even a lurker can do > them. ... extend the patch to include these changes (unless someone enthusiastic gets around to these mods before I do). I should be able to start on this next week (around 16 March). --- Fritz Reese
Re: [PATCH] Use getentropy() for seeding PRNG
On Fri, Aug 3, 2018 at 9:19 AM Janne Blomqvist wrote: > > The getentropy function, found on Linux, OpenBSD, and recently also > FreeBSD, can be used to get random bytes to initialize the PRNG. It > is similar to the traditional way of reading from /dev/urandom, but > being a system call rather than a special file, it doesn't suffer from > problems like running out of file descriptors, or failure when running > in a container where /dev/urandom is not available. > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? Actually, getentropy() is similar to reading from /dev/random, where getrandom() is similar to reading from /dev/urandom. Since the original behavior of getosrandom() is to read from /dev/urandom, I think it is better to use getrandom() for consistent semantics. Furthermore, getentropy() may block to achieve an appropriate degree of randomness, since it is intended for secure use. Of course such block time would hardly be noticeable for a one-time read of a thousand bits or so... but on principle I think we should provide a quick cheesy seed by default, and the user may provide his own seed if he wants expensive secure bits. Just my opinion. I am personally OK with the [second version of the] patch | sed s/getentropy/getrandom/g. Fritz
Re: [PATCH] Use getentropy() for seeding PRNG
On Mon, Aug 13, 2018 at 4:12 PM Janne Blomqvist wrote: > > On Mon, Aug 13, 2018 at 5:36 PM, Fritz Reese wrote: >> >> On Fri, Aug 3, 2018 at 9:19 AM Janne Blomqvist >> wrote: >> > >> > The getentropy function, found on Linux, OpenBSD, and recently also >> > FreeBSD, can be used to get random bytes to initialize the PRNG. It >> > is similar to the traditional way of reading from /dev/urandom, but >> > being a system call rather than a special file, it doesn't suffer from >> > problems like running out of file descriptors, or failure when running >> > in a container where /dev/urandom is not available. >> > >> > Regtested on x86_64-pc-linux-gnu, Ok for trunk? >> >> Actually, getentropy() is similar to reading from /dev/random, where >> getrandom() is similar to reading from /dev/urandom. > > > No, getentropy is similar to getrandom with the flags argument == 0. Which is > similar to reading /dev/urandom, except that just after boot if enough > entropy hasn't yet been gathered, it may block instead of returning some > not-quite-random data. But once it has been initialized, it will never block > again. > > I agree that reading from /dev/random is overkill, but this patch isn't doing > the equivalent of that. > Fair enough, I misread the documentation on getentropy(). Then I concur with Jakub, patch looks OK. Fritz
Re: [Patch, Fortran] PR 86116: Ambiguous generic interface not recognised
Looks OK to me.
On Tue, Aug 14, 2018 at 4:12 AM Janus Weil wrote:
>
> ping!
>
>
> Am So., 5. Aug. 2018 um 15:23 Uhr schrieb Janus Weil :
> >
> > Hi all,
> >
> > the attached patch fixes PR 86116 by splitting up the function
> > 'compare_type' into two variants: One that is used for checking
> > generic interfaces and operators (keeping the old name), and one that
> > is used for checking dummy functions and procedure pointer assignments
> > ('compare_type_characteristics'). The latter calls the former, but
> > includes an additional check that must not be done when checking
> > generics.
> >
> > Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
> >
> > Cheers,
> > Janus
> >
> >
> > 2018-08-05 Janus Weil
> >
> > PR fortran/86116
> > * interface.c (compare_type): Remove a CLASS/TYPE check.
> > (compare_type_characteristics): New function that behaves like the old
> > 'compare_type'.
> > (gfc_check_dummy_characteristics, gfc_check_result_characteristics):
> > Call 'compare_type_characteristics' instead of 'compare_type'.
> >
> > 2018-08-05 Janus Weil
> >
> > PR fortran/86116
> > * gfortran.dg/generic_34.f90: New test case.
[PATCH, Fortran] Fix PR 82886 - ICE with -finit-derived in gfc_conv_expr
All, The attached patch fixes the ICE reported in PR 82886. The ICE is due to compiling the program with -finit-derived, but without any other -finit-* flag (apparently this is something which I never tried when I introduced -finit-derived, somehow...) Previously, -finit-derived would inherit the component initializer expressions from flags like -finit-local-zero, -finit-integer=, -finit-logical=, etc... The problem is, if one is not specified and a derived type variable contains a component of the same type, the structure constructor itself is generated, but the structure element for the component ends up with a NULL expression. The attached patch implements what I think is a natural solution from the user's perspective. If -finit-derived is given, any -finit-* flags which are not given will be treated as if -finit-local-zero was given, for the purposes of the derived-type component initializers. (Of course explicit -finit-* flags will still override this inference). Regression tests pass on x86_64-redhat-linux. OK? --- Fritz Reese >From e70f3917a7b2d35f9baad2f09199c1ccc60a04d4 Mon Sep 17 00:00:00 2001 From: Fritz Reese Date: Fri, 10 Nov 2017 16:10:06 -0500 Subject: [PATCH] Fix -finit-derived when given without other -finit-* flags. PR fortran/82886 gcc/fortran/ * gfortran.h (gfc_build_init_expr): New prototype. * invoke.texi (finit-derived): Update documentation. * expr.c (gfc_build_init_expr): New, from gfc_build_default_init_expr. (gfc_build_default_init_expr): Redirect to gfc_build_init_expr(,,false) (component_initializer): Force building initializers using gfc_build_init_expr(,,true). PR fortran/82886 * gcc/testsuite/gfortran.dg/init_flag_16.f03: New testcase. pr82886.patch Description: Binary data
Re: [PATCH, Fortran] Fix PR 82886 - ICE with -finit-derived in gfc_conv_expr
My mistake, the patch file should not have the random changes to libiberty/functions.texi. Not sure how that ended up there. --- Fritz Reese On Fri, Nov 10, 2017 at 4:31 PM, Fritz Reese wrote: > All, > > The attached patch fixes the ICE reported in PR 82886. The ICE is due > to compiling the program with -finit-derived, but without any other > -finit-* flag (apparently this is something which I never tried when I > introduced -finit-derived, somehow...) Previously, -finit-derived > would inherit the component initializer expressions from flags like > -finit-local-zero, -finit-integer=, -finit-logical=, etc... The > problem is, if one is not specified and a derived type variable > contains a component of the same type, the structure constructor > itself is generated, but the structure element for the component ends > up with a NULL expression. > > The attached patch implements what I think is a natural solution from > the user's perspective. If -finit-derived is given, any -finit-* flags > which are not given will be treated as if -finit-local-zero was given, > for the purposes of the derived-type component initializers. (Of > course explicit -finit-* flags will still override this inference). > > Regression tests pass on x86_64-redhat-linux. OK? > > --- > Fritz Reese > > From e70f3917a7b2d35f9baad2f09199c1ccc60a04d4 Mon Sep 17 00:00:00 2001 > From: Fritz Reese > Date: Fri, 10 Nov 2017 16:10:06 -0500 > Subject: [PATCH] Fix -finit-derived when given without other -finit-* flags. > > PR fortran/82886 > gcc/fortran/ > * gfortran.h (gfc_build_init_expr): New prototype. > * invoke.texi (finit-derived): Update documentation. > * expr.c (gfc_build_init_expr): New, from gfc_build_default_init_expr. > (gfc_build_default_init_expr): Redirect to > gfc_build_init_expr(,,false) > (component_initializer): Force building initializers using > gfc_build_init_expr(,,true). > > PR fortran/82886 > * gcc/testsuite/gfortran.dg/init_flag_16.f03: New testcase. pr82886.patch Description: Binary data
Re: [PATCH, Fortran] Fix PR 82886 - ICE with -finit-derived in gfc_conv_expr
On Fri, Nov 10, 2017 at 6:40 PM, Steve Kargl wrote: > On Fri, Nov 10, 2017 at 04:35:56PM -0500, Fritz Reese wrote: >> My mistake, the patch file should not have the random changes to >> libiberty/functions.texi. Not sure how that ended up there. >> > >> > PR fortran/82886 >> > gcc/fortran/ >> > * gfortran.h (gfc_build_init_expr): New prototype. >> > * invoke.texi (finit-derived): Update documentation. >> > * expr.c (gfc_build_init_expr): New, from >> > gfc_build_default_init_expr. >> > (gfc_build_default_init_expr): Redirect to >> > gfc_build_init_expr(,,false) >> > (component_initializer): Force building initializers using >> > gfc_build_init_expr(,,true). >> > >> > PR fortran/82886 >> > * gcc/testsuite/gfortran.dg/init_flag_16.f03: New testcase. > > Patch looks good to me. Thanks for the patch. Thanks, committed as r254648. > PS: can you look at the patch I posted yesterday about a kludge. > I will look into it. Please hold off on committing until I get a chance to review if it is not urgent - I think some better handling can be done there. --- Fritz Reese
Re: [PATCH] PR fortran/78240 -- kludge of the day
On Thu, Nov 9, 2017 at 5:02 PM, Steve Kargl
wrote:
> The following patch fixes PR fortran/78240. It seems
> to me to be inelegant, but it does pass regression
> testing. [...] OK to commit?
Upon closer analysis, the patch is insufficient to fix the PR. I will
explain below. At the bottom of this letter I explain and have
attached a new patch which fixes some more subtle issues in the code
which causes the PR.
> [...] The second part in resolve.c is needed
> to avoid a NULL pointer dereference when one forgets
> to use -fdec with Gerhard's code.
[...]
> --- gcc/fortran/resolve.c (revision 254603)
> +++ gcc/fortran/resolve.c (working copy)
> @@ -15284,7 +15290,7 @@ check_data_variable (gfc_data_variable *var, locus *wh
>if (!gfc_array_size (e, &size))
> {
> gfc_error ("Nonconstant array section at %L in DATA statement",
> -&e->where);
> +where);
> mpz_clear (offset);
> return false;
> }
This portion of the patch is correct and fixes one of the issues.
> [...] The kludgy portion occurs in decl.c.
> march_clist_expr is clearly expecting an array with
> constant dimension due to gcc_assert. When -fdec
> is used and one takes Gerhard code (see testcase),
> the assertion is raised. The patch checks for
> -fdec and failure of spec_size(), and then goes
> to cleanup.
[...]
> --- gcc/fortran/decl.c (revision 254603)
> +++ gcc/fortran/decl.c (working copy)
> @@ -735,6 +735,8 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts,
>
>/* Validate sizes. */
>gcc_assert (gfc_array_size (expr, &size));
> + if (flag_dec && !spec_size (as, &repeat))
> + goto cleanup;
>gcc_assert (spec_size (as, &repeat));
>cmp = mpz_cmp (size, repeat);
>if (cmp < 0)
This portion of the patch is insufficient. By removing the assert on
spec_size, the remaining code improperly handles the memory of the two
mpz_integer variables 'size' and 'repeat'. Since gfc_array_size() and
spec_size() both allocate their mpz_integer* arguments,
match_clist_expr() should not allocate them (or clear them on error).
With the original patch, memory corruption occurs in several ways
(double-alloc of repeat in gfc_array_size, double-free of size on
failure of spec_size). Strange that regression testing did not reveal
the memory corruption (I see the corruptions in my own gcc after
manually applying the patch, at least).
I have attached a patch which better handles false return from
spec_size, which occurs when the array-spec for the variable being
initialized is not constant. Proper handling requires careful
management of the two mpz_integer size variables used in
gfc_array_size and spec_size. The patch also includes the fix in
resolve.c.
Thanks for pointing me to this issue and allowing me time to review
it. The new patch passes all regression tests including its two tests
(one for each issue above). OK to commit this one?
---
Fritz Reese
>From f2b8262a1a366b072493b129d38465ffa3d265bc Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 13 Nov 2017 15:58:26 -0500
Subject: [PATCH] Fix ICE on non-constant array-specs in clist initializers.
PR fortran/78240
gcc/fortran/
* decl.c (match_clist_expr): Replace gcc_assert with proper
handling of bad result from spec_size().
* resolve.c (check_data_variable): Avoid NULL dereference when passing
locus to gfc_error.
PR fortran/78240
* gcc/testsuite/gfortran.dg/dec_structure_23.f90: New.
* gcc/testsuite/gfortran.dg/pr78240.f90: New.
---
gcc/fortran/decl.c | 37 +-
gcc/fortran/resolve.c | 2 +-
gcc/testsuite/gfortran.dg/dec_structure_23.f90 | 19 +
gcc/testsuite/gfortran.dg/pr78240.f90 | 12 +
4 files changed, 56 insertions(+), 14 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_23.f90
create mode 100644 gcc/testsuite/gfortran.dg/pr78240.f90
pr78240.patch
Description: Binary data
Re: [PATCH] PR fortran/78240 -- kludge of the day
On Tue, Nov 14, 2017 at 4:58 PM, Janus Weil wrote:
> Hi guys,
>
> I see this new test case failing on x86_64-linux-gnu:
>
> FAIL: gfortran.dg/pr78240.f90 -O (test for excess errors)
>
>
> $ gfortran-8 pr78240.f90
> pr78240.f90:11:12:
>
>integer x(n)/1/ ! { dg-error "Nonconstant array" }
> 1
> Error: Variable ‘n’ cannot appear in the expression at (1)
> pr78240.f90:11:14:
>
>integer x(n)/1/ ! { dg-error "Nonconstant array" }
> 1
> Error: The module or main program array ‘x’ at (1) must have constant shape
> pr78240.f90:11:19:
>
>integer x(n)/1/ ! { dg-error "Nonconstant array" }
>1
> Error: Nonconstant array section at (1) in DATA statement
> [...]
... does anyone know how to tell dejagnu to expect multiple errors on
a single line?
---
Fritz Reese
Re: [PATCH] PR fortran/78240 -- kludge of the day
On Wed, Nov 15, 2017 at 1:13 PM, Steve Kargl
wrote:
> On Tue, Nov 14, 2017 at 05:21:41PM -0500, Fritz Reese wrote:
>> On Tue, Nov 14, 2017 at 4:58 PM, Janus Weil wrote:
>> > Hi guys,
>> >
>> > I see this new test case failing on x86_64-linux-gnu:
>> >
>> > FAIL: gfortran.dg/pr78240.f90 -O (test for excess errors)
...
>>
>
> I've fixed the problem with this patch.
>
> 2017-11-15 Steven G. Kargl
>
> PR fortran/78240
> gfortran.dg/pr78240.f90: Prune run-on errors.
>
>
> Index: gcc/testsuite/gfortran.dg/pr78240.f90
> ===
> --- gcc/testsuite/gfortran.dg/pr78240.f90 (revision 254779)
> +++ gcc/testsuite/gfortran.dg/pr78240.f90 (working copy)
> @@ -1,4 +1,5 @@
> ! { dg-do compile }
> +! { dg-options "-w" }
> !
> ! PR fortran/78240
> !
> @@ -8,5 +9,7 @@
> !
>
> program p
> - integer x(n)/1/ ! { dg-error "Nonconstant array" }
> + integer x(n)/1/ ! { dg-error "cannot appear in the expression" }
> end
> +! { dg-prune-output "module or main program" }
> +! { dg-prune-output "Nonconstant array" }
>
> --
> Steve
Thanks! I was planning to commit the very same.
---
Fritz Reese
[PRs fortran/82972, fortran/83088, fortran/85851] Fix ICE with -finit-derived when using iso_c_binding
All, The attached patch generates special initializers for derived-type c_ptr and c_funptr symbols so they are handled correctly by the translation phase. Previously, an EXPR_STRUCTURE expression was generated for both types, as c_ptr and c_funptr are structure types with a c_address field. The c_address field never had its backend_decl generated, because it is typically handled specially. With the patch, the trunk compiler does not exhibit the bugs in the mentioned PRs (82972, 83088, 85851). I did encounter some issues building and regression testing the trunk compiler which I am certain are unrelated. The current trunk fails to bootstrap for me so I am using an older revision which appears to have some testcase issues. The issues are attached at the bottom of this e-mail for reference. In any case, the changelog is here, and the patch is attached. Aside from the issues mentioned below the compile bootstraps and regression tests successfully. Does this look OK for trunk? Furthermore, this patch comes a bit late as the PRs were submitted before 8.1 was released; is it appropriate to backport this to 7-branch and/or 8-branch? >From b6fbe8e429d5c98675741234e2ac5cc6810df3c5 Mon Sep 17 00:00:00 2001 From: Fritz Reese Date: Fri, 22 Jun 2018 16:11:02 -0400 Subject: [PATCH] PR fortran/82972 Fix -finit-derived for c_ptr and c_funptr in programs which use iso_c_binding. gcc/fortran/ * expr.c (component_initializer): Assign init expr to c->initializer. (generate_isocbinding_initializer): New. (gfc_generate_initializer): Call generate_isocbinding_initializer to generate initializers for c_ptr and c_funptr with -finit-derived. gcc/testsuite/ * gfortran.dg/init_flag_17.f90: New testcase. --- gcc/fortran/expr.c | 33 +- gcc/testsuite/gfortran.dg/init_flag_17.f90 | 28 + 2 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gfortran.dg/init_flag_17.f90 === TEST ISSUES === $ gfortran --version GNU Fortran (GCC) 8.0.0 20180110 (experimental) ... $ make -sk check-fortran ... FAIL: gfortran.dg/pr68078.f90 -O0 execution test FAIL: gfortran.fortran-torture/compile/pr83081.f90, -O3 -g (internal compiler error) ... In the first case (pr68078) the process appears to occasionally run out of stack memory due to the setrlimit(), causing it to receive SIGSEGV. $ cd gcc/testsuite/gfortran.dg $ gfortran pr68078.f90 set_vm_limit.c -o pr68078 $ i=0; time while ./a.out >/dev/null; do echo attempt $i; i=$(($i+1)) ; done attempt 0 attempt 1 attempt 2 attempt 3 attempt 4 attempt 5 attempt 6 attempt 7 attempt 8 attempt 9 attempt 10 Segmentation fault (core dumped) real0m0.104s user0m0.007s sys0m0.023s The second case appears positively unrelated (and only occurs with -O3): $ gfortran -c -O3 pr83081.f90 during GIMPLE pass: pcom pr83081.f90:4:0: Subroutine SPLIFT (X,Y,YP,YPP,N,IERR,ISX,A1,B1,AN,BN) internal compiler error: in probability_in, at profile-count.h:1038 0x6f47ee profile_count::probability_in(profile_count) const /data/midas/foreese/src/gcc-trunk/gcc/profile-count.h:1038 0x6f47ee tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*, tree_niter_desc*, void (*)(loop*, void*), void*) /data/midas/foreese/src/gcc-trunk/gcc/tree-ssa-loop-manip.c:1382 0xe36716 tree_predictive_commoning_loop /data/midas/foreese/src/gcc-trunk/gcc/tree-predcom.c:3278 0xe37e7d tree_predictive_commoning() /data/midas/foreese/src/gcc-trunk/gcc/tree-predcom.c:3312 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. === END TEST ISSUES === From b6fbe8e429d5c98675741234e2ac5cc6810df3c5 Mon Sep 17 00:00:00 2001 From: Fritz Reese Date: Fri, 22 Jun 2018 16:11:02 -0400 Subject: [PATCH] PR fortran/82972 Fix -finit-derived for c_ptr and c_funptr in programs which use iso_c_binding. gcc/fortran/ * expr.c (component_initializer): Assign init expr to c->initializer. (generate_isocbinding_initializer): New. (gfc_generate_initializer): Call generate_isocbinding_initializer to generate initializers for c_ptr and c_funptr with -finit-derived. gcc/testsuite/ * gfortran.dg/init_flag_17.f90: New testcase. --- gcc/fortran/expr.c | 33 +- gcc/testsuite/gfortran.dg/init_flag_17.f90 | 28 + 2 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gfortran.dg/init_flag_17.f90 diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index 45ccc184fc1..ad549911cd1 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4476,7 +4476,7 @@ component_initializer (gfc_typespec *ts, gfc_component *c, bool generate) gfc_apply_init (&c->ts, &c->attr, init); } - return init; + return (c->initializer
Re: [PRs fortran/82972, fortran/83088, fortran/85851] Fix ICE with -finit-derived when using iso_c_binding
Thanks for the review. I will commit tomorrow.
---
Fritz Reese
On Sat, Jun 23, 2018 at 11:57 AM, Steve Kargl
wrote:
> On Fri, Jun 22, 2018 at 04:46:19PM -0400, Fritz Reese wrote:
>>
>> In any case, the changelog is here, and the patch is attached. Aside
>> from the issues mentioned below the compile bootstraps and regression
>> tests successfully. Does this look OK for trunk? Furthermore, this
>> patch comes a bit late as the PRs were submitted before 8.1 was
>> released; is it appropriate to backport this to 7-branch and/or
>> 8-branch?
>
> OK with minor style fixes (see below). Note, I cannot reproduce
> the issues that you saw. Please keep an eye on the list for a
> regression.
>
>> +/* Generate an initializer expression for an iso_c_binding type
>> + such as c_[fun]ptr. The appropriate initializer is c_null_[fun]ptr. */
>> +
>> +static gfc_expr *
>> +generate_isocbinding_initializer (gfc_symbol *derived)
>> +{
>> + /* The initializers have already been built into the c_null_[fun]ptr
>> symbols
>> + from gen_special_c_interop_ptr. */
>> +
>> + gfc_symtree *npsym = NULL;
>> + if (0 == strcmp(derived->name, "c_ptr"))
>
> Missing space. strcmp ()
>
>> +gfc_find_sym_tree("c_null_ptr", gfc_current_ns, true, &npsym);
>
> same here
>
>> + else if (0 == strcmp(derived->name, "c_funptr"))
>
> same here
>
>> +gfc_find_sym_tree("c_null_funptr", gfc_current_ns, true, &npsym);
>
> same here
>
>> + else
>> +gfc_internal_error ("generate_isocbinding_initializer(): bad
>> iso_c_binding"
>> + " type, expected % or %");
>> + if (npsym)
>> +{
>> + gfc_expr *init = gfc_copy_expr(npsym->n.sym->value);
>
> same here
>
>> + init->symtree = npsym;
>> + init->ts.is_iso_c = true;
>> + return init;
>> +}
>> +
>> + return NULL;
>> +}
>>
>> /* Get or generate an expression for a default initializer of a derived
>> type.
>> If -finit-derived is specified, generate default initialization
>> expressions
>> @@ -4498,8 +4525,12 @@ gfc_generate_initializer (gfc_typespec *ts, bool
>> generate)
>> {
>>gfc_expr *init, *tmp;
>>gfc_component *comp;
>> +
>>generate = flag_init_derived && generate;
>>
>> + if (ts->u.derived->ts.is_iso_c && generate)
>> +return generate_isocbinding_initializer(ts->u.derived);
>
> same here
>
> --
> Steve
[PR Fortran/83183] Fix infinite recursion (ICE) with -finit-derived when initializing allocatable BT_DERIVED components
All,
The attached patch fixes PR 83183. Previously, attempting to generate
initializers for allocatable components of the same derived type
triggered infinite recursion. Passes regression tests. OK for trunk
and gcc-8-branch?
>From 01961cc78b8ecd5272521098ae3166516a49dcd1 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH] PR fortran/83183
Fix infinite recursion occurring with -finit-derived generating initializers
for allocatable derived-type components.
gcc/fortran/
* expr.c (component_initializer): Do not generate initializers with
allocatable BT_DERIVED components.
---
gcc/fortran/expr.c | 1 +
gcc/testsuite/gfortran.dg/init_flag_18.f90 | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/init_flag_18.f90
From 01961cc78b8ecd5272521098ae3166516a49dcd1 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH] PR fortran/83183
Fix infinite recursion occurring with -finit-derived generating initializers
for allocatable derived-type components.
gcc/fortran/
* expr.c (component_initializer): Do not generate initializers with
allocatable BT_DERIVED components.
---
gcc/fortran/expr.c | 1 +
gcc/testsuite/gfortran.dg/init_flag_18.f90 | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/init_flag_18.f90
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 5103a5cc990..468f45ec488 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4422,6 +4422,7 @@ component_initializer (gfc_typespec *ts, gfc_component *c, bool generate)
Some components should never get initializers. */
if (c->initializer || !generate
|| (ts->type == BT_CLASS && !c->attr.allocatable)
+ || (ts->type == BT_DERIVED && c->attr.allocatable)
|| c->attr.pointer
|| c->attr.class_pointer
|| c->attr.proc_pointer)
diff --git a/gcc/testsuite/gfortran.dg/init_flag_18.f90 b/gcc/testsuite/gfortran.dg/init_flag_18.f90
new file mode 100644
index 000..9ab00a9afce
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/init_flag_18.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-finit-derived" }
+!
+! PR fortran/83183
+!
+! Test a regression where -finit-derived recursed infinitely generating
+! initializers for allocatable components of the same derived type.
+!
+
+program pr83183
+ type :: linked_list
+ type(linked_list), allocatable :: link
+ integer :: value
+ end type
+ type(linked_list) :: test
+ allocate(test % link)
+ print *, test%value
+ print *, test%link%value
+end program
--
2.12.2
Re: [PR Fortran/83183] Fix infinite recursion (ICE) with -finit-derived when initializing allocatable BT_DERIVED components
On Mon, Jun 25, 2018 at 9:04 PM Steve Kargl
wrote:
> ... It does seem odd to me
> that BT_CLASS has !c->attr.allocatable and BT_DERIVED
> is c->attr.allocatable, i.e., bang vs no bang. Is this
> because class is not affected by -finit-derived?
>
I'm glad you raised the question. As a result I looked a little harder
at the condition -- it had always been somewhat of a mystery to me
actually, as I copied it from some old initializer code. I'll talk
about what I discovered here. For a tl;dr see the bottom for a new
patch.
There are a few subtleties involved. First, 'ts->type' refers to the
type of the structure containing the component, rather than the
component itself. For this reason my patch is actually incorrect. The
new condition should read:
- || (ts->type == BT_DERIVED && c->attr.allocatable)
+ || (c->ts.type == BT_DERIVED && c->attr.allocatable)
The BT_CLASS clause is to prevent generating initializers for
components within a BT_CLASS definition, because these components are
special (_hash, _size, _extends, _def_init, _copy, _final,
_deallocate, _data, _vptr). I believe it is true that the
c->attr.allocatable check is bogus along with c->ts.type == BT_CLASS.
The intent is likely to pass-through component_initializer() for the
special "_data" component, so that EXPR_NULL will be used in
gfc_generate_initializer() for the condition around line 4580:
> if (comp->attr.allocatable
> || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->attr.allocatable))
> {
I've found I could exploit these weak conditions by using a BT_CLASS
pointer component with -finit-derived. I've reported the issue in PR
86325. After taking a good hard look at the conditions involved, I've
learned the following rules, which were previously unenforced:
* with -finit-derived, allocatable and pointer components (including
BT_CLASS components with an allocatable or pointer _data component)
should initialize with EXPR_NULL
* even without -finit-derived, allocatable components (including
BT_CLASS components with an allocatable _data component) should be
initialized using EXPR_NULL
* special components of a BT_CLASS structure (named _*) should never
have an initializer generated by gfc_generate_initializer()
* gfc_component::initializer is for user-defined assignment
initializers and should never be set by gfc_generate_initializer()
I have thus simplified, implemented, and documented the conditions and
rules above. Vacuously this fixes PR 83183, since a component which
would invoke a recursive derived-type initializer generation must be
allocatable or a pointer; with the above rules, such components are
now assigned EXPR_NULL with -finit-derived which avoids the recursion.
Without -finit-derived, allocatable components are still generated an
EXPR_NULL expression, matching the compiler's original behavior. This
also fixes PR 86325 (mentioned above).
The patch is attached. OK for trunk and 7/8-branch?
>From e190d59153eaa7fbfcfabc93db31ddda0de3b869 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH 1/3] PR fortran/83183 PR fortran/86325
Fix allocatable/pointer conditions for -finit-derived.
gcc/fortran/
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into component_initializer().
gcc/testsuite/
* gfortran.dg/init_flag_19.f03: New testcase.
---
gcc/fortran/expr.c | 73 --
gcc/testsuite/gfortran.dg/init_flag_18.f90 | 19
gcc/testsuite/gfortran.dg/init_flag_19.f03 | 36 +++
3 files changed, 103 insertions(+), 25 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/init_flag_18.f90
create mode 100644 gcc/testsuite/gfortran.dg/init_flag_19.f03
From e190d59153eaa7fbfcfabc93db31ddda0de3b869 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 25 Jun 2018 17:51:00 -0400
Subject: [PATCH 1/3] PR fortran/83183 PR fortran/86325
Fix allocatable/pointer conditions for -finit-derived.
gcc/fortran/
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into component_initializer().
gcc/testsuite/
* gfortran.dg
[PR fortran/83184] Fix matching code for clist/old-style initializers when encountering assumed-rank declarations
The attached patch fixes PR fortran/83184, which is actually two
distinct bugs as described in the PR. Passes regtests.
The patch is attached. OK for trunk and 7/8-branch?
>From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 27 Jun 2018 16:16:31 -0400
Subject: [PATCH 2/3] PR fortran/83184
Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.
gcc/fortran/
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.
gcc/testsuite/
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.
---
gcc/fortran/decl.c | 63 +++---
gcc/testsuite/gfortran.dg/assumed_rank_14.f90 | 11 +
gcc/testsuite/gfortran.dg/assumed_rank_15.f90 | 11 +
gcc/testsuite/gfortran.dg/dec_structure_23.f90 | 6 +--
gcc/testsuite/gfortran.dg/dec_structure_8.f90 | 6 +--
5 files changed, 64 insertions(+), 33 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_14.f90
create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_15.f90
From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 27 Jun 2018 16:16:31 -0400
Subject: [PATCH 2/3] PR fortran/83184
Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.
gcc/fortran/
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.
gcc/testsuite/
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.
---
gcc/fortran/decl.c | 63 +++---
gcc/testsuite/gfortran.dg/assumed_rank_14.f90 | 11 +
gcc/testsuite/gfortran.dg/assumed_rank_15.f90 | 11 +
gcc/testsuite/gfortran.dg/dec_structure_23.f90 | 6 +--
gcc/testsuite/gfortran.dg/dec_structure_8.f90 | 6 +--
5 files changed, 64 insertions(+), 33 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_14.f90
create mode 100644 gcc/testsuite/gfortran.dg/assumed_rank_15.f90
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index cb235343962..af724658d8d 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -521,6 +521,7 @@ match_old_style_init (const char *name)
newdata = gfc_get_data ();
newdata->var = gfc_get_data_variable ();
newdata->var->expr = gfc_get_variable_expr (st);
+ newdata->var->expr->where = sym->declared_at;
newdata->where = gfc_current_locus;
/* Match initial value list. This also eats the terminal '/'. */
@@ -632,7 +633,7 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
{
gfc_constructor_base array_head = NULL;
gfc_expr *expr = NULL;
- match m;
+ match m = MATCH_ERROR;
locus where;
mpz_t repeat, cons_size, as_size;
bool scalar;
@@ -640,18 +641,27 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
gcc_assert (ts);
- mpz_init_set_ui (repeat, 0);
- scalar = !as || !as->rank;
-
/* We have already matched '/' - now look for a constant list, as with
top_val_list from decl.c, but append the result to an array. */
if (gfc_match ("/") == MATCH_YES)
{
gfc_error ("Empty old style initializer list at %C");
- goto cleanup;
+ return MATCH_ERROR;
}
where = gfc_current_locus;
+ scalar = !as || !as->rank;
+
+ if (!scalar && !spec_size (as, &as_size))
+{
+ gfc_error ("Array in initializer list at %L must have an explicit shape",
+ as->type == AS_EXPLICIT ? &as->upper[0]->where : &where);
+ /* Nothing to cleanup yet. */
+ return MATCH_ERROR;
+}
+
+ mpz_init_set_ui (repeat, 0);
+
for (;;)
{
m = match_data_constant (&expr);
@@ -681,7 +691,10 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
m = match_data_constant (&expr);
if (m == MATCH_NO)
-gfc_error ("Expected data constant after repeat spec at %C");
+ {
+ m = MATCH_ERROR;
+ gfc_error ("Expected data constant after repeat spec at %C");
+ }
if (m != MATCH_YES)
goto cleanup;
}
@@ -724,6 +737,9 @@ match_clist_expr (gfc_expr **result, gfc_typespec *ts, gfc_array_spec *as)
[PR fortran/82865] Fix PDT declarations being parsed as PRINT statements with -fdec
One extension enabled by -fdec is the ability to interpret TYPE
as a PRINT statement for compatibility purposes. When PDTs were
introduced, the code that handles -fde TYPE matching was not updated.
This patch fixes TYPE matching to no longer interpret as a PRINT statement when -fdec is asserted. Passes
regression tests as well.
The patch is attached. OK for trunk and 7/8-branch?
0dd08cefc2476014487b3eeab059784ab21bb41b Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 27 Jun 2018 15:43:45 -0400
Subject: [PATCH 3/3] PR fortran/82865
Do not override PDT declarations from gfc_match_type with -fdec.
gcc/fortran/
* decl.c (gfc_match_type): Refactor and check for PDT declarations.
gcc/testsuite/
* gfortran.dg/dec_type_print_2.f03: New testcase.
---
gcc/fortran/decl.c | 66 +-
gcc/testsuite/gfortran.dg/dec_type_print_2.f03 | 59 +++
2 files changed, 93 insertions(+), 32 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_type_print_2.f03
From 0dd08cefc2476014487b3eeab059784ab21bb41b Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 27 Jun 2018 15:43:45 -0400
Subject: [PATCH 3/3] PR fortran/82865
Do not override PDT declarations from gfc_match_type with -fdec.
gcc/fortran/
* decl.c (gfc_match_type): Refactor and check for PDT declarations.
gcc/testsuite/
* gfortran.dg/dec_type_print_2.f03: New testcase.
---
gcc/fortran/decl.c | 66 +-
gcc/testsuite/gfortran.dg/dec_type_print_2.f03 | 59 +++
2 files changed, 93 insertions(+), 32 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_type_print_2.f03
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index af724658d8d..ef59d1679ed 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -9607,9 +9607,9 @@ gfc_match_structure_decl (void)
/* This function does some work to determine which matcher should be used to
- * match a statement beginning with "TYPE". This is used to disambiguate TYPE
+ * match a statement beginning with "TYPE". This is used to disambiguate TYPE
* as an alias for PRINT from derived type declarations, TYPE IS statements,
- * and derived type data declarations. */
+ * and [parameterized] derived type declarations. */
match
gfc_match_type (gfc_statement *st)
@@ -9636,11 +9636,7 @@ gfc_match_type (gfc_statement *st)
/* If we see an attribute list before anything else it's definitely a derived
* type declaration. */
if (gfc_match (" ,") == MATCH_YES || gfc_match (" ::") == MATCH_YES)
-{
- gfc_current_locus = old_loc;
- *st = ST_DERIVED_DECL;
- return gfc_match_derived_decl ();
-}
+goto derived;
/* By now "TYPE" has already been matched. If we do not see a name, this may
* be something like "TYPE *" or "TYPE ". */
@@ -9655,29 +9651,11 @@ gfc_match_type (gfc_statement *st)
*st = ST_WRITE;
return MATCH_YES;
}
- gfc_current_locus = old_loc;
- *st = ST_DERIVED_DECL;
- return gfc_match_derived_decl ();
+ goto derived;
}
- /* A derived type declaration requires an EOS. Without it, assume print. */
- m = gfc_match_eos ();
- if (m == MATCH_NO)
-{
- /* Check manually for TYPE IS (... - this is invalid print syntax. */
- if (strncmp ("is", name, 3) == 0
- && gfc_match (" (", name) == MATCH_YES)
- {
- gfc_current_locus = old_loc;
- gcc_assert (gfc_match (" is") == MATCH_YES);
- *st = ST_TYPE_IS;
- return gfc_match_type_is ();
- }
- gfc_current_locus = old_loc;
- *st = ST_WRITE;
- return gfc_match_print ();
-}
- else
+ /* Check for EOS. */
+ if (gfc_match_eos () == MATCH_YES)
{
/* By now we have "TYPE ". Check first if the name is an
* intrinsic typename - if so let gfc_match_derived_decl dump an error.
@@ -9690,12 +9668,36 @@ gfc_match_type (gfc_statement *st)
*st = ST_DERIVED_DECL;
return m;
}
- gfc_current_locus = old_loc;
- *st = ST_WRITE;
- return gfc_match_print ();
}
+ else
+{
+ /* Here we have "TYPE ". Check for or a PDT declaration
+ like . */
+ gfc_gobble_whitespace ();
+ bool paren = gfc_peek_ascii_char () == '(';
+ if (paren)
+ {
+ if (strcmp ("is", name) == 0)
+ goto typeis;
+ else
+ goto derived;
+ }
+}
+
+ /* Treat TYPE... like PRINT... */
+ gfc_current_locus = old_loc;
+ *st = ST_WRITE;
+ return gfc_match_print ();
- return MATCH_NO;
+derived:
+ gfc_current_locus = old_loc;
+ *st = ST_DERIVED_DECL;
+ return gfc_match_derived_decl ();
+
+typeis:
+ gfc_current_locus = old_loc;
+ *st = ST_TYPE_IS;
+ return gfc_match_type_is ();
}
diff --git a/gcc/testsuite/gfortran.dg/dec_type_print_2.f03 b/gcc/testsuite/gfortran.dg/
Re: [PATCH, Fortran] -fno-automatic with -finit-local prevents initialization of automatics in recursive functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62309
It seems with gcc-4.8.3 -fno-automatic prevents initializers from
being applied to automatic variables. The following does not behave as
I would expect it to with gcc-4.8.3 on linux-x86-64:
function f (x)
implicit none
integer f, x
integer a ! should be SAVEd from -fno-automatic
a = a + x ! should increment by y every time
f = a
return
endfunction
recursive function g (x)
implicit none
integer g, x
integer b ! should be automatic from recursive
b = b + x ! should be set to y every time
g = b
return
endfunction
implicit none
integer f, g
! Should return static value of a; accumulates x
print *, f(3) ! -> 3, ok
print *, f(4) ! -> 7, ok
print *, f(2) ! -> 2, ok
! Should return automatic value of c; equal to y each time
print *, g(3) ! -> garbage, expected 3
print *, g(4) ! -> garbage, expected 4
print *, g(2) ! -> garbage, expected 2
end
$ gfortran -fno-automatic -finit-local-zero auto_test.f
$ ./a.out
3
7
9
32770
32771
32769
$
According to gfortran's manual page, -fno-automatic should "Treat each
program unit (except those marked as RECURSIVE) as if the "SAVE"
statement were specified for every local variable [...]". As far as I
can tell, -finit-local-zero should still initialize automatic
variables in RECURSIVE functions.
I believe this is a simple fix; to actually follow the specification
set forth in the man page, don't treat symbols in a RECURSIVE
namespace as if they are saved in resolve.c
(apply_default_init_local):
2014-08-29 Fritz Reese
* resolve.c (apply_default_init_local): Don't treat variables in
RECURSIVE units as saved.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 43eb240..a428633 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11104,6 +11104,7 @@ apply_default_init_local (gfc_symbol *sym)
result variable, which are also nonstatic. */
if (sym->attr.save || sym->ns->save_all
|| (gfc_option.flag_max_stack_var_size == 0 && !sym->attr.result
+ && !sym->ns->proc_name->attr.recursive
&& (!sym->attr.dimension || !is_non_constant_shape_array (sym
{
/* Don't clobber an existing initializer! */
diff --git a/gcc/testsuite/gfortran.dg/auto_save_2.f90 b/gcc/testsuite/gfortran.
new file mode 100644
index 000..0d39d48
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/auto_save_2.f90
@@ -0,0 +1,52 @@
+! { dg-do run }
+! { dg-options "-fno-automatic -finit-local-zero" }
+!
+! Make sure variables are saved with -fno-automatic except in
+! functions marked RECURSIVE, and that they are still initialized with
+! -finit-local-zero.
+!
+
+function f (x)
+implicit none
+ integer f, x
+ integer a ! should be SAVEd
+ a = a + x ! should increment by y every time
+ f = a
+ return
+endfunction
+
+recursive function g (x)
+implicit none
+ integer g, x
+ integer b ! should be automatic
+ b = b + x ! should be set to y every time
+ g = b
+ return
+endfunction
+
+implicit none
+integer f, g
+
+! Should return static value of a; accumulates y
+if ( f(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( f(4) .ne. 7 ) then
+ call abort ()
+endif
+if ( f(2) .ne. 9 ) then
+ call abort ()
+endif
+
+! Should return automatic value of a; equal to y each time
+if ( g(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( g(4) .ne. 4 ) then
+ call abort ()
+endif
+if ( g(2) .ne. 2 ) then
+ call abort ()
+endif
+
+end
Fritz Reese
[Patch, Fortran] Component declarations overwrite types of Cray Pointee variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174
The typespecs for Cray pointees are overwritten by the typespecs of
components with the same name which are declared later.
This problem was introduced with Cray pointer support in 4.1.0 and is
confirmed up through trunk (5.0).
Here is a proposed patch from 4.8.3 (test case comments/ChangeLog
descriptions are updated from the submission on bugzilla). The test
case demonstrates the problem.
FYI, I am currently working with my employer so any future changes I
have can comply with GNU's legal requirements. Also my mail client
replaces tabs with spaces so I'm sorry for any whitespace issues.
2014-09-02 Fritz Reese
PR fortran/62174
* decl.c (variable_decl): Don't overwrite typespecs of Cray pointees
when matching a component declaration.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 4048ac9..7b3c59a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1904,8 +1904,9 @@ variable_decl (int elem)
}
/* If this symbol has already shown up in a Cray Pointer declaration,
+ and this is not a component declaration,
then we want to set the type & bail out. */
- if (gfc_option.flag_cray_pointer)
+ if (gfc_option.flag_cray_pointer && gfc_current_state () != COMP_DERIVED)
{
gfc_find_symbol (name, gfc_current_ns, 1, &sym);
if (sym != NULL && sym->attr.cray_pointee)
2014-09-02 Fritz Reese
PR fortran/62174
* gcc/testsuite/gfortran.dg/cray_pointers_11.f90: New.
diff --git a/gcc/testsuite/gfortran.dg/cray_pointers_11.f90
b/gcc/testsuite/gfortran.dg/cray_pointers_11.f90
new file mode 100644
index 000..038e4dc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/cray_pointers_11.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-fcray-pointer" }
+!
+! PR fortran/62174
+! Component declarations within derived types would overwrite the typespec of
+! variables with the same name who were Cray pointees.
+implicit none
+
+type t1
+ integer i
+end type t1
+type(t1) x
+
+pointer (x_ptr, x)
+
+type t2
+ real x ! should not overwrite x's type
+end type t2
+
+x%i = 0 ! should see no error here
+
+end
---
Fritz Reese
Re: PR fortran/87919 patch for -fno-dec-structure
> I think more than enough time passed, do you plan to commit to trunk now? > Note, small adjustment will be needed for the addition of flag_dec_include > in set_dec_flags. Jakub- Sorry, yes. I've had other priorities the past few weeks here, but I just committed r266745 adjusted for -fdec-include. > I'm currently using this patch (pending it being committed) and have > some pending patches that use it. > > I can use the old method of setting dec options for the time being and > PR fortran/87919 will have to be modified accordingly. Sorry again for the delay. It is committed now, so you may use the new-style option setting. Thanks in advance for your upcoming patches. > I note that in gcc/fortran/options the comment preceding > set_default_std_flags it says: > > "Keep in sync with libgfortran/runtime/compile_options.c > (init_compile_options)." > > and in libgfortran/runtime/compile_options.c preceding > init_compile_options it says: > > "Keep in sync with gcc/fortran/options.c (gfc_init_options)." > > I think this should have (set_default_std_flags) instead of > (gfc_init_options) and they are not in sync. The first comment (above set_default_std_flags) is also present before gfc_init_options, which is technically the routine that should mirror init_compile_options. Since set_default_std_flags is a subroutine of gfc_init_options, it should also sync with the std flags setting in init_compile_options, so I don't think any of the comments are incorrect. However the symmetry may be more obvious if the std flags setting from init_compile_options was in a subroutine (named similarly to set_default_std_flags), then the comments on the default standard flags could reference each other. That being said, it does appear the default standard flags are out of sync, as you mentioned... Not sure if this is worth a PR but it's certainly worth fixing. Seems it was introduced when f2015 was renamed to f2018 in r255761. Fritz
Re: PR fortran/87919 patch for -fno-dec-structure
On Mon, Dec 3, 2018 at 12:12 PM Jakub Jelinek wrote: > > On Mon, Dec 03, 2018 at 04:58:51PM +0100, Jakub Jelinek wrote: > > > but I just committed r266745 adjusted for -fdec-include. > > > > Thanks, though it seems what you've committed in options.c is incomplete. > > In the patch you've posted earlier, you've changed also > > gfc_init_options and gfc_handle_option, to call the new functions > > (set_init_local_zero, post_dec_options) and use SET_FLAG and undefine it at > > the end. > > None of those changes appears in > > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/options.c?limit_changes=0&r1=266745&r2=266744&pathrev=266745 > > all changes stop at the newly added set_init_local_zero, so > > set_init_local_zero and post_dec_options are now unused functions. > > I've committed the remaining options.c changes in r266761 now > to unbreak the FAILs. > > Jakub Thanks, and sorry...
Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
>
> Just a couple of random comments.
> -fdec-pad-with-spaces option name doesn't look right, because it doesn't say
> what the option affects. So perhaps have transfer in the option name?
[...]
> Wouldn't it be better to allow specifying whatever character you want to pad
> with, so that users can choose something even different?
I concur with this. In that case some option like -ftransfer-pad-char=
may be a more appriopriate name, where -fdec may enable a default
transfer-pad-char of \x20 rather than \x00.
>
> > --- a/gcc/fortran/simplify.c
> > +++ b/gcc/fortran/simplify.c
> > @@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr
> > *mold, gfc_expr *size)
[...]
> This affects just the simplification when the argument is a known constant.
> Shouldn't we handle it also when it is not a constant?
Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
to affect non-constant resolution.
> The tests look too much big-endian vs. little-endian dependent and
> ascii dependent. We have pdp-endian and doesn't s390x TPF use EBCDIC?
>
> Wouldn't it be better to compare transfer("ABCE", 1_8) with transfer("ABCE
> ", 1_8)
Agreed.
---
Fritz
Re: Fortran patches
On Wed, Dec 5, 2018 at 12:00 AM Steve Kargl
wrote:
>
> I intend to commit the attached patch on Saturday.
Thanks for the work. I assume the patch bootstraps and passes regression tests?
RE:
> PR fortran/88228
> * expr.c (check_null, check_elemental): Work around -fdec and
> initialization with logical operators operating on integers.
I plan to review this section of the patch later today -- though the
patch hides the segfault from the PR, I need more time to determine
whether it is correct and complete.
RE:
>PR fortran/88139
>* dump-parse-tree.c (write_proc): Alternate return.
I dissent with this patch. The introduced error is meaningless and, as
mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree
is not directly the issue. The code should be rejected in parsing. In
gcc-8.1 the invalid code is accepted (without an ICE) even without the
-fc-prototypes flag: I haven't finished building the compiler with
your changes yet to see whether that is still true afterwards, but at
least the test case doesn't try this, so I strongly suspect the patch
is incomplete to fix the PR.
RE:
>PR fortran/88205
>* io.c (gfc_match_open): STATUS must be CHARACTER type.
[...]
>@@ -2161,6 +2167,12 @@ gfc_match_open (void)
>
> if (!open->file && open->status)
> {
>+ if (open->status->ts.type != BT_CHARACTER)
>+ {
>+gfc_error ("STATUS must be a default character type at %C");
>+goto cleanup;
>+ }
>+
> if (open->status->expr_type == EXPR_CONSTANT
> && gfc_wide_strncasecmp (open->status->value.character.string,
> "scratch", 7) != 0)
Both resolve_tag() and is_char_type() actually already catch type
mismatches for STATUS (the latter for constant expressions). The real
problem is the following condition which checks STATUS before it has
been processed yet, since NEWUNIT is processed before STATUS. I think
the correct thing to do is actually to move the NEWUNIT/UNIT if-block
after the STATUS if-block, rather than adding a new phrasing for the
same error. Then we should see:
pr88205.f90:13:29:
open (newunit=n, status=status)
1
Error: STATUS requires a scalar-default-char-expr at (1)
RE:
>PR fortran/88328
>* io.c (resolve_tag_format): Detect zero-sized array.
[...]
>Index: gcc/fortran/io.c
>===
>--- gcc/fortran/io.c(revision 266718)
>+++ gcc/fortran/io.c(working copy)
>@@ -1636,6 +1636,12 @@ resolve_tag_format (gfc_expr *e)
> gfc_expr *r;
> gfc_char_t *dest, *src;
>
>+ if (e->value.constructor == NULL)
>+ {
>+ gfc_error ("FORMAT tag at %C cannot be a zero-sized array");
>+ return false;
>+ }
>+
> n = 0;
> c = gfc_constructor_first (e->value.constructor);
> len = c->expr->value.character.length;
[...]
>@ -3231,12 +3257,21 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
> {
> gfc_expr *e;
> io_kind k;
>+ locus loc_tmp;
>
> /* This is set in any case. */
> gcc_assert (dt->dt_io_kind);
> k = dt->dt_io_kind->value.iokind;
>
>- RESOLVE_TAG (&tag_format, dt->format_expr);
>+ loc_tmp = gfc_current_locus;
>+ gfc_current_locus = *loc;
>+ if (!resolve_tag (&tag_format, dt->format_expr))
>+{
>+ gfc_current_locus = loc_tmp;
>+ return false;
>+}
>+ gfc_current_locus = loc_tmp;
>+
> RESOLVE_TAG (&tag_rec, dt->rec);
> RESOLVE_TAG (&tag_spos, dt->pos);
> RESOLVE_TAG (&tag_advance, dt->advance);
Is it really true that resolve_tag_format needs the locus at
gfc_resolve_dt::loc instead of e->where as with the other errors in
resolve_tag_format? If so, are the other errors also incorrect in
using e->where? Might it then be better to pass loc from
gfc_resolve_dt down to resolve_tag/RESOLVE_TAG and then
resolve_tag_format, instead of swapping gfc_current_locus?
RE:
>PR fortran/88048
>* resolve.c (check_data_variable): Convert gfc_internal_error to
>an gfc_error. Add a nearby missing 'return false;'
[...]
>PR fortran/88025
>* expr.c (gfc_apply_init): Remove asserts and check for valid
>ts->u.cl->length.
[...]
>PR fortran/88116
>* simplify.c: Remove internal error and return gfc_bad_expr.
These look good.
A few pedantic comments:
RE:
> PR fortran/88269
> * io.c (io_constraint): Update macro. Remove incompatible use
> of io_constraint and give explicit error.
[...]
There should be two separate references to io_constraint and
check_io_constraints:
> * io.c (io_constraint): Update macro.
> (check_io_constraints) Remove incompatible use
> of io_constraint and give explicit error.
RE:
> #define io_constraint(condition,msg,arg)\
> if (condition) \
> {\
>-gfc_error(msg,arg);\
>+if ((arg)->lb
Re: Fortran patches
On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl
wrote:
>
> On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote:
[...]
> > RE:
> > > PR fortran/88228
> > > * expr.c (check_null, check_elemental): Work around -fdec and
> > > initialization with logical operators operating on integers.
> >
> > I plan to review this section of the patch later today -- though the
> > patch hides the segfault from the PR, I need more time to determine
> > whether it is correct and complete.
>
> By the time the gfc_expr is given to check_check and check_elemental,
> it has been reduced to a EXPR_CONSTANT, which neither routine expected.
> I simply return early in that case.
It appears the correct solution is simply the following patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b2090218d48..775a5c52c65 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -4004,7 +4004,7 @@ resolve_operator (gfc_expr *e)
if (op2->ts.type != e->ts.type || op2->ts.kind != e->ts.kind)
gfc_convert_type (op2, &e->ts, 1);
e = logical_to_bitwise (e);
- return resolve_function (e);
+ break;
}
sprintf (msg, _("Operands of logical operator %%<%s%%> at %%L
are %s/%s"),
@@ -4020,7 +4020,7 @@ resolve_operator (gfc_expr *e)
e->ts.type = BT_INTEGER;
e->ts.kind = op1->ts.kind;
e = logical_to_bitwise (e);
- return resolve_function (e);
+ break;
}
if (op1->ts.type == BT_LOGICAL)
Returning immediately short-circuits various checks and
simplifications which are done in the remainder of resolve_operator,
including gfc_simplify_expr which handles the EXPR_CONSTANT case. The
comments on gfc_reduce_init_expr indicate that check_null and
check_elemental should never get EXPR_CONSTANT anyway if
gfc_resolve_expr is correct. Regression tests verify this patch is
correct. Please use this patch instead for PR 88228, or if you prefer
I can submit/commit the patch myself.
>
> > RE:
> > >PR fortran/88139
> > >* dump-parse-tree.c (write_proc): Alternate return.
> > I dissent with this patch. The introduced error is meaningless and, as
> > mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree
> > is not directly the issue. The code should be rejected in parsing. In
> > gcc-8.1 the invalid code is accepted (without an ICE) even without the
> > -fc-prototypes flag: I haven't finished building the compiler with
> > your changes yet to see whether that is still true afterwards, but at
> > least the test case doesn't try this, so I strongly suspect the patch
> > is incomplete to fix the PR.
>
> Comment #3 does not contain a patch to fix the problem elsewhere.
>
> In F2003, 15.2.6 "Interoperability of procedures and procedure interfaces",
> I cannot find a prohibition on an alternate return in a subroutine
> interface with BIND(C).
>
> I'm disinclined to let a patch fester in bugzilla to only attain
> the same fate as my patch to PR68544.
According to F2008 §15.3.7.2(5):
> any dummy argument without the VALUE attribute [...] is interoperable with an
> entity of the
> referenced type (ISO/IEC 9899:1999, 6.2.5, 7.17, and 7.18.1) of the formal
> parameter
Regardless of whether or not we accept alternate returns in BIND(C)
procedures, the compiler must be at least consistent: if we accept
them (which gfortran currently does), then we should be able to dump
the C prototype (with -fc-prototypes), providing a formal parameter
interoperable with the type of the alternate return dummy argument; if
we reject them, then we should issue the error in parsing (before
handling by -fc-prototypes). In either case, the error message should
not be obscure or meaningless. Even so, the patch here is inconsistent
since we accept the code, but issue an error when attempting to dump
the C prototype.
However, gfortran does not implement alternate return dummy arguments
as actual arguments, but rather using an integer return code
(regardless of the number of alternate return parameters in the
interface). One interpretation of the consequences of this are that
BIND(C) should be rejected, since there is no interoperable formal
parameter which can be used to mirror the dummy argument (required by
15.3.7.2.5 above). An alternate interpretation is that we can continue
to accept BIND(C) with alternate return dummy arguments, but just
ignore the alternate return arguments. The former is perhaps more
"correct"; the latter is perhaps more useful albeit potentially
error-prone.
To patch support for the latter case, rather than issuing an error in
write_proc for procedures with alternate return arguments, we should
ou
Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
> On Mon, Dec 10, 2018 at 02:09:50PM +, Mark Eggleston wrote: > > > > On 06/12/2018 10:20, Mark Eggleston wrote: > > > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer) > > > > to affect non-constant resolution. > > > Thanks for the hint. > > > > I've looked at gfc_resolve_transfer regarding handling of padding when a > > character variable is passed to transfer instead of a literal. This routine > > is not called so can't be where a variable would be handled. > > > > Don't yet know where to make the change. It actually is called through a function pointer (gfc_intrinsic_sym->resolve) in intrinsic.c (resolve_intrinsic), as with all intrinsics. You can find the backtrace by running f951 (`gfortran -print-prog-name=f951`) through gdb and setting a breakpoint on gfc_resolve_transfer. That being said... On Mon, Dec 10, 2018 at 12:12 PM Jakub Jelinek wrote: > I think you want to change gfc_conv_intrinsic_transfer ... in this case Jakub is right. I hadn't looked at the body of the resolve function yet, but peeking at it tells me the transfer expression doesn't contain support for padding information, so you'd have to deal with it yourself in translation. > I guess you want to add after this, guarded with flag_dec only, > code to compare (at runtime) if extent < dest_word_len and if so, > use fill_with_spaces to pad it with spaces at the end (from > that first memcpy's argument + extent dest_word_len - extent bytes), > with a comment why you are doing it. Guess the array case will need > something similar. Alternatively you could call BUILT_IN_MEMSET(&tmpdecl, '\x20', dest_word_len) just prior to the MEMCPY whenever flag_dec is set. Fritz
Re: PR fortran/87919 patch for -fno-dec-structure
On 11/7/18, Jakub Jelinek wrote: > On Wed, Nov 07, 2018 at 03:07:04PM +, Mark Eggleston wrote: > >> PR fortran/87919 >> * options.c (gfc_handle_option): Removed case OPT_fdec_structure >> as it breaks the handling of -fno-dec-structure. > > No entries for the tests, i.e. > * gfortran.dg/pr87919-dec-structure-1.f: New test. > * gfortran.dg/pr87919-dec-structure-2.f: New test. > * gfortran.dg/pr87919-dec-structure-3.f: New test. > * gfortran.dg/pr87919-dec-structure-4.f: New test. > >> diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c >> index 73f5389361d9..3b7c2d40fe8a 100644 >> --- a/gcc/fortran/options.c >> +++ b/gcc/fortran/options.c >> @@ -761,10 +761,6 @@ gfc_handle_option (size_t scode, const char *arg, >> HOST_WIDE_INT value, >>/* Enable all DEC extensions. */ >>set_dec_flags (1); >>break; >> - >> -case OPT_fdec_structure: >> - flag_dec_structure = 1; >> - break; >> } >> >>Fortran_handle_option_auto (&global_options, &global_options_set, > > LGTM, but I'll defer the final review to Fortran maintainers. Thanks for the patch Mark, I concur with Jakub that it is correct for what it does. However, I have a few comments in addition to the fixes recommended by Jakub regarding the test cases. First, I would prefer to name these test cases as "dec_structure_*.f" to align with the other (23) -fdec-structure test cases. Second, the third case (*dec-structure-3.f) is unnecessary because it is identical in function to dec_structure_1.f90. I concur with the remaining test cases, as well as Jakub's suggestion to cover "-fdec-structure -fno-dec-structure" with an additional test. I would name the final four (= 4 - 1 + 1) tests as "dec_structure_[24-27].f". I have taken the liberty of extending this patch to cover the remainder of PR 87919. That is, to fix -fno-* for -fno-dec, -fno-check-array-temporaries and -fno-init-local-zero. In the extended patch, the 'value' set for the aforementioned options is no longer ignored, so that value=1 truly means set and value=0 truly means "unset". Previously, the aforementioned flags effectively ignored the value=0 condition. Similarly to the tests Mark provided with -fdec-structure, I've provided new tests for the various facets of -fno-dec, -fno-check-array-temporaries, and -fno-init-local-zero. Below is the changelog. Bootstraps and regtests fine for me on x86_64-redhat-linux. If it looks OK I'll commit to trunk (and probably backport to 8-branch and 7-branch since the affected code appears to be the same for those branches). >From 2d9e39bbf4a179ae433f33f4e7039b85078ba72f Mon Sep 17 00:00:00 2001 From: Fritz Reese Date: Wed, 7 Nov 2018 15:13:50 -0500 Subject: [PATCH] PR fortran/87919 Fix handling -fno-* prefix for init-local-zero, check-array-temporaries and dec. gcc/fortran/ * options.c (SET_FLAG, SET_BITFLAG): New macros. (set_dec_flags): Unset DEC flags with value==0. (set_init_local_zero): New helper for -finit-local-zero flag group. (gfc_init_options): Fix disabling of init flags, array temporaries check, and dec flags when value is zero (from -fno-*). gcc/testsuiste/ * gfortran.dg/array_temporaries_5.f90: New test. * gfortran.dg/dec_bitwise_ops_3.f90: Ditto. * gfortran.dg/dec_d_lines_3.f: Ditto. * gfortran.dg/dec_exp_4.f90: Ditto. * gfortran.dg/dec_exp_5.f90: Ditto. * gfortran.dg/dec_io_7.f90: Ditto. * gfortran.dg/dec_structure_24.f: Ditto. * gfortran.dg/dec_structure_25.f: Ditto. * gfortran.dg/dec_structure_26.f: Ditto. * gfortran.dg/dec_structure_27.f: Ditto. * gfortran.dg/dec_type_print_3.f90: Ditto. * gfortran.dg/init_flag_20.f90: Ditto. --- gcc/fortran/options.c | 70 +++ gcc/testsuite/gfortran.dg/array_temporaries_5.f90 | 20 +++ gcc/testsuite/gfortran.dg/dec_bitwise_ops_3.f90 | 19 ++ gcc/testsuite/gfortran.dg/dec_d_lines_3.f | 10 gcc/testsuite/gfortran.dg/dec_exp_4.f90 | 13 + gcc/testsuite/gfortran.dg/dec_exp_5.f90 | 15 + gcc/testsuite/gfortran.dg/dec_io_7.f90| 22 +++ gcc/testsuite/gfortran.dg/dec_structure_24.f | 21 +++ gcc/testsuite/gfortran.dg/dec_structure_25.f | 22 +++ gcc/testsuite/gfortran.dg/dec_structure_26.f | 22 +++ gcc/testsuite/gfortran.dg/dec_structure_27.f | 20 +++ gcc/testsuite/gfortran.dg/dec_type_print_3.f90| 29 ++ gcc/testsuite/gfortran.dg/init_flag_20.f90| 62 13 files changed, 320 insertions(+), 25 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/array_temporaries_5
Re: PR fortran/87919 patch for -fno-dec-structure
On Wed, Nov 7, 2018 at 5:32 PM Jakub Jelinek wrote:
>
> On Wed, Nov 07, 2018 at 05:05:13PM -0500, Fritz Reese wrote:
>
> --- a/gcc/fortran/options.c
> +++ b/gcc/fortran/options.c
> @@ -32,6 +32,20 @@ along with GCC; see the file COPYING3. If not see
>
> gfc_option_t gfc_option;
>
> +#define _expand(m) m
>
> I think it would be better to avoid names like _expand, too generic
> name and starts with underscore, name it e.g. SET_BITFLAG_1 or something
> similar. And it isn't mentioned in the ChangeLog.
I find "expand" a more helpful name than "set_bitflag_1" since it
describes what the macro does. However, I don't think it makes too
much of a difference so I'll follow your preference (but I'll use
SET_BITFLAG2 since then the definition line fits in 80 characters).
>
> @@ -62,14 +75,30 @@ set_dec_flags (int value)
> }
>
> What about the
> /* Allow legacy code without warnings. */
> gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
> | GFC_STD_GNU | GFC_STD_LEGACY;
> gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
> that is done for value, shouldn't set_dec_flags remove those
> flags again? Maybe not the allow_std ones, because those are set already by
> default, perhaps just the warn_std flags?
>
Sure. I wasn't convinced about this and how it might interplay with
-std= so I left it alone, but I suppose it makes sense to unsuppress
the warnings when disabling -fdec.
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
> @@ -0,0 +1,20 @@
> +! { dg-do run }
> +! { dg-options "-fcheck-array-temporaries -fno-check-array-temporaries" }
> +!
> +! PR fortran/87919
> +!
> +! Ensure -fno-check-array-temporaries disables array temporary checking.
> +! Copied from array_temporaries_2.f90.
>
> For tests where you expect no errors and that are just copies of other
> testcases, perhaps
> include 'array_temporaries_2.f90'
> or similar instead?
>
Strictly speaking it's not an exact copy because it omits the final {
dg-output } check for the runtime warning, since the warning is
supposed to occur in array_temporaries_2.f90 but not in the new case
array_temporaries_5.f90. I assumed include would propagate the {
dg-output } check -- upon actually testing this, it appears that is
not the case. I find this misleading at a glance, but it works, so I
don't mind this with an extra comment line.
Attached is a new patch which incorporates your recommendations.
Here's the diff between the two, followed by the new changelog:
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index e703cad96fd..167621905bc 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -32,8 +32,6 @@ along with GCC; see the file COPYING3. If not see
gfc_option_t gfc_option;
-#define _expand(m) m
-
#define SET_FLAG(flag, condition, on_value, off_value) \
do \
{ \
@@ -43,8 +41,10 @@ gfc_option_t gfc_option;
flag = (off_value); \
} while (0)
+#define SET_BITFLAG2(m) m
+
#define SET_BITFLAG(flag, condition, value) \
- _expand (SET_FLAG (flag, condition, (flag | (value)), (flag & ~(value
+ SET_BITFLAG2 (SET_FLAG (flag, condition, (flag | (value)), (flag &
~(value
/* Set flags that control warnings and errors for different
@@ -66,15 +66,17 @@ set_default_std_flags (void)
static void
set_dec_flags (int value)
{
+ /* Allow legacy code without warnings.
+ Nb. We do not unset the allowed standards with value == 0 because
+ they are set by default in set_default_std_flags. */
if (value)
-{
- /* Allow legacy code without warnings. */
- gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
-| GFC_STD_GNU | GFC_STD_LEGACY;
- gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
-}
+gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
+ | GFC_STD_GNU | GFC_STD_LEGACY;
+
+ SET_BITFLAG (gfc_option.warn_std, !value, GFC_STD_LEGACY);
+ SET_BITFLAG (gfc_option.warn_std, !value, GFC_STD_F95_DEL);
- /* Set other DEC compatibility extensions. */
+ /* Set (or unset) other DEC compatibility extensions. */
SET_BITFLAG (flag_dollar_ok, value, value);
SET_BITFLAG (flag_cray_pointer, value, value);
SET_BITFLAG (flag_dec_structure, value, value);
@@ -855,3 +871,7 @@ gfc_get_option_string (void)
}
#undef SET_BITFLAG
+#undef SET_BITFLAG2
#undef SET_FLAG
-#undef _expand
diff --git a/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
b/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
index 0070a935933..dd147ba38ed 100644
--- a/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
+++ b/gcc/testsuite/gfortran.dg/array_temporaries_5.f90
@@ -4,17 +4,7 @@
! PR fortran/87919
!
! Ensure -fno-check-array-temporaries disables array temporary che
Re: PR fortran/87919 patch for -fno-dec-structure
On Thu, Nov 8, 2018 at 12:54 PM Jakub Jelinek wrote:
>
> On Thu, Nov 08, 2018 at 12:09:33PM -0500, Fritz Reese wrote:
> > > What about the
> > > /* Allow legacy code without warnings. */
> > > gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
> > > | GFC_STD_GNU | GFC_STD_LEGACY;
> > > gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
> > > that is done for value, shouldn't set_dec_flags remove those
> > > flags again? Maybe not the allow_std ones, because those are set already
> > > by
> > > default, perhaps just the warn_std flags?
> > >
> >
> > Sure. I wasn't convinced about this and how it might interplay with
> > -std= so I left it alone, but I suppose it makes sense to unsuppress
> > the warnings when disabling -fdec.
>
> Perhaps it might be better not to change the allow_std/warn_std flags
> during the option parsing, instead set or clear say flag_dec and
> only when option processing is being finalized (gfc_post_options)
> check if flag_dec is set and set those. It would change behavior of
> -fdec -std=f2018 and similar though. Not sure what users expect.
>
Actually, the gcc frontend appears to move -std= before the
language-specific options before f951 is even executed regardless of
its location compared to the -fdec flags. I don't know if this is a
bug or if it is by design -- the feeling I get is that the gcc
frontend processes it first since it is recognized before the flang
specific options. Therefore, greedily setting the standard options the
first time flag_dec appears means the standard information is lost and
I believe your suggestion is correct: the standard flags must be set
only once in gfc_post_options.
In fact the new testcase dec_bitwise_ops_3.f90 is a good test of this:
it uses -fdec -fno-dec -std=legacy to avoid warnings for XOR. With the
version posted previously, the -std=legacy is overwritten by -fno-dec
and warnings still appear. Here's what I'd change from the previous
patch to support this:
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index af89a5d2faf..b7f7360215c 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -66,16 +66,6 @@ set_default_std_flags (void)
static void
set_dec_flags (int value)
{
- /* Allow legacy code without warnings.
- Nb. We do not unset the allowed standards with value == 0 because
- they are set by default in set_default_std_flags. */
- if (value)
-gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
- | GFC_STD_GNU | GFC_STD_LEGACY;
-
- SET_BITFLAG (gfc_option.warn_std, !value, GFC_STD_LEGACY);
- SET_BITFLAG (gfc_option.warn_std, !value, GFC_STD_F95_DEL);
-
/* Set (or unset) other DEC compatibility extensions. */
SET_BITFLAG (flag_dollar_ok, value, value);
SET_BITFLAG (flag_cray_pointer, value, value);
@@ -85,6 +75,24 @@ set_dec_flags (int value)
SET_BITFLAG (flag_dec_math, value, value);
}
+/* Finalize DEC flags. */
+
+static void
+post_dec_flags (int value)
+{
+ /* Don't warn for legacy code if -fdec is given; however, setting -fno-dec
+ does not force these warnings. We make one final determination on this
+ at the end because -std= is always set first; thus, we can avoid
+ clobbering the user's desired standard settings in gfc_handle_option
+ e.g. when -fdec and -fno-dec are both given. */
+ if (value)
+{
+ gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
+ | GFC_STD_GNU | GFC_STD_LEGACY;
+ gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
+}
+}
+
/* Enable (or disable) -finit-local-zero. */
static void
@@ -248,6 +256,9 @@ gfc_post_options (const char **pfilename)
char *source_path;
int i;
+ /* Finalize DEC flags. */
+ post_dec_flags (flag_dec);
+
/* Excess precision other than "fast" requires front-end
support. */
if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD)
@@
> Directives are only processed in the current file, so it doesn't really
> matter what the included file has as directives. One could even have the
> included one be with expected dg-error lines and then include it in
> the ones that don't expect any.
Good to know, thanks! In that case, I like your suggestion of reducing
the test cases to includes. See new the newly attached patch for
updated cases.
> Anyway, that is all from me, I still don't want to stomp on Fortran
> maintainer's review (use my global reviewer's rights for that) and
> thus I'm deferring the review to them. When committing, please make sure
> to include Mark's email in the ChangeLog next to yours to credit him.
Thanks for your comments. I think nobody will feel stomped on since
maintainers are sparse and busy. I will certainly m
[PATCH, fortran] PR fortran/85982 -- Fix ICE on invalid attributes inside DEC structures
All,
The simple patch below (and attached) fixes PR 85982. The issue is an
omission of the macro gfc_comp_struct() which would include DEC
structures in certain attribute checks that are performed for
derived-TYPE declarations in decl.c. In the case described in the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982) there is an ICE
because the presence of an invalid EXTERNAL attribute leaks through to
resolve_component, invalidating some invariants for objects which are
supposed to be EXTERNAL.
This is fairly obvious so I would commit to trunk and backport to
7-branch and 8-branch if nobody sees any issues this week or so.
(Nb. the test case is named dec_structure_28.f90 so as not to conflict
with the pending patch for PR fortran/87919 which adds
dec_structure_{24-27}.f90.)
--
Fritz
>From dc5a072017af29ca1e84b85b0e3a1e6af49a6928 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 12 Nov 2018 15:19:39 -0500
Fix ICE due to erroneously accepted component attributes in DEC structures.
gcc/fortran/
* decl.c (match_attr_spec): Lump COMP_STRUCTURE/COMP_MAP into attribute
checking used by TYPE.
gcc/testsuite/
* gfortran.dg/dec_structure_28.f90: New test.
---
gcc/fortran/decl.c | 17 -
gcc/testsuite/gfortran.dg/dec_structure_28.f90 | 35 ++
2 files changed, 46 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_28.f90
index 87c736fb2db..2b294fdf65f 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5184,15 +5184,18 @@ match_attr_spec (void)
if (d == DECL_STATIC && seen[DECL_SAVE])
continue;
- if (gfc_current_state () == COMP_DERIVED
+ if (gfc_comp_struct (gfc_current_state ())
&& d != DECL_DIMENSION && d != DECL_CODIMENSION
&& d != DECL_POINTER && d != DECL_PRIVATE
&& d != DECL_PUBLIC && d != DECL_CONTIGUOUS && d != DECL_NONE)
{
+ const char* const state_name = (gfc_current_state () == COMP_DERIVED
+ ? "TYPE" : "STRUCTURE");
if (d == DECL_ALLOCATABLE)
{
if (!gfc_notify_std (GFC_STD_F2003, "ALLOCATABLE "
- "attribute at %C in a TYPE definition"))
+ "attribute at %C in a %s definition",
+ state_name))
{
m = MATCH_ERROR;
goto cleanup;
@@ -5201,7 +5204,8 @@ match_attr_spec (void)
else if (d == DECL_KIND)
{
if (!gfc_notify_std (GFC_STD_F2003, "KIND "
- "attribute at %C in a TYPE definition"))
+ "attribute at %C in a %s definition",
+ state_name))
{
m = MATCH_ERROR;
goto cleanup;
@@ -5225,7 +5229,8 @@ match_attr_spec (void)
else if (d == DECL_LEN)
{
if (!gfc_notify_std (GFC_STD_F2003, "LEN "
- "attribute at %C in a TYPE definition"))
+ "attribute at %C in a %s definition",
+ state_name))
{
m = MATCH_ERROR;
goto cleanup;
@@ -5248,8 +5253,8 @@ match_attr_spec (void)
}
else
{
- gfc_error ("Attribute at %L is not allowed in a TYPE definition",
-&seen_at[d]);
+ gfc_error ("Attribute at %L is not allowed in a %s definition",
+&seen_at[d], state_name);
m = MATCH_ERROR;
goto cleanup;
}
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_28.f90
b/gcc/testsuite/gfortran.dg/dec_structure_28.f90
new file mode 100644
index 000..bab08b2d5c3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_structure_28.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-fdec-structure -fdec-static" }
+!
+! PR fortran/85982
+!
+! Test a regression wherein some component attributes were erroneously accepted
+! within a DEC structure.
+!
+
+structure /s/
+ integer :: a
+ integer, intent(in) :: b ! { dg-error "is not allowed" }
+ integer, intent(out) :: c ! { dg-error "is not allowed" }
+ integer, intent(inout) :: d ! { dg-error "is not allowed" }
+ integer, dimension(1,1) :: e ! OK
+ integer, external, pointer :: f ! { dg-error "is not allowed" }
+ integer, intrinsic :: f ! { dg-error "is not allowed" }
+ integer, optional :: g ! { dg-error "is not allowed" }
+ integer, parameter :: h ! { dg-error "is not al
Re: PR fortran/87919 patch for -fno-dec-structure
On Mon, Nov 12, 2018 at 3:42 PM Jakub Jelinek wrote: > Ok, so I'll ack it for trunk now, but please give the other Fortran > maintainers one day to disagree before committing. > For the release branches, I'd wait two weeks or so before backporting it. > Roger that. I'll happily give it some time. Thanks for looking it over. Fritz
Re: [PATCH] Fortran include line fixes and -fdec-include support
On Mon, Nov 12, 2018 at 9:51 AM Jakub Jelinek wrote: > > In fortran97.pdf I read: > "Except in a character context, blanks are insignificant and may be used > freely throughout the program." > and while we handle that in most cases, we don't allow spaces in INCLUDE > lines in fixed form, while e.g. ifort does. I agree with fixing this unconditionally. > Another thing, which I haven't touched in the PR except covering it with a > testcase is that we allow INLINE line in fixed form to start even in columns > 1 to 6, while ifort rejects that. Is say > include 'omp_lib.h' > valid in fixed form? i in column 6 normally means a continuation line, > though not sure if anything can in a valid program contain nclude > followed by character literal. Shall we reject that, or at least warn that > it won't be portable? AFAICT this is unambiguous so I would certainly suggest adding such a warning (enabled by default). > The last thing, biggest part of the patch, is that for legacy DEC > compatibility, the DEC manuals document INCLUDE as a statement, not a line, > [...] > This means there can be (as can be seen in the following testcases) > continuations in both forms, and in fixed form there can be 0 in column 6. Makes sense to me. I concur with adding -fdec-include to support this under -fdec. If we are going to warn for the above and re-do the include matching anyway, I wonder if we should have also a specific error message for a labeled include statement? For example, 10include 'include_10.inc' Will result in the generic 'Unclassifiable statement' error, but ifort gives "Label on INCLUDE is invalid." > In order not to duplicate all the handling of continuations, comment > skipping etc., the patch just adjusts the include_line routine so that it > signals if the current line is a possible start of a valid INCLUDE statement > when in -fdec-include mode, and if so, whenever it reads a further line it > retries to parse it using > gfc_next_char/gfc_next_char_literal/gfc_gobble_whitespace APIs as an INCLUDE > stmt. If it is found not to be a valid INCLUDE statement line or set of > lines, it returns 0, if it is valid, it returns 1 together with load_file > like include_line does and clears all the lines containint the INCLUDE > statement. If the reading stops because we don't have enough lines, -1 is > returned and the caller tries again with more lines. LGTM. > In addition to the above mentioned question about include in columns 1-6 in > fixed form, another thing is that we support > print *, 'abc''def' > print *, "hij""klm" > which prints abc'def and hij"klm. Shall we support that for INCLUDE lines > and INCLUDE statements too? It appears ifort does also support this. I see no reason not to, as the feature should be straightforward to implement. > Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest? With the above additions it looks ok to me, but I must defer to an official Fortran reviewer. --- Fritz
[PATCH, Fortran] New flag -finit-derived to initialize components of derived types
All,
With many other compilers, local variables are automatically
initialized to zero (or some other user-specified value) by default.
GNU Fortran allows this with the options -finit-local-zero,
-finit-real=, -finit-integer=, etc... However several other compilers
also initialize structure variables (components of derived type
variables), a feature which GNU Fortran does not provide. This would
be a useful feature, and (unfortunately) some legacy code even relies
on automatic initialization of structures.
To increase usability and compatibility I have thus a patch which
introduces a new flag -finit-derived into GNU Fortran, allowing
initialization of automatic derived-type and structure variables. With
the patch GNU Fortran generates initializers for structure/derived
type components as if they were local variables of the same type,
according to the other initialization flags (-finit-local-zero,
finit-real=, -finit-integer=, etc...).
The bulk of the patch includes refactoring some common behaviors in
the existing functions in resolve.c (build_default_init_expr) and
decl.c (build_struct) by placing them in new functions in expr.c
(gfc_build_default_init_expr, gfc_apply_init). The crux of the patch
is a fairly simple tweak to expr.c (gfc_default_initializer), now in
the new functions (component_initializer, gfc_generate_initializer),
which generates initializers for components that do not have them,
when the time is right. Please review and let me know if there are
questions or comments.
Bootstraps and passes all tests (including the several shipped with
it) on x86_64-redhat-linux. If it is ok for trunk I will commit.
---
Fritz Reese
2016-08-04 Fritz Reese
gcc/fortran/
* lang.opt, invoke.texi: New flag -finit-derived.
* gfortran.h (gfc_build_default_init_expr, gfc_apply_init,
gfc_generate_initializer): New prototypes.
* expr.c (gfc_build_default_init_expr, gfc_apply_init,
component_initializer, gfc_generate_initializer): New functions.
* expr.c (gfc_default_initializer): Wrap gfc_generate_initializer.
* decl.c (build_struct): Move common code to gfc_apply_init.
* resolve.c (can_generate_init): New function.
* resolve.c (build_default_init_expr): Wrap gfc_build_default_init_expr.
* resolve.c (apply_default_init, resolve_fl_variable_derived): Use
gfc_generate_initializer.
* trans-decl.c (gfc_generate_function_code): Use
gfc_generate_initializer.
gcc/testsuite/gfortran.dg/
* init_flag_13.f90: New testcase.
* init_flag_14.f90: Ditto.
* init_flag_15.f03: Ditto.
* dec_init_1.f90: Ditto.
* dec_init_2.f90: Ditto.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 818e7d4..80af17c 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1910,53 +1910,7 @@ build_struct (const char *name, gfc_charlen *cl, gfc_expr **init,
}
*as = NULL;
- /* Should this ever get more complicated, combine with similar section
- in add_init_expr_to_sym into a separate function. */
- if (c->ts.type == BT_CHARACTER && !c->attr.pointer && c->initializer
- && c->ts.u.cl
- && c->ts.u.cl->length && c->ts.u.cl->length->expr_type == EXPR_CONSTANT)
-{
- int len;
-
- gcc_assert (c->ts.u.cl && c->ts.u.cl->length);
- gcc_assert (c->ts.u.cl->length->expr_type == EXPR_CONSTANT);
- gcc_assert (c->ts.u.cl->length->ts.type == BT_INTEGER);
-
- len = mpz_get_si (c->ts.u.cl->length->value.integer);
-
- if (c->initializer->expr_type == EXPR_CONSTANT)
- gfc_set_constant_character_len (len, c->initializer, -1);
- else if (c->initializer
- && c->initializer->ts.u.cl
- && mpz_cmp (c->ts.u.cl->length->value.integer,
- c->initializer->ts.u.cl->length->value.integer))
- {
- gfc_constructor *ctor;
- ctor = gfc_constructor_first (c->initializer->value.constructor);
-
- if (ctor)
- {
- int first_len;
- bool has_ts = (c->initializer->ts.u.cl
- && c->initializer->ts.u.cl->length_from_typespec);
-
- /* Remember the length of the first element for checking
- that all elements *in the constructor* have the same
- length. This need not be the length of the LHS! */
- gcc_assert (ctor->expr->expr_type == EXPR_CONSTANT);
- gcc_assert (ctor->expr->ts.type == BT_CHARACTER);
- first_len = ctor->expr->value.character.length;
-
- for ( ; ctor; ctor = gfc_constructor_next (ctor))
- if (ctor->expr->expr_type == EXPR_CONSTANT)
- {
- gfc_set_constant_character_len (len, ctor->expr,
- has_ts ? -1 : first_len);
- ctor->expr->ts.u.cl->length = gfc_copy_expr (c->ts.u.cl->length);
- }
- }
- }
-}
+ gfc_apply
Ping! Re: [PATCH, Fortran] New flag -finit-derived to initialize components of derived types
https://gcc.gnu.org/ml/fortran/2016-08/msg00014.html On Thu, Aug 4, 2016 at 2:07 PM, Fritz Reese wrote: > ... > To increase usability and compatibility I have thus a patch which > introduces a new flag -finit-derived into GNU Fortran, allowing > initialization of automatic derived-type and structure variables. With > the patch GNU Fortran generates initializers for structure/derived > type components as if they were local variables of the same type, > according to the other initialization flags (-finit-local-zero, > finit-real=, -finit-integer=, etc...). > ... Still waiting on a review for this patch. Comments/concerns from all are welcome. > ... > Bootstraps and passes all tests (including the several shipped with > it) on x86_64-redhat-linux. If it is ok for trunk I will commit. > ... > 2016-08-04 Fritz Reese > > gcc/fortran/ > * lang.opt, invoke.texi: New flag -finit-derived. > * gfortran.h (gfc_build_default_init_expr, gfc_apply_init, > gfc_generate_initializer): New prototypes. > * expr.c (gfc_build_default_init_expr, gfc_apply_init, > component_initializer, gfc_generate_initializer): New functions. > * expr.c (gfc_default_initializer): Wrap gfc_generate_initializer. > * decl.c (build_struct): Move common code to gfc_apply_init. > * resolve.c (can_generate_init): New function. > * resolve.c (build_default_init_expr): Wrap > gfc_build_default_init_expr. > * resolve.c (apply_default_init, resolve_fl_variable_derived): Use > gfc_generate_initializer. > * trans-decl.c (gfc_generate_function_code): Use > gfc_generate_initializer. > > gcc/testsuite/gfortran.dg/ > * init_flag_13.f90: New testcase. > * init_flag_14.f90: Ditto. > * init_flag_15.f03: Ditto. > * dec_init_1.f90: Ditto. > * dec_init_2.f90: Ditto. --- Fritz Reese
[PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
Greetings,
This patch extends the GNU Fortran front-end to add support for
DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
-fdec-static, allowing explicit control of variable storage. AUTOMATIC
local variables are placed on the stack, whereas STATIC variables are
placed in static storage.
Currently, GNU Fortran provides some control over variable storage
through the use of its options -f[no-]automatic, -f[no-]recursive, and
-fmax-stack-var-size=, as well as the Fortran standard SAVE attribute.
However there is no way to mark a particular variable to be allocated
in automatic storage without potentially affecting other variables in
a given program. There are programs written in legacy (non-standard)
Fortran which do use the AUTOMATIC attribute for this reason. STATIC
is just an alias for SAVE, but provides further compatibility for such
legacy programs.
AUTOMATIC is implemented as a new symbol_attribute 'automatic', which
is checked in a couple places in resolve.c (apply_default_init_local,
resolve_fl_variable_derived, resolve_symbol), symbol.c
(gfc_is_var_automatic), and trans-decl.c (gfc_finish_var_decl). Note
that AUTOMATIC does NOT override -fno-automatic; with the flag, a
warning is produced for variables marked AUTOMATIC. STATIC is
implemented by setting the 'save' attribute and no distinction is made
from SAVE. Parser support for these attributes is enabled only with
the new compile flag -fdec-static.
Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
and critique welcome. Ok for trunk?
P.S. Historical note: a user of some legacy code pointed out to me
that some other compilers allow the AUTOMATIC attribute to be
specified for variables in an EQUIVALENCE, and that some legacy code
contains usages of such. As one of my primary goals is (unfortunately)
to provide support for legacy code I debated whether to allow this. In
the end I restricted this combination for several reasons. Firstly,
F95§5.5.1 states "... an equivalence object shall not be... an
automatic object...". This is a less convincing reason, since the
AUTOMATIC/STATIC attributes are already non-standard, and implement
non-standard behavior, but GNU Fortran in implementing the standard
will follow this behavior. Thus implementing an "automatic
equivalence" variable would potentially be non-trivial and have
strange consequences in the first place. Furthermore, I have found
empirically that other compilers which accept the combination
syntactically still specify in documentation that the combination is
illegal, and the implementation is unpredictable. So AUTOMATIC +
EQUIVALENCE seems like something to be fixed in user code.
---
Fritz Reese
08-17-2016 Fritz Reese
gcc/fortran/
* lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
* options.c (set_dec_flags): Set -fdec-static with -fdec.
* gfortran.h (symbol_attribute): New attribute AUTOMATIC.
* gfortran.h (gfc_add_automatic): New prototype.
* match.h (gfc_match_automatic, gfc_match_static): New functions.
* decl.c (gfc_match_automatic, gfc_match_static): Ditto.
* symbol.c (gfc_add_automatic): Ditto.
* decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
* parse.c (decode_specification_statement, decode_statement): Ditto.
* resolve.c (apply_default_init_local, resolve_fl_variable_derived,
resolve_symbol): Support for automatic attribute.
* symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
Ditto.
* trans-decl.c (gfc_finish_var_decl): Ditto.
gcc/testsuite/gfortran.dg/
* dec_static_1.f90, dec_static_2.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..db431dd 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
d = DECL_ASYNCHRONOUS;
}
break;
+
+case 'u':
+ if (match_string_p ("tomatic"))
+{
+ /* Matched "automatic". */
+ d = DECL_AUTOMATIC;
+}
+ break;
}
break;
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
break;
case 's':
- if (match_string_p ("save"))
- d = DECL_SAVE;
+ gfc_next_ascii_char ();
+ switch (gfc_next_ascii_char ())
+
Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
Minor correction to the previously submitted patch:
On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote:
> ...
> Note that AUTOMATIC does NOT override -fno-automatic; with the flag, a
> warning is produced for variables marked AUTOMATIC.
> ...
This statement was true for a previous version of this patch, but I
had changed the behavior and this is now incorrect. AUTOMATIC
attributes _do_ override -fno-automatic. I also submitted a slightly
older version of the patch file, which contained two errors. This
re-submission fixes these two artifacts; (1) Rename dec_static_*.for
-> dec_static-*.f90; and (2) fix a comment in the second test case:
--- a/gcc/testsuite/gfortran.dg/dec_static_2.f90
+++ b/gcc/testsuite/gfortran.dg/dec_static_2.f90
@@ -1,9 +1,7 @@
! { dg-do run }
! { dg-options "-fdec-static -fno-automatic -finit-local-zero" }
!
-! Make sure a warning is produced when variables marked AUTOMATIC
-! cannot be automatic due to compilation with -fno-automatic, and
-! that they are in fact still saved.
+! Test STATIC and AUTOMATIC with -fno-automatic and recursive subroutines.
!
The attached patch is the CORRECT version that I intend to commit.
Sorry for the mixup.
> Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
> and critique welcome. Ok for trunk?
---
Fritz Reese
> 08-17-2016 Fritz Reese
>
> gcc/fortran/
> * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
> * options.c (set_dec_flags): Set -fdec-static with -fdec.
> * gfortran.h (symbol_attribute): New attribute AUTOMATIC.
> * gfortran.h (gfc_add_automatic): New prototype.
> * match.h (gfc_match_automatic, gfc_match_static): New functions.
> * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
> * symbol.c (gfc_add_automatic): Ditto.
> * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
> * parse.c (decode_specification_statement, decode_statement): Ditto.
> * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
> resolve_symbol): Support for automatic attribute.
> * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
> Ditto.
> * trans-decl.c (gfc_finish_var_decl): Ditto.
>
> gcc/testsuite/gfortran.dg/
> * dec_static_1.f90, dec_static_2.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..db431dd 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
d = DECL_ASYNCHRONOUS;
}
break;
+
+case 'u':
+ if (match_string_p ("tomatic"))
+{
+ /* Matched "automatic". */
+ d = DECL_AUTOMATIC;
+}
+ break;
}
break;
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
break;
case 's':
- if (match_string_p ("save"))
- d = DECL_SAVE;
+ gfc_next_ascii_char ();
+ switch (gfc_next_ascii_char ())
+{
+ case 'a':
+if (match_string_p ("ve"))
+ {
+/* Matched "save". */
+d = DECL_SAVE;
+ }
+break;
+
+ case 't':
+if (match_string_p ("atic"))
+ {
+/* Matched "static". */
+d = DECL_STATIC;
+ }
+break;
+}
break;
case 't':
@@ -4124,6 +4150,12 @@ match_attr_spec (void)
case DECL_SAVE:
attr = "SAVE";
break;
+ case DECL_STATIC:
+attr = "STATIC";
+break;
+ case DECL_AUTOMATIC:
+attr = "AUTOMATIC";
+break;
case DECL_TARGET:
attr = "TARGET";
break;
@@ -4152,6 +4184,18 @@ match_attr_spec (void)
if (seen[d] == 0)
continue;
+ if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
+ && !flag_dec_static)
+{
+ gfc_error ("%s at %L is a DEC extension
[committed] Re: Bug in DEC UNION/STRUCT patch
On Mon, Aug 22, 2016 at 5:22 PM, Steve Kargl
wrote:
> Fritz,
>
> I was lookng at part of a previous patch that I committed for you.
> In interface.c, one now has
>
> static int
> compare_components (gfc_component *cmp1, gfc_component *cmp2,
> gfc_symbol *derived1, gfc_symbol *derived2)
> {
> gfc_symbol *d1, *d2;
> bool anonymous = false;
>
> /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
> which should not be compared. */
> d1 = cmp1->ts.u.derived;
> d2 = cmp2->ts.u.derived;
> if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
> && ISUPPER (cmp1->name[1]))
> || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
> && ISUPPER (cmp1->name[1])))
> anonymous = true;
>
> Is the second ISUPPER suppose to have cmp2->name[1]?
>
> --
> Steve
This above is pretty clearly a typo. The attached patch committed as
obvious r239706.
---
Fritz Reese
2016-08-23 Fritz Reese
gcc/fortran/
* interface.c (compare_components): Fix typo in name check conditional.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 5bd1279..17500c9 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -403,7 +403,7 @@ compare_components (gfc_component *cmp1, gfc_component *cmp2,
if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
&& ISUPPER (cmp1->name[1]))
|| (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
- && ISUPPER (cmp1->name[1])))
+ && ISUPPER (cmp2->name[1])))
anonymous = true;
if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
[committed] Fix for multiple anonymous structures conflict with -fdec-structure
Found another silly typo in my structure/union patch.
With anonymous nested structures, as with unions and maps (which are
inherently anonymous), a static counter is used to give each type
definition a unique name. Due to a typo the counter for anonymous
structures was not static, therefore was simply zero for each
invocation of decl.c (gfc_match_structure_decl). Thus only one
anonymous structure declaration could be used per program, as multiple
anonymous structure definitions would be given the same name, causing
the compiler to complain about conflicting type definitions.
Committed the attached as obvious as r239709 - includes testcase
exhibiting the regression.
---
Fritz Reese
2016-08-23 Fritz Reese
gcc/fortran/
* decl.c (gfc_match_structure_decl): Make gfc_structure_id static.
gcc/testsuite/gfortran.dg/
* dec_structure_12.f90: New testcase.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 66158b9..24bd374 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -8626,7 +8626,7 @@ match
gfc_match_structure_decl (void)
{
/* Counter used to give unique internal names to anonymous structures. */
-int gfc_structure_id = 0;
+static unsigned int gfc_structure_id = 0;
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym;
match m;
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_12.f90 b/gcc/testsuite/gfortran.dg/dec_structure_12.f90
new file mode 100644
index 000..b6cc5aa
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_structure_12.f90
@@ -0,0 +1,27 @@
+! { dg-do "compile" }
+! { dg-options "-fdec-structure" }
+!
+! Test a regression where multiple anonymous structures failed to
+! receive unique internal names.
+!
+
+implicit none
+
+structure /s/
+
+ structure record0 ! (2)
+integer i
+ end structure
+
+ structure record1 ! regression: Type definition was already defined at (2)
+real r
+ end structure
+
+end structure
+
+record /s/ var
+
+var.record0.i = 0
+var.record1.r = 0.0
+
+end
Re: [committed] Re: Bug in DEC UNION/STRUCT patch
On Tue, Aug 23, 2016 at 12:22 PM, Dominique d'Humières wrote: >> This above is pretty clearly a typo. The attached patch committed as >> obvious r239706. > Could you please provide a test failing before r239706 and succeeding after > it? > I will work on that - it seems to be harder to exhibit this issue than I would've thought. I'm finding myself reconsidering this piece of the original patch and its implications. In related news, I found and fixed another bug while attempting to exhibit this bug: https://gcc.gnu.org/ml/fortran/2016-08/msg00126.html --- Fritz Reese
Re: Ping! Re: [PATCH, Fortran] New flag -finit-derived to initialize components of derived types
On Tue, Aug 23, 2016 at 4:53 PM, Gerald Pfeifer wrote: > On Mon, 15 Aug 2016, Thomas Koenig wrote: >> @Gerald: Will a gcc-7/changes.html file be generated? If so, we should >> document this new flag (and others...) > > Yes, please! Segher beat me to it today, sorry for the delay, and > thanks for thinking of our release notes. > > Let me know if you need any help. I would be happy to document my new flags (I have added several) in upcoming release notes or applicable documents - however I do not know where or how. --- Fritz Reese
[PATCH, Fortran] Fix compare logic for anonymous structure types
name[2]
> && derived1->name[1] == (char) TOUPPER (derived1->name[0])
> && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
(snip)
With the patch, duplicate structure definitions containing anonymous
elements will appropriately be resolved to use the same backend tree
declarations. You can see the clarified conditions for n name
comparison in the new functions in interface.c is_anonymous_component
and is_anonymous_dt. This also helps abstract the condition, if one
were to change the implementation of anonymous names in the future.
tl;dr: The attached patch fixes PR 77327 and another bug which is
demonstrated in the included testcase. The replacement code is also
easier to understand and more maintainable than the original.
Bootstraps and regtests on x86_64-redhat-linux. Since it is a change
to my previously submitted code I'll aim to commit to trunk over the
weekend if there are no concerns by then.
As a side note, I actually don't know how to exhibit PR 77327 in a
DejaGNU testcase, since it is a normally-silent heap-use-after-free
which was only found with a memory checker. I would appreciate any
advice on this matter so I can include a testcase for it with this
commit.
---
Fritz Reese
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 17500c9..ffc36f5 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -387,26 +387,46 @@ gfc_match_end_interface (void)
}
+/* Return whether the component was defined anonymously. */
+
+static bool
+is_anonymous_component (gfc_component *cmp)
+{
+ /* Only UNION and MAP components are anonymous. In the case of a MAP,
+ the derived type symbol is FL_STRUCT and the component name looks like mM*.
+ This is the only case in which the second character of a component name is
+ uppercase. */
+ return cmp->ts.type == BT_UNION
+|| (cmp->ts.type == BT_DERIVED
+&& cmp->ts.u.derived->attr.flavor == FL_STRUCT
+&& cmp->name[0] && cmp->name[1] && ISUPPER (cmp->name[1]));
+}
+
+
+/* Return whether the derived type was defined anonymously. */
+
+static bool
+is_anonymous_dt (gfc_symbol *derived)
+{
+ /* UNION and MAP types are always anonymous. Otherwise, only nested STRUCTURE
+ types can be anonymous. For anonymous MAP/STRUCTURE, we have FL_STRUCT
+ and the type name looks like XX*. This is the only case in which the
+ second character of a type name is uppercase. */
+ return derived->attr.flavor == FL_UNION
+|| (derived->attr.flavor == FL_STRUCT
+&& derived->name[0] && derived->name[1] && ISUPPER (derived->name[1]));
+}
+
+
/* Compare components according to 4.4.2 of the Fortran standard. */
static int
compare_components (gfc_component *cmp1, gfc_component *cmp2,
gfc_symbol *derived1, gfc_symbol *derived2)
{
- gfc_symbol *d1, *d2;
- bool anonymous = false;
-
- /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
- which should not be compared. */
- d1 = cmp1->ts.u.derived;
- d2 = cmp2->ts.u.derived;
- if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
- && ISUPPER (cmp1->name[1]))
- || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
- && ISUPPER (cmp2->name[1])))
-anonymous = true;
-
- if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
+ /* Compare names, but not for anonymous components such as UNION or MAP. */
+ if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp1)
+ && strcmp (cmp1->name, cmp2->name) != 0)
return 0;
if (cmp1->attr.access != cmp2->attr.access)
@@ -512,22 +532,12 @@ int
gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
{
gfc_component *cmp1, *cmp2;
- bool anonymous = false;
if (derived1 == derived2)
return 1;
gcc_assert (derived1 && derived2);
- /* MAP and anonymous STRUCTURE types have internal names of the form
- mM* and sS* (we can get away this this because source names are converted
- to lowerase). Compare anonymous type names specially because each
- gets a unique name when it is declared. */
- anonymous = (derived1->name[0] == derived2->name[0]
- && derived1->name[1] && derived2->name[1] && derived2->name[2]
- && derived1->name[1] == (char) TOUPPER (derived1->name[0])
- && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
-
/* Special case for comparing derived types across namespaces. If the
true names and module names are the same and the module name is
nonnull, then they are equal. */
@@ -541,7 +551,9 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derive
Re: [PATCH, Fortran] Fix compare logic for anonymous structure types
https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html
On Wed, Aug 24, 2016 at 5:14 PM, Fritz Reese wrote:
> With a few recent notes by others, I have identified that the
> comparison logic I used in interface.c (compare_components,
> gfc_compare_derived_types) was faulty in a few ways.
(snip)
> tl;dr: The attached patch fixes PR 77327 and another bug which is
> demonstrated in the included testcase.
Minor correction to a typo in the patch above - should be checking
cmp1 and cmp2 not cmp1 and cmp1:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index ffc36f5..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -425,7 +425,7 @@ compare_components (gfc_component *cmp1, gfc_component *cmp2
gfc_symbol *derived1, gfc_symbol *derived2)
{
/* Compare names, but not for anonymous components such as UNION or MAP. */
- if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp1)
+ if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
&& strcmp (cmp1->name, cmp2->name) != 0)
return 0;
---
Fritz Reese
2016-08-24 Fritz Reese
PR fortran/77327
gcc/fortran/
* interface.c (is_anonymous_component, is_anonymous_dt): New functions.
* interface.c (compare_components, gfc_compare_derived_types): Use new
functions.
gcc/testsuite/gfortran.dg/
* dec_structure_13.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 17500c9..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -387,26 +387,46 @@ gfc_match_end_interface (void)
}
+/* Return whether the component was defined anonymously. */
+
+static bool
+is_anonymous_component (gfc_component *cmp)
+{
+ /* Only UNION and MAP components are anonymous. In the case of a MAP,
+ the derived type symbol is FL_STRUCT and the component name looks like mM*.
+ This is the only case in which the second character of a component name is
+ uppercase. */
+ return cmp->ts.type == BT_UNION
+|| (cmp->ts.type == BT_DERIVED
+&& cmp->ts.u.derived->attr.flavor == FL_STRUCT
+&& cmp->name[0] && cmp->name[1] && ISUPPER (cmp->name[1]));
+}
+
+
+/* Return whether the derived type was defined anonymously. */
+
+static bool
+is_anonymous_dt (gfc_symbol *derived)
+{
+ /* UNION and MAP types are always anonymous. Otherwise, only nested STRUCTURE
+ types can be anonymous. For anonymous MAP/STRUCTURE, we have FL_STRUCT
+ and the type name looks like XX*. This is the only case in which the
+ second character of a type name is uppercase. */
+ return derived->attr.flavor == FL_UNION
+|| (derived->attr.flavor == FL_STRUCT
+&& derived->name[0] && derived->name[1] && ISUPPER (derived->name[1]));
+}
+
+
/* Compare components according to 4.4.2 of the Fortran standard. */
static int
compare_components (gfc_component *cmp1, gfc_component *cmp2,
gfc_symbol *derived1, gfc_symbol *derived2)
{
- gfc_symbol *d1, *d2;
- bool anonymous = false;
-
- /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
- which should not be compared. */
- d1 = cmp1->ts.u.derived;
- d2 = cmp2->ts.u.derived;
- if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
- && ISUPPER (cmp1->name[1]))
- || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
- && ISUPPER (cmp2->name[1])))
-anonymous = true;
-
- if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
+ /* Compare names, but not for anonymous components such as UNION or MAP. */
+ if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
+ && strcmp (cmp1->name, cmp2->name) != 0)
return 0;
if (cmp1->attr.access != cmp2->attr.access)
@@ -512,22 +532,12 @@ int
gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
{
gfc_component *cmp1, *cmp2;
- bool anonymous = false;
if (derived1 == derived2)
return 1;
gcc_assert (derived1 && derived2);
- /* MAP and anonymous STRUCTURE types have internal names of the form
- mM* and sS* (we can get away this this because source names are converted
- to lowerase). Compare anonymous type names specially because each
- gets a unique name when it is declared. */
- anonymous = (derived1->name[0] == derived2->name[0]
- && derived1->name[1] && derived2->name[1] && derived2->name[2]
- && derived1->name[1] == (char) TOUPPER (derived1->name[0])
- && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
-
/* Special case for comparing derived types across na
Re: [PATCH] PR fortran/77372
On Thu, Aug 25, 2016 at 6:13 PM, Steve Kargl
wrote:
> I plan to commit the following patch on Saturday if
> no one objects in the next 40 or so hours.
>
> 2016-08-25 Steven G. Kargl
>
> PR fortran/77372
> simplify.c (simplify_ieee_selected_real_kind): Check for NULL
> pointers.
>
> 2016-08-25 Steven G. Kargl
>
> PR fortran/77372
> gfortran.dg/pr77372.f90: New test.
>
> Index: gcc/fortran/simplify.c
> ===
> --- gcc/fortran/simplify.c (revision 239762)
> +++ gcc/fortran/simplify.c (working copy)
> @@ -7044,9 +7044,19 @@ gfc_simplify_compiler_version (void)
> gfc_expr *
> simplify_ieee_selected_real_kind (gfc_expr *expr)
> {
> - gfc_actual_arglist *arg = expr->value.function.actual;
> - gfc_expr *p = arg->expr, *q = arg->next->expr,
> - *rdx = arg->next->next->expr;
> + gfc_actual_arglist *arg;
> + gfc_expr *p = NULL, *q = NULL, *rdx = NULL;
> +
> + arg = expr->value.function.actual;
> + if (arg->expr)
> +p = arg->expr;
> + if (arg->next)
> +{
> + if (arg->next->expr)
> + q = arg->next->expr;
> + if (arg->next->next && arg->next->next->expr)
> + rdx = arg->next->next->expr;
> +}
>
(snip)
Technically there are three superfluous conditions. The following is equivalent:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 8096a92..a3d42e1 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7045,8 +7045,15 @@ gfc_expr *
simplify_ieee_selected_real_kind (gfc_expr *expr)
{
- gfc_actual_arglist *arg = expr->value.function.actual;
- gfc_expr *p = arg->expr, *q = arg->next->expr,
- *rdx = arg->next->next->expr;
+ gfc_actual_arglist *arg;
+ gfc_expr *p = NULL, *q = NULL, *rdx = NULL;
+
+ arg = expr->value.function.actual;
+ p = arg->expr;
+ if (arg->next)
+ {
+q = arg->next->expr;
+if (arg->next->next)
+ rdx = arg->next->next->expr;
+ }
/* Currently, if IEEE is supported and this module is built, it means
all our floating-point types conform to IEEE. Hence, we simply handle
[committed] Re: [PATCH, Fortran] Fix compare logic for anonymous structure types
https://gcc.gnu.org/ml/fortran/2016-08/msg00145.html
On Wed, Aug 24, 2016 at 5:32 PM, Fritz Reese wrote:
> https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html
>
> On Wed, Aug 24, 2016 at 5:14 PM, Fritz Reese wrote:
>> With a few recent notes by others, I have identified that the
>> comparison logic I used in interface.c (compare_components,
>> gfc_compare_derived_types) was faulty in a few ways.
> (snip)
>> tl;dr: The attached patch fixes PR 77327 and another bug which is
>> demonstrated in the included testcase.
FYI-
Committed the patch (as attached) as r239819. Note that PR 77327 is
exhibited by the existing testcase gfortran.dg/import4.f90.
Nb. there was one final typo fixed before committing since the
previously posted version:
>>>>
--- a/gcc/testsuite/gfortran.dg/dec_structure_13.f90
+++ b/gcc/testsuite/gfortran.dg/dec_structure_13.f90
@@ -37,7 +37,7 @@ subroutine sub1 ()
call sub0(u) ! regression: Type mismatch in argument
end subroutine
-subroutine sub3(u)
+subroutine sub2(u)
structure /tu/
union
map
<<<<
---
Fritz Reese
2016-08-29 Fritz Reese
Fix, reorganize, and clarify comparisons of anonymous types/components.
PR fortran/77327
* interface.c (is_anonymous_component, is_anonymous_dt): New functions.
* interface.c (compare_components, gfc_compare_derived_types): Use new
functions.
* gfortran.dg/dec_structure_13.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 17500c9..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -387,26 +387,46 @@ gfc_match_end_interface (void)
}
+/* Return whether the component was defined anonymously. */
+
+static bool
+is_anonymous_component (gfc_component *cmp)
+{
+ /* Only UNION and MAP components are anonymous. In the case of a MAP,
+ the derived type symbol is FL_STRUCT and the component name looks like mM*.
+ This is the only case in which the second character of a component name is
+ uppercase. */
+ return cmp->ts.type == BT_UNION
+|| (cmp->ts.type == BT_DERIVED
+&& cmp->ts.u.derived->attr.flavor == FL_STRUCT
+&& cmp->name[0] && cmp->name[1] && ISUPPER (cmp->name[1]));
+}
+
+
+/* Return whether the derived type was defined anonymously. */
+
+static bool
+is_anonymous_dt (gfc_symbol *derived)
+{
+ /* UNION and MAP types are always anonymous. Otherwise, only nested STRUCTURE
+ types can be anonymous. For anonymous MAP/STRUCTURE, we have FL_STRUCT
+ and the type name looks like XX*. This is the only case in which the
+ second character of a type name is uppercase. */
+ return derived->attr.flavor == FL_UNION
+|| (derived->attr.flavor == FL_STRUCT
+&& derived->name[0] && derived->name[1] && ISUPPER (derived->name[1]));
+}
+
+
/* Compare components according to 4.4.2 of the Fortran standard. */
static int
compare_components (gfc_component *cmp1, gfc_component *cmp2,
gfc_symbol *derived1, gfc_symbol *derived2)
{
- gfc_symbol *d1, *d2;
- bool anonymous = false;
-
- /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
- which should not be compared. */
- d1 = cmp1->ts.u.derived;
- d2 = cmp2->ts.u.derived;
- if ( (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
- && ISUPPER (cmp1->name[1]))
- || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
- && ISUPPER (cmp2->name[1])))
-anonymous = true;
-
- if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
+ /* Compare names, but not for anonymous components such as UNION or MAP. */
+ if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
+ && strcmp (cmp1->name, cmp2->name) != 0)
return 0;
if (cmp1->attr.access != cmp2->attr.access)
@@ -512,22 +532,12 @@ int
gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
{
gfc_component *cmp1, *cmp2;
- bool anonymous = false;
if (derived1 == derived2)
return 1;
gcc_assert (derived1 && derived2);
- /* MAP and anonymous STRUCTURE types have internal names of the form
- mM* and sS* (we can get away this this because source names are converted
- to lowerase). Compare anonymous type names specially because each
- gets a unique name when it is declared. */
- anonymous = (derived1->name[0] == derived2->name[0]
- && derived1->name[1] && derived2->name[1] && derived2->name[2]
- && derived1->name[1] == (char) TOUPPER (derived1->name[0])
- && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
-
/* Special case for comparing de
Ping! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote: > This patch extends the GNU Fortran front-end to add support for > DEC-style AUTOMATIC and STATIC symbol attributes with a new flag > -fdec-static, allowing explicit control of variable storage. AUTOMATIC > local variables are placed on the stack, whereas STATIC variables are > placed in static storage. Patch still pending review. > Bootstraps and regtests on x86_64-redhat-linux. Questions, comments, > and critique welcome. Ok for trunk? ... > > 08-17-2016 Fritz Reese > > gcc/fortran/ > * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static. > * options.c (set_dec_flags): Set -fdec-static with -fdec. > * gfortran.h (symbol_attribute): New attribute AUTOMATIC. > * gfortran.h (gfc_add_automatic): New prototype. > * match.h (gfc_match_automatic, gfc_match_static): New functions. > * decl.c (gfc_match_automatic, gfc_match_static): Ditto. > * symbol.c (gfc_add_automatic): Ditto. > * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls. > * parse.c (decode_specification_statement, decode_statement): Ditto. > * resolve.c (apply_default_init_local, resolve_fl_variable_derived, > resolve_symbol): Support for automatic attribute. > * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic): > Ditto. > * trans-decl.c (gfc_finish_var_decl): Ditto. > > gcc/testsuite/gfortran.dg/ > * dec_static_1.f90, dec_static_2.f90: New testcases. --- Fritz Reese
[committed] Small documentation fix to STRUCTURE
Committed as obvious as r239862, this fixes a "rebase-o" ("typo during
rebase") that found its way into the documentation on STRUCTURE which
is clearly incorrect:
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (revision 239861)
+++ gcc/fortran/gfortran.texi (working copy)
@@ -2127,9 +2127,10 @@ be disabled using -std=legacy.
@cindex @code{RECORD}
Record structures are a pre-Fortran-90 vendor extension to create
-user-defined aggregate data types. GNU Fortran does not support
-record structures, only Fortran 90's ``derived types'', which have
-a different syntax.
+user-defined aggregate data types. Support for record structures in GNU
+Fortran can be enabled with the @option{-fdec-structure} compile flag.
+If you have a choice, you should instead use Fortran 90's ``derived types'',
+which have a different syntax.
In many cases, record structures can easily be converted to derived types.
To convert, replace @code{STRUCTURE /}@var{structure-name}@code{/}
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (revision 239861)
+++ gcc/fortran/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-08-30 Fritz Reese
+
+ * gfortran.texi: Fix typo in STRUCTURE documentation.
+
2016-08-29 Fritz Reese
Fix, reorganize, and clarify comparisons of anonymous types/components.
---
Fritz Reese
Ping**2! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
https://gcc.gnu.org/ml/fortran/2016-08/msg00173.html On Mon, Aug 29, 2016 at 8:36 AM, Fritz Reese wrote: > > https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html > On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote: > > This patch extends the GNU Fortran front-end to add support for > > DEC-style AUTOMATIC and STATIC symbol attributes with a new flag > > -fdec-static, allowing explicit control of variable storage. AUTOMATIC > > local variables are placed on the stack, whereas STATIC variables are > > placed in static storage. > > Patch still pending review. > > > Bootstraps and regtests on x86_64-redhat-linux. Questions, comments, > > and critique welcome. Ok for trunk? > ... > > > > 08-17-2016 Fritz Reese > > > > gcc/fortran/ > > * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static. > > * options.c (set_dec_flags): Set -fdec-static with -fdec. > > * gfortran.h (symbol_attribute): New attribute AUTOMATIC. > > * gfortran.h (gfc_add_automatic): New prototype. > > * match.h (gfc_match_automatic, gfc_match_static): New functions. > > * decl.c (gfc_match_automatic, gfc_match_static): Ditto. > > * symbol.c (gfc_add_automatic): Ditto. > > * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls. > > * parse.c (decode_specification_statement, decode_statement): Ditto. > > * resolve.c (apply_default_init_local, resolve_fl_variable_derived, > > resolve_symbol): Support for automatic attribute. > > * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic): > > Ditto. > > * trans-decl.c (gfc_finish_var_decl): Ditto. > > > > gcc/testsuite/gfortran.dg/ > > * dec_static_1.f90, dec_static_2.f90: New testcases. > --- Fritz Reese
Re: Ping**2! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
list in AUTOMATIC statement at %C");
return MATCH_ERROR;
}
... And similar for gfc_match_static. (Nb. "entity-list" was chosen to
correspond with the "save-entity-list" descriptor used by F90 to
specify the SAVE statement.)
Andre, thanks again for your comments. I hope the attached patch is
acceptable for trunk; now pending official review once again.
---
Fritz Reese
2016-09-07 Fritz Reese
Support for AUTOMATIC and STATIC attributes with new flag -fdec-static.
gcc/fortran/
* lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
* options.c (set_dec_flags): Set -fdec-static with -fdec.
* gfortran.h (symbol_attribute): New attribute automatic.
* gfortran.h (gfc_add_automatic): New prototype.
* match.h (gfc_match_automatic, gfc_match_static): New functions.
* decl.c (gfc_match_automatic, gfc_match_static): Ditto.
* symbol.c (gfc_add_automatic): Ditto.
* decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
* parse.c (decode_specification_statement, decode_statement): Ditto.
* resolve.c (apply_default_init_local, resolve_fl_variable_derived,
resolve_symbol): Support for automatic attribute.
* symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
Ditto.
* trans-decl.c (gfc_finish_var_decl): Ditto.
gcc/testsuite/gfortran.dg/
* dec_static_1.f90, dec_static_2.f90, dec_static_3.f90,
dec_static_4.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..be8e9f7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
d = DECL_ASYNCHRONOUS;
}
break;
+
+ case 'u':
+ if (match_string_p ("tomatic"))
+ {
+ /* Matched "automatic". */
+ d = DECL_AUTOMATIC;
+ }
+ break;
}
break;
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
break;
case 's':
- if (match_string_p ("save"))
- d = DECL_SAVE;
+ gfc_next_ascii_char ();
+ switch (gfc_next_ascii_char ())
+ {
+ case 'a':
+ if (match_string_p ("ve"))
+ {
+ /* Matched "save". */
+ d = DECL_SAVE;
+ }
+ break;
+
+ case 't':
+ if (match_string_p ("atic"))
+ {
+ /* Matched "static". */
+ d = DECL_STATIC;
+ }
+ break;
+ }
break;
case 't':
@@ -4124,6 +4150,12 @@ match_attr_spec (void)
case DECL_SAVE:
attr = "SAVE";
break;
+ case DECL_STATIC:
+ attr = "STATIC";
+ break;
+ case DECL_AUTOMATIC:
+ attr = "AUTOMATIC";
+ break;
case DECL_TARGET:
attr = "TARGET";
break;
@@ -4152,6 +4184,18 @@ match_attr_spec (void)
if (seen[d] == 0)
continue;
+ if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
+ && !flag_dec_static)
+ {
+ gfc_error ("%s at %L is a DEC extension, enable with -fdec-static",
+ d == DECL_STATIC ? "STATIC" : "AUTOMATIC", &seen_at[d]);
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+ /* Allow SAVE with STATIC, but don't complain. */
+ if (d == DECL_STATIC && seen[DECL_SAVE])
+ continue;
+
if (gfc_current_state () == COMP_DERIVED
&& d != DECL_DIMENSION && d != DECL_CODIMENSION
&& d != DECL_POINTER && d != DECL_PRIVATE
@@ -4290,10 +4334,15 @@ match_attr_spec (void)
&seen_at[d]);
break;
+ case DECL_STATIC:
case DECL_SAVE:
t = gfc_add_save (¤t_attr, SAVE_EXPLICIT, NULL, &seen_at[d]);
break;
+ case DECL_AUTOMATIC:
+ t = gfc_add_automatic (¤t_attr, NULL, &seen_at[d]);
+ break;
+
case DECL_TARGET:
t = gfc_add_target (¤t_attr, &seen_at[d]);
break;
@@ -7767,6 +7816,114 @@ gfc_match_parameter (void)
}
+match
+gfc_match_automatic (void)
+{
+ gfc_symbol *sym;
+ match m;
+ bool seen_symbol = false;
+
+ if (!flag_dec_static)
+{
+ gfc_error ("AUTOMATIC at %C is a DEC extension, enable with "
+ "-fdec-static");
+ return MATCH_ERROR;
+}
+
+ gfc_match (" ::");
+
+ for (;;)
+{
+ m = gfc_match_symbol (&sym, 0);
+ switch (m)
+ {
+ case MATCH_NO:
+break;
+
+ case MATCH_ERROR:
+ return MATCH_ERR
[PATCH, Fortran] PR71523 - Static variables given automatic initializers with -finit-* and -fmax-stack-var-size
RE: https://gcc.gnu.org/ml/fortran/2016-06/msg00023.html On Thu, Jun 9, 2016 at 2:01 PM, Fritz Reese wrote: > It looks like when -fautomatic and -finit-local-zero are set with > -fmax-stack-var-size=X, an automatic initializer is generated even for > variables larger than X which are given static storage, causing such > static variables to have their value re-initialized upon each entry to > their namespace. > ... After doing more research I noticed PR41860 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860) was very similar to this issue, so I've decided this is a bug and created PR71523 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71523). Here's a patch for it. The bug seems to be due to an oversight - since the size of a variable is not known at resolution time when initializer expressions are applied, -finit-* is too greedy in the case that the variable is large enough to be removed from the stack according to -fmax-stack-var-size. This patch removes automatic initializers at translation time which were inserted by -finit-* (and inserts the appropriate static initializer) according to -fmax-stack-var-size. The patch passes all regression tests (on x86_64-redhat-linux), including the two additional tests of its own demonstrating the issue. --- Fritz Reese 0001-PR-Fortran-71523.patch Description: Binary data
[PATCH, Fortran, committed] PR82511: ICE Bad IO basetype (12) on attempted read or write of entire DEC structure
All,
The simple attached patch which fixes PR 82511 has been committed to
trunk as r253791. It regtests on x86_64-redhat-linux-gnu.
The issue was an ICE when a variable containing a BT_UNION (basetype
12) component was given in a I/O list. The patch treats the BT_UNION
component as a derived type variable, thus recursing into its final
components (across all of its MAPs).
---
Fritz Reese
From 89ed92f0127b61bc802e43c8f3125f48540d7c27 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 16 Oct 2017 13:27:28 -0400
Subject: [PATCH] Treat UNION components as DT comp. in I/O lists.
PR fortran/82511
gcc/fortran/
* trans-io.c (transfer_expr): Treat BT_UNION as BT_DERIVED.
PR fortran/82511
gcc/testsuite/gfortran.dg/
* dec_structure_22.f90: New testcase.
---
gcc/fortran/trans-io.c | 4 +--
gcc/testsuite/gfortran.dg/dec_structure_22.f90 | 38 ++
2 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_22.f90
diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 026f9a993d2..f3e1f3e4d09 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -2404,7 +2404,7 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree addr_expr,
case BT_CLASS:
if (ts->u.derived->components == NULL)
return;
- if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
+ if (gfc_bt_struct (ts->type) || ts->type == BT_CLASS)
{
gfc_symbol *derived;
gfc_symbol *dtio_sub = NULL;
@@ -2438,7 +2438,7 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree addr_expr,
function = iocall[IOCALL_X_DERIVED];
break;
}
- else if (ts->type == BT_DERIVED)
+ else if (gfc_bt_struct (ts->type))
{
/* Recurse into the elements of the derived type. */
expr = gfc_evaluate_now (addr_expr, &se->pre);
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_22.f90 b/gcc/testsuite/gfortran.dg/dec_structure_22.f90
new file mode 100644
index 000..ddbee02602a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_structure_22.f90
@@ -0,0 +1,38 @@
+ ! { dg-do run }
+ ! { dg-options "-fdec-structure" }
+ !
+ ! PR fortran/82511
+ !
+ ! Verify that structure variables with UNION components
+ ! are accepted in an I/O-list READ.
+ !
+ implicit none
+
+ structure /s/
+union
+ map
+character(16) :: c16_1
+ end map
+ map
+character(16) :: c16_2
+ end map
+end union
+ end structure
+
+ record /s/ r
+ character(32) :: instr = "ABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^"
+
+ r.c16_1 = ''
+ r.c16_2 = ''
+ ! The record r shall be treated as if its components are listed:
+ ! read(...) r.c16_1, r.c16_2
+ ! This shall correspond to the formatted read of A16,A16
+ read(instr, '(A16,A16)') r
+
+ ! r.c16_1 and r.c16_2 are in a union, thus share the same memory
+ ! and the first 16 bytes of instr are overwritten
+ if ( r.c16_1 .ne. instr(17:32) .or. r.c16_2 .ne. instr(17:32) ) then
+call abort()
+ endif
+
+ end
--
2.12.2
[PATCH, Fortran] Correctly set -fd-lines-as-comments with -fdec
All,
This is a simple patch. The original intent was for -fdec to set
-fd-lines-as-comments by default if flag_d_lines was unspecified by
the user. However, currently flag_d_lines is interrogated in
set_dec_flags(), usually before its final value is determined. The
attached patch fixes this behavior to work as intended.
Any objections for trunk? If not I think it is safe to commit.
---
Fritz Reese
>From e2761d73e818a5095bcc130ddbafe27022e25ba6 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 12:46:10 -0400
Subject: [PATCH] Correctly set -fd-lines-as-comments with -fdec
gcc/fortran/
* options.c (set_dec_flags, gfc_post_options): Set flag_d_lines
with -fdec when not set by user.
gcc/testsuite/gfortran.dg/
* dec_d_lines_1.f, dec_d_lines_2.f: New.
From e2761d73e818a5095bcc130ddbafe27022e25ba6 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 12:46:10 -0400
Subject: [PATCH] Don't override -fd-lines-as-code with -fdec.
gcc/fortran/
* options.c (set_dec_flags, gfc_post_options): Only set flag_d_lines
with -fdec when not set by user.
gcc/testsuite/gfortran.dg/
* dec_d_lines_1.f, dec_d_lines_2.f: New.
---
gcc/fortran/options.c | 14 +-
gcc/testsuite/gfortran.dg/dec_d_lines_1.f | 9 +
gcc/testsuite/gfortran.dg/dec_d_lines_2.f | 8
3 files changed, 26 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_d_lines_1.f
create mode 100644 gcc/testsuite/gfortran.dg/dec_d_lines_2.f
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 1af76aa81ec..8cb861bf513 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -57,9 +57,6 @@ set_dec_flags (int value)
| GFC_STD_GNU | GFC_STD_LEGACY;
gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
- /* Set -fd-lines-as-comments by default. */
- if (value && gfc_current_form != FORM_FREE && gfc_option.flag_d_lines == -1)
-gfc_option.flag_d_lines = 0;
/* Set other DEC compatibility extensions. */
flag_dollar_ok |= value;
@@ -337,8 +334,15 @@ gfc_post_options (const char **pfilename)
diagnostic_classify_diagnostic (global_dc, OPT_Wline_truncation,
DK_ERROR, UNKNOWN_LOCATION);
}
- else if (warn_line_truncation == -1)
-warn_line_truncation = 0;
+ else
+{
+ /* With -fdec, set -fd-lines-as-comments by default in fixed form. */
+ if (flag_dec && gfc_option.flag_d_lines == -1)
+ gfc_option.flag_d_lines = 0;
+
+ if (warn_line_truncation == -1)
+ warn_line_truncation = 0;
+}
/* If -pedantic, warn about the use of GNU extensions. */
if (pedantic && (gfc_option.allow_std & GFC_STD_GNU) != 0)
diff --git a/gcc/testsuite/gfortran.dg/dec_d_lines_1.f b/gcc/testsuite/gfortran.dg/dec_d_lines_1.f
new file mode 100644
index 000..2cc7a01daff
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_d_lines_1.f
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-ffixed-form -fd-lines-as-code -fdec" }
+!
+! Ensure -fd-lines-as-code is not overridden by -fdec.
+!
+ i = 0
+d end
+ subroutine s
+D end
diff --git a/gcc/testsuite/gfortran.dg/dec_d_lines_2.f b/gcc/testsuite/gfortran.dg/dec_d_lines_2.f
new file mode 100644
index 000..31eaf5f2328
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_d_lines_2.f
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-ffixed-form -fdec" }
+!
+! Ensure -fd-lines-as-comments is enabled by default with -fdec.
+!
+d This is a comment.
+D This line, too.
+ end
--
2.12.2
[PATCH, Fortran] Slight cleanup in set_dec_flags
All,
Attached is a trivial patch which exists for posterity: currently
set_dec_flags(int value) enables support for legacy standards and
disables warnings for them etc... Unfortunately it does this
irrespective of the int value parameter. Since set_dec_flags(0) is
called on initialization, the legacy standards are enabled even when
-fdec is not specified on the command-line. However, since
set_dec_flags is called *just before* set_default_std_flags() in
gfc_init_options() the standards are correctly reset to defaults. I
believe a guard around setting the legacy standards from set_dec_flags
to ensure they are only set with value != 0 is appropriate for clarity
and correctness.
I plan to commit to trunk soon if there no objections since the patch
is trivial and does not effectively change compiler behavior at
present.
---
Fritz Reese
>From 805b4909deb450216c1dc522d834173455baca69 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 12:58:30 -0400
Subject: [PATCH] Only set legacy std in set_dec_flags when value!=0 for
posterity
gcc/fortran/
* options.c (set_dec_flags): Only set legacy standards when value
is not zero.
From 805b4909deb450216c1dc522d834173455baca69 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 12:58:30 -0400
Subject: [PATCH] Only set legacy std in set_dec_flags when value!=0 for
posterity
gcc/fortran/
* options.c (set_dec_flags): Only set legacy standards when value
is not zero.
---
gcc/fortran/options.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 8cb861bf513..c2f8b8a9398 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -52,11 +52,13 @@ set_default_std_flags (void)
static void
set_dec_flags (int value)
{
- /* Allow legacy code without warnings. */
- gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
-| GFC_STD_GNU | GFC_STD_LEGACY;
- gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
-
+ if (value)
+{
+ /* Allow legacy code without warnings. */
+ gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
+| GFC_STD_GNU | GFC_STD_LEGACY;
+ gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
+}
/* Set other DEC compatibility extensions. */
flag_dollar_ok |= value;
--
2.12.2
[PATCH, Fortran] Support for legacy %FILL fields in STRUCTUREs
All,
Attached is a patch which extends the DEC STRUCTURE support to include
special fields named '%FILL'. These fields generate anonymous
inaccessible components, commonly used in DEC FORTRAN to control
alignment of fields within STRUCTUREs. The patch is fairly
straightforward. The match is performed during parsing in decl.c
(variable_decl) by generating a component with an internal anonymous
name which is an invalid Fortran identifier to replace any components
specified as '%FILL'.
Regtests on x86_64-redhat-linux. OK for trunk?
---
Fritz Reese
>From a94d1aefe608447ff0de469ca90cbcc4942f6168 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 14:18:25 -0400
Subject: [PATCH] Support for legacy %FILL field in STRUCTUREs.
gcc/fortran/
* decl.c (attr_seen): New static variable.
* decl.c (variable_decl): Match %FILL in STRUCTURE body.
* gfortran.texi: Update documentation.
gcc/testsuite/gfortran.dg/
* dec_structure_18.f90, dec_structure_19.f90, dec_structure_20.f90,
dec_structure_21.f90: New.
---
From a94d1aefe608447ff0de469ca90cbcc4942f6168 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 31 Jul 2017 14:18:25 -0400
Subject: [PATCH] Support for legacy %FILL field in STRUCTUREs.
gcc/fortran/
* decl.c (attr_seen): New static variable.
* decl.c (variable_decl): Match %FILL in STRUCTURE body.
* gfortran.texi: Update documentation.
gcc/testsuite/gfortran.dg/
* dec_structure_18.f90, dec_structure_19.f90, dec_structure_20.f90,
dec_structure_21.f90: New.
---
gcc/fortran/decl.c | 56 +-
gcc/fortran/gfortran.texi | 14 +++
gcc/testsuite/gfortran.dg/dec_structure_18.f90 | 38 +
gcc/testsuite/gfortran.dg/dec_structure_19.f90 | 38 +
gcc/testsuite/gfortran.dg/dec_structure_20.f90 | 18 +
gcc/testsuite/gfortran.dg/dec_structure_21.f90 | 10 +
6 files changed, 172 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_18.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_19.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_20.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_structure_21.f90
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index bd310703557..0c56b4010bc 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -54,6 +54,7 @@ static gfc_typespec current_ts;
static symbol_attribute current_attr;
static gfc_array_spec *current_as;
static int colon_seen;
+static int attr_seen;
/* The current binding label (if any). */
static const char* curr_binding_label;
@@ -2140,6 +2141,7 @@ static match
variable_decl (int elem)
{
char name[GFC_MAX_SYMBOL_LEN + 1];
+ static unsigned int fill_id = 0;
gfc_expr *initializer, *char_len;
gfc_array_spec *as;
gfc_array_spec *cp_as; /* Extra copy for Cray Pointees. */
@@ -2157,9 +2159,47 @@ variable_decl (int elem)
/* When we get here, we've just matched a list of attributes and
maybe a type and a double colon. The next thing we expect to see
is the name of the symbol. */
- m = gfc_match_name (name);
+
+ /* If we are parsing a structure with legacy support, we allow the symbol
+ name to be '%FILL' which gives it an anonymous (inaccessible) name. */
+ m = MATCH_NO;
+ gfc_gobble_whitespace ();
+ if (gfc_peek_ascii_char () == '%')
+{
+ gfc_next_ascii_char ();
+ m = gfc_match ("fill");
+}
+
if (m != MATCH_YES)
-goto cleanup;
+{
+ m = gfc_match_name (name);
+ if (m != MATCH_YES)
+ goto cleanup;
+}
+
+ else
+{
+ m = MATCH_ERROR;
+ if (gfc_current_state () != COMP_STRUCTURE)
+ {
+ if (flag_dec_structure)
+ gfc_error ("%s not allowed outside STRUCTURE at %C", "%FILL");
+ else
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec-structure%>", "%FILL");
+ goto cleanup;
+ }
+
+ if (attr_seen)
+ {
+ gfc_error ("%s entity cannot have attributes at %C", "%FILL");
+ goto cleanup;
+ }
+
+ /* %FILL components are given invalid fortran names. */
+ snprintf (name, GFC_MAX_SYMBOL_LEN + 1, "%%FILL%u", fill_id++);
+ m = MATCH_YES;
+}
var_locus = gfc_current_locus;
@@ -2260,6 +2300,14 @@ variable_decl (int elem)
}
}
+ /* %FILL components may not have initializers. */
+ if (strncmp (name, "%FILL", 5) == 0 && gfc_match_eos () != MATCH_YES)
+{
+ gfc_error ("%s entity cannot have an initializer at %C", "%FILL");
+ m = MATCH_ERROR;
+ goto cleanup;
+}
+
/* If this symbol has already shown up in a Cray Pointer declaration,
and this is not a component declaration,
then we want to set the type & bail out. */
@@ -3
Re: [PATCH, Fortran] Correctly set -fd-lines-as-comments with -fdec
Yes I did. Committed, thanks. --- Fritz Reese On Tue, Aug 1, 2017 at 11:11 AM, Thomas Koenig wrote: > Hi Fritz, > >> This is a simple patch. The original intent was for -fdec to set >> -fd-lines-as-comments by default if flag_d_lines was unspecified by >> the user. However, currently flag_d_lines is interrogated in >> set_dec_flags(), usually before its final value is determined. The >> attached patch fixes this behavior to work as intended. >> >> Any objections for trunk? If not I think it is safe to commit. > > > Did you regression-test? OK for trunk if yes. > > Regards > > Thomas
Re: [PATCH, Fortran] Support for legacy %FILL fields in STRUCTUREs
I find them strange too... But as you say, they are needed for old
code, and some such code bases are quite large and/or have
uncooperative users or maintainers.
Committed with %qs throughout, thanks for review.
---
Fritz Reese
On Tue, Aug 1, 2017 at 11:29 AM, Thomas Koenig wrote:
> Hi Fritz,
>
>
>
>> Regtests on x86_64-redhat-linux. OK for trunk?
>
>
> Patch looks good in principle; I really find all these DEC extensions
> strange, but if they are needed for old code, why not?
>
> Just one point:
>
>> + gfc_error ("%s not allowed outside STRUCTURE at %C", "%FILL");
>
>
> This should have %qs (throughout the patch).
>
> OK for trunk with that.
>
> Regards
>
> Thomas
[PATCH, Fortran] PR 80668: wrong error message with -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668
All,
The following fixes a bug exposed in PR 80668 in which the compiler
attempted to generate an initializer for components of derived types
with the POINTER attribute when compiling with -finit-derived and
-finit-*=*. It is nonsensical for components with the POINTER
attribute to have initializers generated in this way. The resolution
phase caught the resulting contradictions, resulting in an error for
the testcase given in the PR.
With the patch all regression tests pass except for the following,
which already fail in the current trunk (r247800):
Running /data/midas/foreese/src/gcc-dev/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times
original "_gfortran_caf_lock \\(caf_token.., \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[0\\].lbound\\) \\+
\\(integer\\(kind=4\\)\\) MAX_EXPR <\\(parm...dim\\[0\\].ubound -
parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[1\\].lbound\\), 0, 0B, &ii, 0B,
0\\);|_gfortran_caf_lock \\(caf_token.1, \\(3 -
parm...dim\\[0\\].lbound\\) \\+ MAX_EXPR <\\(parm...dim\\[0\\].ubound
- parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
parm...dim\\[1\\].lbound\\), 0, 0B, &ii, 0B, 0\\);" 1
FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times
original "_gfortran_caf_unlock \\(caf_token.., \\(2 -
\\(integer\\(kind=4\\)\\) parm...dim\\[0\\].lbound\\) \\+
\\(integer\\(kind=4\\)\\) MAX_EXPR <\\(parm...dim\\[0\\].ubound -
parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
\\(integer\\(kind=4\\)\\) parm...dim\\[1\\].lbound\\), 0, &ii, 0B,
0\\);|_gfortran_caf_unlock \\(caf_token.., \\(2 -
parm...dim\\[0\\].lbound\\) \\+ MAX_EXPR <\\(parm...dim\\[0\\].ubound
- parm...dim\\[0\\].lbound\\) \\+ 1, 0> \\* \\(3 -
parm...dim\\[1\\].lbound\\), 0, &ii, 0B, 0\\);" 1
FAIL: gfortran.dg/mvbits_7.f90 -O0 (test for warnings, line 28)
OK for trunk?
---
Fritz Reese
2017-05-09 Fritz Reese
PR fortran/80668
gcc/fortran/ChangeLog:
PR fortran/80668
* expr.c (component_initializer): Don't generate initializers for
pointer components.
* invoke.texi (-finit-derived): Document.
gcc/testsuite/ChangeLog:
PR fortran/80668
* gfortran.dg/pr80668.f90: New.
From bd14dcb2026636052a50bb5a7f7075de0fc3b856 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Tue, 9 May 2017 08:42:19 -0400
Subject: [PATCH] 2017-05-09 Fritz Reese
PR fortran/80668
gcc/fortran/
* expr.c (component_initializer): Don't generate initializers for
pointer components.
* invoke.texi (-finit-derived): Document.
* gcc/testsuite/gfortran.dg/pr80668.f90: New.
---
gcc/fortran/expr.c| 8 ++--
gcc/fortran/invoke.texi | 2 ++
gcc/testsuite/gfortran.dg/pr80668.f90 | 32
3 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr80668.f90
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index c8be9513af5..7ea9d8233a9 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4280,9 +4280,13 @@ component_initializer (gfc_typespec *ts, gfc_component *c, bool generate)
{
gfc_expr *init = NULL;
- /* See if we can find the initializer immediately. */
+ /* See if we can find the initializer immediately.
+ Some components should never get initializers. */
if (c->initializer || !generate
- || (ts->type == BT_CLASS && !c->attr.allocatable))
+ || (ts->type == BT_CLASS && !c->attr.allocatable)
+ || c->attr.pointer
+ || c->attr.class_pointer
+ || c->attr.proc_pointer)
return c->initializer;
/* Recursively handle derived type components. */
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 636432fead8..8a1d09dd5e5 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1665,6 +1665,8 @@ according to these flags only with @option{-finit-derived}. These options do
not initialize
@itemize @bullet
@item
+objects with the POINTER attribute
+@item
allocatable arrays
@item
variables that appear in an @code{EQUIVALENCE} statement.
diff --git a/gcc/testsuite/gfortran.dg/pr80668.f90 b/gcc/testsuite/gfortran.dg/pr80668.f90
new file mode 100644
index 000..f69327c3302
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr80668.f90
@@ -0,0 +1,32 @@
+! { dg-do compile }
+! { dg-options "-finit-derived -finit-integer=12345678" }
+!
+! PR fortran/80668
+!
+! Test a regression where structure constructor expressions were created for
+! POINTER components with -finit-derived.
+!
+
+MODULE pr80668
+ IMPLICIT NONE
+ TYPE :: dist_t
+ INTEGER :: TYPE,nblks_loc,nblks
+ INTEGER,DIMENSION(:),POINTER :: dist ! regression: "element in structure
+ ! constructor... should be a POIN
Re: [PATCH, Fortran] PR 80668: wrong error message with -finit-derived
> (1) you don’t need the lines (as in "please don’t use them")
>
> +
> +! { dg-final { cleanup-modules "pr80668" } }
I will remove the "dg-final" lines.
>
> (2) I don’t understand the comments after 'INTEGER,DIMENSION(:),POINTER ::
> dist’.
(2) Sorry, the comments were meant to show the error that would appear
if the testcase is regressed; i.e., the error that appeared in the
original PR report. If it is too esoteric I can just remove the
comments.
Version 2 attached. OK?
---
Fritz Reese
2017-05-09 Fritz Reese
PR fortran/80668
gcc/fortran/ChangeLog:
PR fortran/80668
* expr.c (component_initializer): Don't generate initializers for
pointer components.
* invoke.texi (-finit-derived): Document.
gcc/testsuite/ChangeLog:
PR fortran/80668
* gfortran.dg/pr80668.f90: New.
From 10a0bdcf222db45208242d0530bc2c69530787c0 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Tue, 9 May 2017 12:13:06 -0400
Subject: [PATCH] 2017-05-09 Fritz Reese
PR fortran/80668
gcc/fortran/
* expr.c (component_initializer): Don't generate initializers for
pointer components.
* invoke.texi (-finit-derived): Document.
PR fortran/80668
* gcc/testsuite/gfortran.dg/pr80668.f90: New.
---
gcc/fortran/expr.c| 8 ++--
gcc/fortran/invoke.texi | 2 ++
gcc/testsuite/gfortran.dg/pr80668.f90 | 29 +
3 files changed, 37 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr80668.f90
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index c8be9513af5..7ea9d8233a9 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4280,9 +4280,13 @@ component_initializer (gfc_typespec *ts, gfc_component *c, bool generate)
{
gfc_expr *init = NULL;
- /* See if we can find the initializer immediately. */
+ /* See if we can find the initializer immediately.
+ Some components should never get initializers. */
if (c->initializer || !generate
- || (ts->type == BT_CLASS && !c->attr.allocatable))
+ || (ts->type == BT_CLASS && !c->attr.allocatable)
+ || c->attr.pointer
+ || c->attr.class_pointer
+ || c->attr.proc_pointer)
return c->initializer;
/* Recursively handle derived type components. */
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 636432fead8..8a1d09dd5e5 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1665,6 +1665,8 @@ according to these flags only with @option{-finit-derived}. These options do
not initialize
@itemize @bullet
@item
+objects with the POINTER attribute
+@item
allocatable arrays
@item
variables that appear in an @code{EQUIVALENCE} statement.
diff --git a/gcc/testsuite/gfortran.dg/pr80668.f90 b/gcc/testsuite/gfortran.dg/pr80668.f90
new file mode 100644
index 000..63bd0d3d5cd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr80668.f90
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-options "-finit-derived -finit-integer=12345678" }
+!
+! PR fortran/80668
+!
+! Test a regression where structure constructor expressions were created for
+! POINTER components with -finit-derived.
+!
+
+MODULE pr80668
+ IMPLICIT NONE
+ TYPE :: dist_t
+ INTEGER :: TYPE,nblks_loc,nblks
+ INTEGER,DIMENSION(:),POINTER :: dist
+ END TYPE dist_t
+
+CONTAINS
+
+ SUBROUTINE hfx_new()
+TYPE(dist_t) :: dist
+integer,pointer :: bob
+CALL release_dist(dist, bob)
+ END SUBROUTINE hfx_new
+
+ SUBROUTINE release_dist(dist,p)
+TYPE(dist_t) :: dist
+integer, pointer, intent(in) :: p
+ END SUBROUTINE release_dist
+END MODULE
--
2.12.2
[PATCH, Fortran] PR 79968: merge similar diagnostics containing -fdec-structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968
All,
The PR suggests unifying diagnostics of the form "%s at %C is a DEC
extension, enable with ..." I think the patch is obvious/trivial and
speaks for itself. I plan to commit the attached to trunk shortly,
barring any complaints.
(Nb. even with the change in diagnostics, the applicable testcases
(dec_io_3.f90 and dec_static_3.f90) are not regressed as they match
only the "is a DEC extension" portion of the error message.)
---
Fritz Reese
2017-05-17 Fritz Reese
PR fortran/79968
gcc/fortran/ChangeLog:
PR fortran/79968
* decl.c (match_attr_spec, gfc_match_automatic,
gfc_match_static, gfc_match_structure_decl): Unify diagnostic
errors regarding -fdec options.
* io.c (match_dec_etag, match_dec_vtag, match_dec_ftag): Ditto.
From de4f3b068eff1f33c0f7a8c9a5c328f6c85c712b Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 17 May 2017 11:36:54 -0400
Subject: [PATCH] 2017-05-17 Fritz Reese
PR fortran/79968
gcc/fortran/
* decl.c (match_attr_spec, gfc_match_automatic,
gfc_match_static, gfc_match_structure_decl): Unify diagnostic
errors regarding -fdec options.
* io.c (match_dec_etag, match_dec_vtag, match_dec_ftag): Ditto.
---
gcc/fortran/decl.c | 18 --
gcc/fortran/io.c | 12 ++--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 5ca664e57a5..8d6c2064db4 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4210,7 +4210,8 @@ match_attr_spec (void)
if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
&& !flag_dec_static)
{
- gfc_error ("%s at %L is a DEC extension, enable with -fdec-static",
+ gfc_error ("%s at %L is a DEC extension, enable with "
+ "%<-fdec-static%>",
d == DECL_STATIC ? "STATIC" : "AUTOMATIC", &seen_at[d]);
m = MATCH_ERROR;
goto cleanup;
@@ -7889,8 +7890,10 @@ gfc_match_automatic (void)
if (!flag_dec_static)
{
- gfc_error ("AUTOMATIC at %C is a DEC extension, enable with "
- "-fdec-static");
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec-static%>",
+ "AUTOMATIC"
+ );
return MATCH_ERROR;
}
@@ -7943,7 +7946,9 @@ gfc_match_static (void)
if (!flag_dec_static)
{
- gfc_error ("STATIC at %C is a DEC extension, enable with -fdec-static");
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec-static%>",
+ "STATIC");
return MATCH_ERROR;
}
@@ -8702,8 +8707,9 @@ gfc_match_structure_decl (void)
if (!flag_dec_structure)
{
- gfc_error ("STRUCTURE at %C is a DEC extension, enable with "
- "-fdec-structure");
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec-structure%>",
+ "STRUCTURE");
return MATCH_ERROR;
}
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 7ab897daa44..b08c785988d 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -1515,8 +1515,8 @@ match_dec_etag (const io_tag *tag, gfc_expr **e)
return m;
else if (m != MATCH_NO)
{
- gfc_error ("%s is a DEC extension at %C, re-compile with "
- "-fdec to enable", tag->name);
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec%>", tag->name);
return MATCH_ERROR;
}
return m;
@@ -1532,8 +1532,8 @@ match_dec_vtag (const io_tag *tag, gfc_expr **e)
return m;
else if (m != MATCH_NO)
{
- gfc_error ("%s is a DEC extension at %C, re-compile with "
- "-fdec to enable", tag->name);
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec%>", tag->name);
return MATCH_ERROR;
}
return m;
@@ -1553,8 +1553,8 @@ match_dec_ftag (const io_tag *tag, gfc_open *o)
if (!flag_dec)
{
- gfc_error ("%s is a DEC extension at %C, re-compile with "
- "-fdec to enable", tag->name);
+ gfc_error ("%s at %C is a DEC extension, enable with "
+ "%<-fdec%>", tag->name);
return MATCH_ERROR;
}
--
2.12.2
Re: [Patch, Fortran] Test for implied sequence in structures in common blocks
Jim, While the test exhibits no particular regression, IMVHO I don't see any reason not to add it. None of my previous testcases include a STRUCTURE within a COMMON block so this would certainly tickle some new code paths, which could expose a future regression. I'll give this through the weekend or so to see if any official maintainers have a comment otherwise I wouldn't mind committing it as trivial. --- Fritz Reese On Tue, Sep 13, 2016 at 9:51 AM, Jim MacArthur wrote: > Hi, I'd like to contribute this small test. I have legacy code which uses > STRUCTURE statements in common blocks, and was happy to find Fritz's DEC > support assumes ordering in STRUCTUREs, as the Oracle compiler does. > > Jim MacArthur > > -- > > 2016-09-13 Jim MacArthur > >* gfortran.dg/dec_structure_14.f90: New testcase. >
Re: [Patch, Fortran] Test for implied sequence in structures in common blocks
Committed revision 240134. --- Fritz Reese On Tue, Sep 13, 2016 at 10:52 AM, Jerry DeLisle wrote: > On 09/13/2016 07:33 AM, Fritz Reese wrote: >> >> Jim, >> >> While the test exhibits no particular regression, IMVHO I don't see >> any reason not to add it. None of my previous testcases include a >> STRUCTURE within a COMMON block so this would certainly tickle some >> new code paths, which could expose a future regression. >> >> I'll give this through the weekend or so to see if any official >> maintainers have a comment otherwise I wouldn't mind committing it as >> trivial. >> > > No problem with the test case being added. > > Jerry
Ping**3! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote:
> This patch extends the GNU Fortran front-end to add support for
> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
> -fdec-static, allowing explicit control of variable storage. AUTOMATIC
> local variables are placed on the stack, whereas STATIC variables are
> placed in static storage.
...
https://gcc.gnu.org/ml/fortran/2016-09/msg00021.html
On Wed, Sep 7, 2016 at 4:13 PM Fritz Reese wrote:
...
> Attached is a replacement for the original patch [...]
...
I hate to be a bother but I'm still waiting on official review for
this patch for trunk - and I still have many other extension patches I
would like to submit. I know these aren't as important as things like
DTIO, ACC, and other f03/f08+ features, and I appreciate that the
maintainers are overworked with these features as it is. Nevertheless
I believe these legacy extensions to be useful to a number of user
groups and would like to see the extensions through in this GCC
release. I am quite committed to supporting the extensions and will
address any PRs or regressions introduced as a result of them (though
of course I aim to eliminate such bugs from the beginning).
Thanks in advance,
---
Fritz Reese
> Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
> and critique welcome. Ok for trunk?
...
>
> 2016-09-07 Fritz Reese
>
> Support for AUTOMATIC and STATIC attributes with new flag -fdec-static.
>
> gcc/fortran/
> * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
> * options.c (set_dec_flags): Set -fdec-static with -fdec.
> * gfortran.h (symbol_attribute): New attribute automatic.
> * gfortran.h (gfc_add_automatic): New prototype.
> * match.h (gfc_match_automatic, gfc_match_static): New functions.
> * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
> * symbol.c (gfc_add_automatic): Ditto.
> * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
> * parse.c (decode_specification_statement, decode_statement): Ditto.
> * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
> resolve_symbol): Support for automatic attribute.
> * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
> Ditto.
> * trans-decl.c (gfc_finish_var_decl): Ditto.
>
> gcc/testsuite/gfortran.dg/
> * dec_static_1.f90, dec_static_2.f90, dec_static_3.f90,
> dec_static_4.f90: New testcases.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index ce5ebb7..be8e9f7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3794,6 +3794,7 @@ match_attr_spec (void)
DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
+DECL_STATIC, DECL_AUTOMATIC,
DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
DECL_IS_BIND_C, DECL_CODIMENSION, DECL_ASYNCHRONOUS, DECL_CONTIGUOUS,
DECL_NONE, GFC_DECL_END /* Sentinel */
@@ -3857,6 +3858,14 @@ match_attr_spec (void)
d = DECL_ASYNCHRONOUS;
}
break;
+
+ case 'u':
+ if (match_string_p ("tomatic"))
+ {
+ /* Matched "automatic". */
+ d = DECL_AUTOMATIC;
+ }
+ break;
}
break;
@@ -3986,8 +3995,25 @@ match_attr_spec (void)
break;
case 's':
- if (match_string_p ("save"))
- d = DECL_SAVE;
+ gfc_next_ascii_char ();
+ switch (gfc_next_ascii_char ())
+ {
+ case 'a':
+ if (match_string_p ("ve"))
+ {
+ /* Matched "save". */
+ d = DECL_SAVE;
+ }
+ break;
+
+ case 't':
+ if (match_string_p ("atic"))
+ {
+ /* Matched "static". */
+ d = DECL_STATIC;
+ }
+ break;
+ }
break;
case 't':
@@ -4124,6 +4150,12 @@ match_attr_spec (void)
case DECL_SAVE:
attr = "SAVE";
break;
+ case DECL_STATIC:
+ attr = "STATIC";
+ break;
+ case DECL_AUTOMATIC:
+ attr = "AUTOMATIC";
+ break;
case DECL_TARGET:
attr = "TARGET";
break;
@@ -4152,6 +4184,18 @@ match_attr_spec (void)
if (seen[d] == 0)
continue;
+ if ((d == DECL_STATIC || d == DECL_AUTOMATIC)
+ && !flag_dec_static)
+ {
+ gfc_error ("%s at %L is a DEC extension, enable with -fdec-static",
+ d == DECL_STATIC ? "STATIC" : "AUTOMATIC", &seen_at[d]);
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+ /* Allow SAVE with STATIC, but don't complain. */
+ if (d == DECL_STA
Re: Ping**3! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static
Many thanks. :) Committed revision 240458. Next extension coming soon On Fri, Sep 23, 2016 at 3:15 PM Jerry DeLisle wrote: > > On 09/23/2016 06:17 AM, Fritz Reese wrote: > > https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html > > On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote: > >> This patch extends the GNU Fortran front-end to add support for > >> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag > >> -fdec-static, allowing explicit control of variable storage. AUTOMATIC > >> local variables are placed on the stack, whereas STATIC variables are > >> placed in static storage. > > ... > > > > https://gcc.gnu.org/ml/fortran/2016-09/msg00021.html > > On Wed, Sep 7, 2016 at 4:13 PM Fritz Reese wrote: > > ... > >> Attached is a replacement for the original patch [...] > > ... > > > > I hate to be a bother but I'm still waiting on official review for > > this patch for trunk - and I still have many other extension patches I > > would like to submit. I know these aren't as important as things like > > DTIO, ACC, and other f03/f08+ features, and I appreciate that the > > maintainers are overworked with these features as it is. Nevertheless > > I believe these legacy extensions to be useful to a number of user > > groups and would like to see the extensions through in this GCC > > release. I am quite committed to supporting the extensions and will > > address any PRs or regressions introduced as a result of them (though > > of course I aim to eliminate such bugs from the beginning). > > > > Thanks in advance, > > > > --- > > Fritz Reese > > looks OK to me, Go ahead. > > Jerry
[PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
All, Attached is a patch extending the GNU Fortran front-end to support some additional math intrinsics, enabled with a new compile flag -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD, etc...). This extension allows for further compatibility with legacy code that depends on the compiler to support such intrinsic functions. I would definitely like some peer review on this patch to ensure my implementation has no unintended mathematical side-effects, such as rounding errors, or oversights with complex math: I implement the degree-valued functions by simply converting the argument or result to degrees/radians as appropriate by multiplying by the factor pi/180 (or 180/pi). In the constant case this is done using mpfr/mpc, and in the non-constant case the factor multiplication expression is just inserted into the expression tree where appropriate. The new COTAN intrinsic is implemented using mpfr_cot in the constant case, and by replacing the call with a 1/tan expression in the non-constant case (and in the complex case, since there is no mpc_cot). See the new functions in simplify.c/iresolve.c for specifics. I also added a new macro MATH_ALIAS_BUILTIN used in mathbuiltins.def to define the new COTAN intrinsic. This macro defines a new isym, but keeps everything else defined normally by DEFINE_MATH_BUILTIN the same as an existing isym (TAN in this case). The reason for this is to avoid having to define a new BUILT_IN_COTAN in gcc/builtins.def (or any other context). As I described above, the simplify/resolve code for COTAN just wraps TAN. I am not 100% convinced this is the "right" or "best" way to do this - so feel free to me know if there are any problems with this approach. By the way, I don't use intrinsic.c (make_alias) for these because they need their own simplification/resolution routines to handle the degree-radian conversion. As usual the patched compiler bootstraps and regtests on x86_64-redhat-linux. Questions, comments and concerns are very welcome. Barring any, is this OK for trunk? --- Fritz Reese 2016-09-26 Fritz Reese New flag -fdec-math for COTAN and degree trig intrinsics. gcc/fortran/ * lang.opt: New flag -fdec-math. * options.c (set_dec_flags): Enable with -fdec. * invoke.texi, gfortran.texi, intrinsic.texi: Update documentation. * trans-intrinsic.c (MATH_ALIAS_BUILTLIN): New macro for math aliases. * f95-lang.c (MATH_ALIAS_BUILTIN): New macro for math aliases. * mathbuiltins.def (MATH_ALIAS_BUILTIN): Use for cotan. * intrinsics.c (add_functions, do_simplify): New intrinsics with -fdec-math. * gfortran.h (gfc_isym_id): New isym GFC_ISYM_COTAN. * gfortran.h (gfc_resolve_atan2d, gfc_resolve_cotan, gfc_resolve_trigd, gfc_resolve_atrigd): New prototypes. * iresolve.c (resolve_trig_call, get_degrees, get_radians, is_trig_resolved, gfc_resolve_cotan, gfc_resolve_trigd, gfc_resolve_atrigd, gfc_resolve_atan2d): New functions. * intrinsics.h (gfc_simplify_atan2d, gfc_simplify_atrigd, gfc_simplify_cotan, gfc_simplify_trigd): New prototypes. * simplify.c (simplify_trig_call, degrees_f, radians_f, gfc_simplify_cotan, gfc_simplify_trigd, gfc_simplify_atrigd, gfc_simplify_atan2d): New functions. gcc/testsuite/gfortran.dg/ * dec_math.f90: New testsuite. diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c index 2b58173..7229d8d 100644 --- a/gcc/fortran/f95-lang.c +++ b/gcc/fortran/f95-lang.c @@ -559,6 +559,8 @@ gfc_define_builtin (const char *name, tree type, enum built_in_function code, DO_DEFINE_MATH_BUILTIN (code, name, argtype, mfunc_) \ DO_DEFINE_MATH_BUILTIN (C##code, "c" name, argtype, mfunc_c) +/* Defined in trans-intrinsic.c. */ +#define MATH_ALIAS_BUILTIN(newid, id, name, type) /* Create function types for builtin functions. */ @@ -1244,6 +1246,7 @@ gfc_init_builtin_functions (void) targetm.init_builtins (); } +#undef MATH_ALIAS_BUILTIN #undef DEFINE_MATH_BUILTIN_C #undef DEFINE_MATH_BUILTIN diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index d6b92a6..f8f3d4a 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -391,6 +391,7 @@ enum gfc_isym_id GFC_ISYM_CONVERSION, GFC_ISYM_COS, GFC_ISYM_COSH, + GFC_ISYM_COTAN, GFC_ISYM_COUNT, GFC_ISYM_CPU_TIME, GFC_ISYM_CSHIFT, diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 3ebe3c7..4f8d2d6 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -1466,6 +1466,7 @@ without warning. * Form feed as whitespace:: * TYPE as an alias for PRINT:: * %LOC as an rvalue:: +* Extended math intrinsics:: @end menu @node Old-style kind specifications @@ -2519,6 +2520,33 @@ integer :: i call sub(%loc(i)) @end smallexampl
Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
Tobias, Many thanks for the comments. I will adjust the patch according to your advice shortly. - Fritz On Mon, Sep 26, 2016, 11:59 Tobias Burnus wrote: > > Fritz Reese wrote: > > Attached is a patch extending the GNU Fortran front-end to support > > some additional math intrinsics, enabled with a new compile flag > > -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as > > degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD, > > etc...). > > > > + /* There is no builtin mpc_cot, so compute x = 1 / tan (x). */ > > + val = &result->value.complex; > > + mpc_tan (*val, *val, GFC_MPC_RND_MODE); > > + mpc_div (*val, one, *val, GFC_MPC_RND_MODE); > > The internet remarks: TAN(x) for x -> pi/2 goes to +inf or -inf - while > COTAN(pi/2) == 0. For values near pi/2, using cos(x)/sin(x) should be > numerically better than 1/tan(x). [Cf. mpfr_sin_cos and BUILT_IN_SINCOS.] > > I am not sure how big the prevision difference really is. A quick test > showed results which didn't look to bad: > > implicit none > real(8), volatile :: x > x = 3.14159265358d0/2.0d0 > print '(g0)', cotan(x), cos(x)/sin(x), cotan(x)-cos(x)/sin(x) > end > > yields: > > 0.48965888601467483E-011 > 0.48965888601467475E-011 > 0.80779356694631609E-027 > > Usint N[1/Tan[314159265358/10^11/2],200], Mathematica shows > 4.8966192313216916397514812338... * 10^12. > I am not quite sure whether I should expect that already the 5th digit > differs from the results above. > > > > mpfr_set_d (tmp, 180.0l, GFC_RND_MODE); > > With some fonts the L after 180.0 looks like a one; I was initially > puzzled why one uses not 180 but 180.01. Hence, I'd prefer an "L" instead > of an "l". > > However, the second argument of mpfr_set_d is a "double" and 180.0 is > already a double. Hence, one can even completely get rid of the "l". > > > > Regarding the decimal trigonometric functions, the internet suggests to > use >sin (fmod ((x), 360) * M_PI / 180) > instead of >sin (x * M_PI / 180) > to yield better results for angles which are larger than +/-360 degrees. > > > Cheers, > > Tobias
[PATCH, Fortran] PR fortran/77782 - ICE in gfc_get_union_type
ICE in [1] is due to an incomplete fix for PR fortran/77327 (r239819,
see [2],[3]). Specifically in interface.c (gfc_compare_derived_types)
I overlooked the case where FL_UNION type symbols could be compared as
equal to FL_STRUCTURE type symbols, which is _never_ correct. The
faulty logic causes a UNION to be considered equal to a STRUCTURE,
thus the union receives the structure's backend declaration. Obviously
everything goes haywire from there.
Attached is the [obvious] fix. Will commit to trunk soon, barring any
concerns from others.
---
Fritz Reese
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77782
[2] https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html
[3] https://gcc.gnu.org/ml/fortran/2016-08/msg00145.html
2016-09-29 Fritz Reese
Fix ICE caused by union types comparing equal to structure types.
PR fortran/77782
* gcc/fortran/interface.c (gfc_compare_derived_types): Use
gfc_compare_union_types to compare union types.
PR fortran/77782
* gcc/testsuite/gfortran.dg/dec_structure_16.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 9a19fa7..9d4e5e9 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -589,6 +589,10 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
gcc_assert (derived1 && derived2);
+ /* Compare UNION types specially. */
+ if (derived1->attr.flavor == FL_UNION || derived2->attr.flavor == FL_UNION)
+return gfc_compare_union_types (derived1, derived2);
+
/* Special case for comparing derived types across namespaces. If the
true names and module names are the same and the module name is
nonnull, then they are equal. */
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_16.f90 b/gcc/testsuite/gfortran.dg/dec_structure_16.f90
new file mode 100644
index 000..f9b2671
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_structure_16.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-fdec-structure" }
+!
+! PR fortran/77782
+!
+! Test an ICE where a union might be considered equal to a structure,
+! causing the union's backend_decl to be replaced with that of the structure.
+!
+
+program p
+
+structure /s1/
+ union
+map
+ integer(4) a
+ end map
+map
+ real(4) b
+end map
+ end union
+end structure
+
+structure /s2/
+ union ! regression: if this union == s1, we ICE in gfc_get_union_type
+map
+ integer(2) x, y
+ integer(4) z
+end map
+ end union
+end structure
+
+record /s1/ r1
+r1.a = 0
+
+end
[PATCH, Fortran] PR fortran/77764 - ICE in is_anonymous_component
ICE in [1] is due to failure to null-guard map components in
gfc_compare_union_types. Attached is [obvious] fix - will commit soon
without complaints.
---
Fritz Reese
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77764
2016-09-29 Fritz Reese
Fix ICE for maps with zero components.
PR fortran/77764
* gcc/fortran/interface.c (gfc_compare_union_types): Null-guard map
components.
PR fortran/77764
* gcc/testsuite/gfortran.dg/dec_union_8.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 9d4e5e9..55923a3 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -526,6 +526,7 @@ int
gfc_compare_union_types (gfc_symbol *un1, gfc_symbol *un2)
{
gfc_component *map1, *map2, *cmp1, *cmp2;
+ gfc_symbol *map1_t, *map2_t;
if (un1->attr.flavor != FL_UNION || un2->attr.flavor != FL_UNION)
return 0;
@@ -541,16 +542,26 @@ gfc_compare_union_types (gfc_symbol *un1, gfc_symbol *un2)
we compare the maps sequentially. */
for (;;)
{
-cmp1 = map1->ts.u.derived->components;
-cmp2 = map2->ts.u.derived->components;
+map1_t = map1->ts.u.derived;
+map2_t = map2->ts.u.derived;
+
+cmp1 = map1_t->components;
+cmp2 = map2_t->components;
+
+/* Protect against null components. */
+if (map1_t->attr.zero_comp != map2_t->attr.zero_comp)
+ return 0;
+
+if (map1_t->attr.zero_comp)
+ return 1;
+
for (;;)
{
/* No two fields will ever point to the same map type unless they are
the same component, because one map field is created with its type
declaration. Therefore don't worry about recursion here. */
/* TODO: worry about recursion into parent types of the unions? */
- if (compare_components (cmp1, cmp2,
-map1->ts.u.derived, map2->ts.u.derived) == 0)
+ if (compare_components (cmp1, cmp2, map1_t, map2_t) == 0)
return 0;
cmp1 = cmp1->next;
diff --git a/gcc/testsuite/gfortran.dg/dec_union_8.f90 b/gcc/testsuite/gfortran.dg/dec_union_8.f90
new file mode 100644
index 000..2d856fc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_union_8.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+! { dg-options "-fdec-structure" }
+!
+! PR fortran/77764
+!
+! Test an ICE due to a map with zero components.
+!
+
+program p
+
+structure /s1/
+ union
+map
+end map
+map
+ real :: a = 2.0
+end map
+ end union
+end structure
+
+end
[PATCH, Fortran] Fix ICE due to comparison between UNION components
All,
The attached fixes an[other] ICE in the comparison between UNIONs.
This time the ICE is due to a BT_UNION component comparing itself to a
BT_DERIVED component, thus considering their FL_STRUCT and FL_UNION
typenodes to be equal. This is very similar to PR fortran/77782,
except it is an error in the comparison of _components_ from
gfc_compare_types, instead of an error comparing the _type symbols_
from gfc_compare_derived. The patch makes sure that BT_UNION compared
to anything other than BT_UNION is _not_ equal, while still comparing
two union components with gfc_compare_union_types.
Will commit soon with no complaints. Maybe this patch will finally get
type comparison right for unions.
---
Fritz Reese
2016-10-02 Fritz Reese
Fix ICE due to comparison between UNION components.
* gcc/fortran/interface.c (gfc_compare_types): Don't compare BT_UNION
components until we know they're both UNIONs.
* gcc/testsuite/gfortran.dg/dec_union_9.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 04ad0e2..441cc00 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -694,13 +694,14 @@ gfc_compare_types (gfc_typespec *ts1, gfc_typespec *ts2)
&& (ts1->u.derived->attr.sequence || ts1->u.derived->attr.is_bind_c))
return 1;
- if (ts1->type == BT_UNION && ts2->type == BT_UNION)
-return gfc_compare_union_types (ts1->u.derived, ts2->u.derived);
-
if (ts1->type != ts2->type
- && ((!gfc_bt_struct (ts1->type) && ts1->type != BT_CLASS)
- || (!gfc_bt_struct (ts2->type) && ts2->type != BT_CLASS)))
+ && ((ts1->type != BT_DERIVED && ts1->type != BT_CLASS)
+ || (ts2->type != BT_DERIVED && ts2->type != BT_CLASS)))
return 0;
+
+ if (ts1->type == BT_UNION)
+return gfc_compare_union_types (ts1->u.derived, ts2->u.derived);
+
if (ts1->type != BT_DERIVED && ts1->type != BT_CLASS)
return (ts1->kind == ts2->kind);
diff --git a/gcc/testsuite/gfortran.dg/dec_union_9.f90 b/gcc/testsuite/gfortran.dg/dec_union_9.f90
new file mode 100644
index 000..2cb38fc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_union_9.f90
@@ -0,0 +1,26 @@
+! { dg-do compile }
+! { dg-options "-fdec-structure" }
+!
+! Test a regression where union components could compare equal to structure/map
+! components, causing an ICE in gfc_conv_component_ref.
+!
+
+implicit none
+
+structure /s1/
+ integer(4) i
+end structure
+
+structure /s2/
+ union
+map
+ record /s1/ r
+end map
+ end union
+end structure
+
+record /s2/ x
+
+x.r.i = 0
+
+end
Re: [PATCH, Fortran] Fix ICE due to comparison between UNION components
On Sun, Oct 2, 2016 at 6:27 PM, Fritz Reese wrote: > All, > > The attached fixes an[other] ICE in the comparison between UNIONs. > This time the ICE is due to a BT_UNION component comparing itself to a > BT_DERIVED component, thus considering their FL_STRUCT and FL_UNION > typenodes to be equal. This is very similar to PR fortran/77782, > except it is an error in the comparison of _components_ from > gfc_compare_types, instead of an error comparing the _type symbols_ > from gfc_compare_derived. The patch makes sure that BT_UNION compared > to anything other than BT_UNION is _not_ equal, while still comparing > two union components with gfc_compare_union_types. > > Will commit soon with no complaints. Maybe this patch will finally get > type comparison right for unions. > Meant to include a null-guard as part of the patch, see below. Fritz Reese 2016-10-03 Fritz Reese Fix ICE due to comparison between UNION components. gcc/fortran/ * interface.c (gfc_compare_types): Don't compare BT_UNION components until we know they're both UNIONs. * interface.c (gfc_compare_union_types): Guard against empty components. gcc/testsuite/gfortran.dg/ * dec_union_9.f90, dec_union_10.f90: New testcases. union_ice.patch2 Description: Binary data
Fix ICE due to map typespecs with different sized charlens being copied
When union type symbols are compared and they contain maps containing
characters with different lengths, their type symbols should have
different backend declarations otherwise the gimple tree explodes.
Strangely enough the gimple checker only explodes with '-g' enabled
and certain other specific conditions, however the problem seems
clear. See the attached testcase for an example, and the attached
patch for a fix.
RFC: My only concern is that this patch would technically also change
the way components are compared between derived types and class types,
not just union/map types. However from what I can tell if two derived
types are declared with character components of different lengths then
the two types should have distinct backend declarations anyway. If
anyone can think of any issues this patch might cause with derived
types/class types then I'd be okay guarding the new if statement to
only run for union/structure types. But with all my tests it doesn't
seem to result in any concrete differences.
The patch does pass all regression tests on x86_64-redhat-linux. I
will give it a couple days for the RFC before committing.
---
Fritz Reese
2016-10-05 Fritz Reese
Fix ICE due to map typespecs with different sized charlens being copied.
* gcc/fortran/interface.c (compare_components): Check charlens.
* gcc/testsuite/gfortran.dg/dec_union_11.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index e7f1878..17f544e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -495,6 +495,17 @@ compare_components (gfc_component *cmp1,
gfc_component *cmp2,
if (cmp1->attr.dimension && gfc_compare_array_spec (cmp1->as, cmp2->as) == 0)
return 0;
+ if (cmp1->ts.type == BT_CHARACTER && cmp2->ts.type == BT_CHARACTER)
+{
+ gfc_charlen *l1 = cmp1->ts.u.cl;
+ gfc_charlen *l2 = cmp2->ts.u.cl;
+ if (l1 && l2 && l1->length && l2->length
+ && l1->length->expr_type == EXPR_CONSTANT
+ && l2->length->expr_type == EXPR_CONSTANT
+ && gfc_dep_compare_expr (l1->length, l2->length) != 0)
+return 0;
+}
+
/* Make sure that link lists do not put this function into an
endless recursive loop! */
if (!(cmp1->ts.type == BT_DERIVED && derived1 == cmp1->ts.u.derived)
diff --git a/gcc/testsuite/gfortran.dg/dec_union_11.f90
b/gcc/testsuite/gfortran.dg/dec_union_11.f90
new file mode 100644
index 000..3ff4b49
diff --git a/gcc/testsuite/gfortran.dg/dec_union_11.f90
b/gcc/testsuite/gfortran.dg/dec_union_11.f90
new file mode 100644
index 000..3ff4b49
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dec_union_11.f90
@@ -0,0 +1,63 @@
+! { dg-do compile }
+! { dg-options "-g -fdec-structure" }
+!
+! Test a regression where typespecs of unions containing character buffers of
+! different lengths where copied, resulting in a bad gimple tree state.
+!
+
+subroutine sub2 (otherbuf)
+ integer, parameter :: L_bbuf = 65536
+ integer, parameter :: L_bbuf2 = 24
+
+ structure /buffer2/
+union
+ map
+ character(L_bbuf2) sbuf
+ end map
+end union
+ end structure
+ structure /buffer/
+union
+ map
+ character(L_bbuf) sbuf
+ end map
+end union
+ end structure
+
+ record /buffer/ buf1
+ record /buffer2/ buf2
+ common /c/ buf1, buf2
+
+ record /buffer2/ otherbuf
+end subroutine
+
+subroutine sub()
+ integer, parameter :: L_bbuf = 65536
+ integer, parameter :: L_bbuf2 = 24
+
+ structure /buffer2/
+union
+ map
+ character(L_bbuf2) sbuf
+ end map
+end union
+ end structure
+ structure /buffer/
+union
+ map
+ character(L_bbuf) sbuf
+ end map
+end union
+ end structure
+
+ record /buffer/ buf1
+ record /buffer2/ buf2
+ common /c/ buf1, buf2
+
+ call sub2 (buf1) ! { dg-warning "Type mismatch" }
+ return
+end subroutine
+
+call sub()
+
+end
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index e7f1878..17f544e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -495,6 +495,17 @@ compare_components (gfc_component *cmp1, gfc_component *cmp2,
if (cmp1->attr.dimension && gfc_compare_array_spec (cmp1->as, cmp2->as) == 0)
return 0;
+ if (cmp1->ts.type == BT_CHARACTER && cmp2->ts.type == BT_CHARACTER)
+{
+ gfc_charlen *l1 = cmp1->ts.u.cl;
+ gfc_charlen *l2 = cmp2->ts.u.cl;
+ if (l1 && l2 && l1->length && l2->length
+ && l1->length->expr_type == EXPR_CONSTANT
+ && l2->length->expr_type == EXPR_CONSTANT
+ && gfc_dep_compare_expr (l1->length, l2->length) != 0)
+return 0;
+}
+
/* Make sure that link lists do not put this function into an
endles
Re: [PATCH, libgfortran] PR 67585 Handle EINTR
On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist wrote: > On Fri, Oct 7, 2016 at 2:41 PM, FX wrote: >>> Many POSIX systems have the bad habit of not restarting interrupted >>> syscalls. On these systems it's up to the user to check for an error >>> with errno == EINTR and restart manually. This patch does this for >>> libgfortran, so that GFortran users don't have to do it. >> >> I have not much experience with EINTR, but is it garanteed that those EINTR >> loops will never cycle forever? > > Hmm, no I don't think so, but I don't think it'll be a problem. So on > systems where syscalls are not restarted automatically, EINTR happens > when the process receives a signal while blocked in a system call [1]. > So I suppose in theory you could have a situation where something > continuously fires signals at the process, and the result is some kind > of race between the process restarting the syscall which then never > manages to complete before being interrupted again. But I think this > goes into the "Doctor, this hurts! Then don't do that" territory. > > There's some more info in https://www.python.org/dev/peps/pep-0475/ > (Python nowadays does the same as this patch). Just one concern (slightly different from the race you described) - what if a user wants/expects a system call to be interrupted? With the patch we would always restart the system call even if the user was expecting it would be interrupted. For small calls like lseek this may not be a big deal but if read on a pipe/socket/terminal is restarted after being interrupted (e.g. with CTRL-C) we may loop forever even if the user program was written to expect and handle EINTR after the read call, e.g. to terminate nicely with "non async-safe" calls like printf that couldn't be done in the handler. This is discussed as "use case 2" in the PEP you referenced. Python handles this case by explicitly calling user defined signal handlers directly after EINTR and checking the return value from the handler, only trying again if the handler reports success. Not so simple I think with libgfortran. --- Fritz Reese
PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
https://gcc.gnu.org/ml/fortran/2016-09/msg00163.html [original]
https://gcc.gnu.org/ml/fortran/2016-09/msg00183.html [latest]
On Wed, Sep 28, 2016 at 4:14 PM, Fritz Reese wrote:
> Attached is a patch extending the GNU Fortran front-end to support
> some additional math intrinsics, enabled with a new compile flag
> -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as
> degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD,
> etc...). This extension allows for further compatibility with legacy
> code that depends on the compiler to support such intrinsic functions.
Patch is still pending. Current draft of the patch is re-attached for
convenience, since it was amended twice since the original post. OK
for trunk?
---
Fritz Reese
2016-09-28 Fritz Reese
New flag -fdec-math for COTAN and degree trig intrinsics.
gcc/fortran/
* lang.opt: New flag -fdec-math.
* options.c (set_dec_flags): Enable with -fdec.
* invoke.texi, gfortran.texi, intrinsic.texi: Update documentation.
* intrinsics.c (add_functions, do_simplify): New intrinsics
with -fdec-math.
* gfortran.h (gfc_isym_id): New isym GFC_ISYM_COTAN.
* gfortran.h (gfc_resolve_atan2d, gfc_resolve_cotan,
gfc_resolve_trigd, gfc_resolve_atrigd): New prototypes.
* iresolve.c (resolve_trig_call, get_degrees, get_radians,
is_trig_resolved, gfc_resolve_cotan, gfc_resolve_trigd,
gfc_resolve_atrigd, gfc_resolve_atan2d): New functions.
* intrinsics.h (gfc_simplify_atan2d, gfc_simplify_atrigd,
gfc_simplify_cotan, gfc_simplify_trigd): New prototypes.
* simplify.c (simplify_trig_call, degrees_f, radians_f,
gfc_simplify_cotan, gfc_simplify_trigd, gfc_simplify_atrigd,
gfc_simplify_atan2d): New functions.
gcc/testsuite/gfortran.dg/
* dec_math.f90: New testsuite.
commit 126e89b660fad6b21f50c48e2af616225a727586
Author: Fritz Reese
Date: Wed Sep 28 16:11:23 2016 -0400
New flag -fdec-math for COTAN and degree trig intrinsics.
gcc/fortran/
* lang.opt: New flag -fdec-math.
* options.c (set_dec_flags): Enable with -fdec.
* invoke.texi, gfortran.texi, intrinsic.texi: Update documentation.
* intrinsics.c (add_functions, do_simplify): New intrinsics
with -fdec-math.
* gfortran.h (gfc_isym_id): New isym GFC_ISYM_COTAN.
* gfortran.h (gfc_resolve_atan2d, gfc_resolve_cotan,
gfc_resolve_trigd, gfc_resolve_atrigd): New prototypes.
* iresolve.c (resolve_trig_call, get_degrees, get_radians,
is_trig_resolved, gfc_resolve_cotan, gfc_resolve_trigd,
gfc_resolve_atrigd, gfc_resolve_atan2d): New functions.
* intrinsics.h (gfc_simplify_atan2d, gfc_simplify_atrigd,
gfc_simplify_cotan, gfc_simplify_trigd): New prototypes.
* simplify.c (simplify_trig_call, degrees_f, radians_f,
gfc_simplify_cotan, gfc_simplify_trigd, gfc_simplify_atrigd,
gfc_simplify_atan2d): New functions.
gcc/testsuite/gfortran.dg/
* dec_math.f90: New testsuite.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d6b92a6..f8f3d4a 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -391,6 +391,7 @@ enum gfc_isym_id
GFC_ISYM_CONVERSION,
GFC_ISYM_COS,
GFC_ISYM_COSH,
+ GFC_ISYM_COTAN,
GFC_ISYM_COUNT,
GFC_ISYM_CPU_TIME,
GFC_ISYM_CSHIFT,
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 3ebe3c7..a11eb84 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1466,6 +1466,7 @@ without warning.
* Form feed as whitespace::
* TYPE as an alias for PRINT::
* %LOC as an rvalue::
+* Extended math intrinsics::
@end menu
@node Old-style kind specifications
@@ -2519,6 +2520,42 @@ integer :: i
call sub(%loc(i))
@end smallexample
+@node Extended math intrinsics
+@subsection Extended math intrinsics
+@cindex intrinsics, math
+@cindex intrinsics, trigonometric functions
+
+GNU Fortran supports an extended list of mathematical intrinsics with the
+compile flag @option{-fdec-math} for compatability with legacy code.
+These intrinsics are described fully in @ref{Intrinsic Procedures} where it is
+noted that they are extensions and should be avoided whenever possible.
+
+Specifically, @option{-fdec-math} enables the @ref{COTAN} intrinsic, and
+trigonometric intrinsics which accept or produce values in degrees instead of
+radians. Here is a summary of the new intrinsics:
+
+@multitable @columnfractions .5 .5
+@headitem Radians @tab Degrees
+@item @code{@ref{ACOS}} @tab @code{@ref{ACOSD}}*
+@item @code{@ref{ASIN}} @tab @code{@ref{ASIND}}*
+@item @code{@ref{ATAN}} @tab @code{@ref{ATAND}}*
+@item @code{@ref{ATAN2}} @tab @code{@ref{ATAN2D}}*
+@item @code{@ref{COS}}@tab @code{@ref{COSD}}*
+@item @code{@ref{COTAN}}* @tab @code{@ref{COTAND}}*
+@item @code{@ref{SIN}}@tab @code{@ref{SIND}}*
+@item @code{@ref{TAN}}@tab @code{
Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
On Mon, Oct 10, 2016 at 3:56 PM, Steve Kargl
wrote:
...
> There are a few small clean-up that can be
> done. For example,
>
> +static gfc_expr *
> +get_radians (gfc_expr *deg)
> +{
> + mpfr_t tmp;
...
> the tmp variable is unneeded in the above. Converting the double
> precision 180.0 to mpfr_t and then dividing is probably slower
> than just dividing by 180.
>
> + /* Set factor = pi / 180. */
> + factor = gfc_get_constant_expr (deg->ts.type, deg->ts.kind, °->where);
> + mpfr_const_pi (factor->value.real, GFC_RND_MODE);
> + mpfr_div_ui (factor->value.real, factor->value.real, 180, GFC_RND_MODE);
>
...
Good catch, fixed and committed r240989. Many thanks to you and Jerry.
---
Fritz Reese
Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
On Mon, 2016-10-11 08:43 AM, Markus Trippelsdorf wrote: > This patch breaks bootstrap: ... Sorry all!! was in a rush to get in the car this morning and made a hasty commit. Fixed for r241001 (sorry Jerry, I was a little too slow.) --- Fritz Reese
Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
On Tue, Oct 11, 2016 at 2:44 PM, Fritz Reese wrote: > On Mon, 2016-10-11 08:43 AM, Markus Trippelsdorf > wrote: >> This patch breaks bootstrap: > ... > > Sorry all!! was in a rush to get in the car this morning and made a > hasty commit. Fixed for r241001 (sorry Jerry, I was a little too > slow.) > > --- > Fritz Reese dec_math_4_fix.patch Description: Binary data
Re: [PATCH] Fix formatting of the -fdec-math changes
On Tue, Oct 11, 2016 at 3:00 PM, Jakub Jelinek wrote:
> On Tue, Oct 11, 2016 at 02:47:34PM -0400, Fritz Reese wrote:
>> On Tue, Oct 11, 2016 at 2:44 PM, Fritz Reese wrote:
>> > On Mon, 2016-10-11 08:43 AM, Markus Trippelsdorf
>> > wrote:
>> >> This patch breaks bootstrap:
>> > ...
>> >
>> > Sorry all!! was in a rush to get in the car this morning and made a
>> > hasty commit. Fixed for r241001 (sorry Jerry, I was a little too
>> > slow.)
>
> While looking at the changes, I've noticed various coding style and
> formatting issues (mainly wrong indentation).
>
> The patch below should resolve what I've noticed. Ok for trunk if it passes
> bootstrap/regtest?
>
> 2016-10-11 Jakub Jelinek
>
> * iresolve.c (is_trig_resolved, resolve_trig_call): Formatting fixes.
> * simplify.c (simplify_trig_call, degrees_f, radians_f,
> gfc_simplify_atrigd, gfc_simplify_cotan): Likewise.
>
Thanks for these- I thought I fixed all that stuff already, but I
guess I miffed it somewhere along the line.
...
>
> /* Resolve degree trig function as trigd (x) = trig (radians (x)). */
> --- gcc/fortran/simplify.c.jj 2016-10-11 20:51:01.767308095 +0200
> +++ gcc/fortran/simplify.c 2016-10-11 20:56:27.468199551 +0200
> @@ -1717,27 +1717,24 @@ simplify_trig_call (gfc_expr *icall)
>
>/* The actual simplifiers will return NULL for non-constant x. */
>switch (func)
> - {
> +{
...
> default:
> -break;
> - }
> -
> - gfc_internal_error ("in simplify_trig_call(): Bad intrinsic");
> - return NULL;
> + gfc_internal_error ("in simplify_trig_call(): Bad intrinsic");
> + }
> }
>
I only had a 'return NULL' so no compiler could complain that
"simplify_trig_call might not return a value". Your way is okay too if
it works.
Otherwise looks OK to me. Thanks again.
---
Fritz Reese
[PATCH, Fortran] Four small DEC extensions
Here I submit for review four small extensions to the GNU Fortran frontend for compatibility with legacy code. I figure it might be a nice change of pace from my larger patches. Never fear, for I have more large patches to come, which I will continue to submit one-at-a-time. Each extension is enabled with its own compile flag, and each are enabled along with -fdec. They are fairly self-explanatory. 1. [-fdec-feed] Treat form feed characters as whitespace. 2. [-fdec-type-print] Treat TYPE as an alias for PRINT where applicable. 3. [-fdec-loc-rval] Allow %LOC() as an rvalue, equivalent to using the LOC() intrinsic. 4. [-fdec-logical-xor] Enable .XOR. as a logical operator. Feel free to comment on/question/approve each patch individually as desired. They are attached as sequential patch files for ease of review. Bootstraps & regtests on x86_64-redhat- linux. OK for trunk? --- Fritz Reese 0001-dec-feed.patch Description: Binary data 0002-dec-type-print.patch Description: Binary data 0003-dec-loc-rval.patch Description: Binary data 0004-dec-logical-xor.patch Description: Binary data
Re: [PATCH, Fortran] Four small DEC extensions
https://gcc.gnu.org/ml/fortran/2016-10/msg00087.html et. al.
> On 12/10/16 13:30, Fritz Reese wrote:
>> Here I submit for review four small extensions to the GNU Fortran
>> frontend for compatibility with legacy code. I figure it might be a
>> nice change of pace from my larger patches. Never fear, for I have
>> more large patches to come, which I will continue to submit
>> one-at-a-time.
Sorry I took a break from this last week. Back on it this week. I
really hope I can get the rest of my major extensions in before the
next release stage, which is apparently imminent, so I might have an
overwhelming number of submissions this week...
Here's how I'm thinking of the flags situation: we use -std=legacy for
old compatibility stuff that users shouldn't use, and -fdec for
ancient compatibility stuff that users _really_ shouldn't use. So if a
user wants the compiler to mimic an old DEC compiler they hit -fdec
and get -std=legacy and all the bells and whistles of the
deleted/obsolete/compatibility extensions without question. Otherwise
they can just use -std=legacy for a more reasonable compilation, or
-std=gnu for some such extensions with reasonable warnings.
Anyway, here's a resubmission of the several patches for the four
extensions mentioned previously, plus an initial cleanup patch for
-fdec. Sorry to pork-barrel the cleanup patch in here, but it combines
some stuff I've been meaning to touch up with the change of making
-fdec into flag_dec using Fortran Var. (This is necessary for the
type-print and future extensions to be enabled with -fdec without
their own flag.)
To summarize, we have
0001 Cleanup -fdec: rolls some options in with fdec that were
documented as being a part of it previously (-fdollar-ok,
-fcray-pointer, -fd-lines-as-comments, legacy/deleted/obsolete feature
standard bits) and moves fdec-structure out of gfc_option to use
Fortran Var.
0002 [always] Form feed: feed characters ('\f') accepted as whitespace in source
0003 [-fdec] TYPE is an alias for PRINT
0004 [-std=legacy] %LOC() can be used as an rval (like the LOC() intrinsic)
0005 [-std=legacy] Support for .XOR. operator (same as .NEQV.)
The -std=legacy extensions of course compile clean with -std=legacy,
give warnings with-std=gnu, and give errors with -std=f*.
OK for trunk now? (regtests x86_64-redhat-linux)
---
Fritz Reese
==> 0001-Cleanup-fdec.patch <==
>From e2563d592af111c7f67ea7f3e41cf6b83d294b1e Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 24 Oct 2016 09:56:11 -0400
Subject: [PATCH 1/5] Cleanup -fdec.
gcc/fortran/
* invoke.texi, gfortran.texi: Touch up documentation of -fdec.
* gfortran.h (gfc_option): Move flag_dec_structure out of gfc_option.
* decl.c (match_record_decl, gfc_match_decl_type_spec,
gfc_match_structure_decl): Ditto.
* match.c (gfc_match_member_sep): Ditto.
* options.c (gfc_handle_option): Ditto.
* lang.opt (fdec-structure): Use Fortran Var for flag_dec_structure.
* lang.opt (fdec): Use Fortran Var to create flag_dec.
* options.c (set_dec_flags): With -fdec enable -fcray-pointer,
-fd-lines-as-comments (default), and legacy/deleted/obsolete standards.
==> 0002-Treat-form-feed-as-whitespace.patch <==
>From d771dd0e49c30498b6dbd94e1edc3689b5a5cab3 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 17 Oct 2016 08:44:27 -0400
Subject: [PATCH 2/5] Treat form feed as whitespace.
gcc/fortran/
* gfortran.texi: Document.
* gfortran.h (gfc_is_whitespace): Include form feed ('\f').
gcc/testsuite/gfortran.dg/
* feed_1.f90, feed_2.f90: New testcases.
==> 0003-Support-TYPE-as-alias-for-PRINT-with-fdec.patch <==
>From 3a26fbde4ace44b3565872f84c2f2dfcec813cb8 Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 24 Oct 2016 09:56:53 -0400
Subject: [PATCH 3/5] Support TYPE as alias for PRINT with -fdec.
gcc/fortran/
* decl.c (gfc_match_type): New function.
* match.h (gfc_match_type): New function.
* match.c (gfc_match_if): Special case for one-line IFs.
* gfortran.texi: Update documentation.
* parse.c (decode_statement): Invoke gfc_match_type.
gcc/testsuite/gfortran.dg/
* dec_type_print.f90: New testcase.
==> 0004-Enable-LOC-as-an-rvalue-with-std-legacy.patch <==
>From 965d3a0f3dfd4597ce5c1108bb75141e95dd1fbc Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Mon, 24 Oct 2016 09:46:58 -0400
Subject: [PATCH 4/5] Enable %LOC as an rvalue with -std=legacy.
gcc/fortran/
* primary.c (gfc_match_rvalue): Match %LOC as LOC with -std=legacy.
* gfortran.texi: Document.
gcc/testsuite/gfortran.dg/
* dec_loc_rval_1.f90, dec_loc_rval_2.f90, dec_loc_rval_3.f90: New.
==> 0005-Enable-.XOR.-operator-with-std-legacy.patch <==
>From 72f1ffbd6d7d277b212aa5265b4
Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math
On Tue, Oct 25, 2016 at 11:37 AM Cesar Philippidis
wrote:
>
> On 10/10/2016 08:06 AM, Fritz Reese wrote:
>
> > --- a/gcc/fortran/intrinsic.texi
> > +++ b/gcc/fortran/intrinsic.texi
> > @@ -23,6 +23,9 @@ Some basic guidelines for editing this document:
> > @end ignore
> >
> > @tex
> > +\gdef\acosd{\mathop{\rm acosd}\nolimits}
> > +\gdef\asind{\mathop{\rm asind}\nolimits}
> > +\gdef\atand{\mathop{\rm atand}\nolimits}
> > \gdef\acos{\mathop{\rm acos}\nolimits}
> > \gdef\asin{\mathop{\rm asin}\nolimits}
> > \gdef\atan{\mathop{\rm atan}\nolimits}
>
> There should be a new mathop for cosd or else ...
>
> > +@item @emph{Return value}:
> > +The return value is of the same type and kind as @var{X}. The real part
> > +of the result is in degrees. If @var{X} is of the type @code{REAL},
> > +the return value lies in the range @math{ -1 \leq \cosd (x) \leq 1}.
>
> ... this will cause texinfo/pdflatex to complain about an undefined
> function when you try to run 'make pdf'. The attached adds a mathop for
> cosd.
>
> Is this patch OK for trunk?
>
> Cesar
Yes, I think that counts as 'obvious'. Thanks!
---
Fritz Reese
Re: [PATCH, Fortran] Four small DEC extensions
On Mon, Oct 24, 2016 at 10:47 PM, Jerry DeLisle wrote:
> On 10/24/2016 07:23 AM, Fritz Reese wrote:
>>
>> https://gcc.gnu.org/ml/fortran/2016-10/msg00087.html et. al.
>>>
>>> On 12/10/16 13:30, Fritz Reese wrote:
>>>>
>>>> Here I submit for review four small extensions to the GNU Fortran
>>>> frontend for compatibility with legacy code. I figure it might be a
>>>> nice change of pace from my larger patches. Never fear, for I have
>>>> more large patches to come, which I will continue to submit
>>>> one-at-a-time.
...
>> OK for trunk now? (regtests x86_64-redhat-linux)
>>
>
> God do go!
>
> Jerry
>
Committed r241516, r241517, r241518, r241519.
---
Fritz Reese
---
Fritz Reese
On Mon, Oct 24, 2016 at 10:47 PM, Jerry DeLisle wrote:
> On 10/24/2016 07:23 AM, Fritz Reese wrote:
>>
>> https://gcc.gnu.org/ml/fortran/2016-10/msg00087.html et. al.
>>>
>>> On 12/10/16 13:30, Fritz Reese wrote:
>>>>
>>>> Here I submit for review four small extensions to the GNU Fortran
>>>> frontend for compatibility with legacy code. I figure it might be a
>>>> nice change of pace from my larger patches. Never fear, for I have
>>>> more large patches to come, which I will continue to submit
>>>> one-at-a-time.
>>
>>
>> Sorry I took a break from this last week. Back on it this week. I
>> really hope I can get the rest of my major extensions in before the
>> next release stage, which is apparently imminent, so I might have an
>> overwhelming number of submissions this week...
>>
>> Here's how I'm thinking of the flags situation: we use -std=legacy for
>> old compatibility stuff that users shouldn't use, and -fdec for
>> ancient compatibility stuff that users _really_ shouldn't use. So if a
>> user wants the compiler to mimic an old DEC compiler they hit -fdec
>> and get -std=legacy and all the bells and whistles of the
>> deleted/obsolete/compatibility extensions without question. Otherwise
>> they can just use -std=legacy for a more reasonable compilation, or
>> -std=gnu for some such extensions with reasonable warnings.
>>
>> Anyway, here's a resubmission of the several patches for the four
>> extensions mentioned previously, plus an initial cleanup patch for
>> -fdec. Sorry to pork-barrel the cleanup patch in here, but it combines
>> some stuff I've been meaning to touch up with the change of making
>> -fdec into flag_dec using Fortran Var. (This is necessary for the
>> type-print and future extensions to be enabled with -fdec without
>> their own flag.)
>>
>> To summarize, we have
>> 0001 Cleanup -fdec: rolls some options in with fdec that were
>> documented as being a part of it previously (-fdollar-ok,
>> -fcray-pointer, -fd-lines-as-comments, legacy/deleted/obsolete feature
>> standard bits) and moves fdec-structure out of gfc_option to use
>> Fortran Var.
>> 0002 [always] Form feed: feed characters ('\f') accepted as whitespace in
>> source
>> 0003 [-fdec] TYPE is an alias for PRINT
>> 0004 [-std=legacy] %LOC() can be used as an rval (like the LOC()
>> intrinsic)
>> 0005 [-std=legacy] Support for .XOR. operator (same as .NEQV.)
>>
>> The -std=legacy extensions of course compile clean with -std=legacy,
>> give warnings with-std=gnu, and give errors with -std=f*.
>>
>> OK for trunk now? (regtests x86_64-redhat-linux)
>>
>
> God do go!
>
> Jerry
>
Re: [PATCH, Fortran] Four small DEC extensions
On Tue, Oct 25, 2016 at 11:46 AM, Fritz Reese wrote: ... > Committed r241516, r241517, r241518, r241519. ... and r241520. --- Fritz Reese
[PATCH, Fortran] Fix initialization of UNIONs with -finit-derived
All,
Currently the '-finit-derived' flag does not handle UNIONs properly.
Specifically, a default initializer may not be appropriately generated
for BT_UNION components, leaving some memory in the middle of the
structure uninitialized even with -finit-derived. This patch ensures
UNION nodes receive a NULL structure constructor with -finit-derived
while simultaneously respecting the first user-given initializers
within the union's MAP nodes, if any. With the NULL structure
constructor the gcc middle-end figures out the full initialization, as
if you were initializing a C union like "u = {0}", and a bit of work
is saved on our end.
The front-end stores an EXPR_NULL node as the UNION's constructor
expression when -finit-derived is given and it has no user-specified
MAP initializers. When the node propagates through the resolution
phase and makes it to trans-expr.c, gfc_trans_subcomponent_assign and
gfc_conv_union_initializer use this to identify whether to generate a
null initializer or use the user-given MAP initializer.
For the attached testcases: dec_init_3.f90 exhibits improper
initialization for unions before this patch, and dec_init_4.f90
verifies that explicit user-given initializers are not regressed with
the implementation.
Since this only touches my own UNION and -finit-derived code I aim to
commit it in a few days if nobody finds anything wrong with the patch.
Bootstraps and regtests on x86_64-redhat-linux.
---
Fritz Reese
2016-10-25 Fritz Reese
Fix initialization of UNIONs with -finit-derived.
gcc/fortran/
* expr.c (generate_union_initializer, get_union_initializer): New.
* expr.c (component_initializer): Consider BT_UNION specially.
* resolve.c (resolve_structure_cons): Hack for BT_UNION.
* trans-expr.c (gfc_trans_subcomponent_assign): Ditto.
* trans-expr.c (gfc_conv_union_initializer): New.
* trans-expr.c (gfc_conv_structure): Replace UNION handling code with
new function gfc_conv_union_initializer.
gcc/testsuite/gfortran.dg/
* dec_init_1.f90, dec_init_2.f90: Remove -fdump-tree-original.
* dec_init_3.f90, dec_init_4.f90: New testcases.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index b3acf1d..1b4b96c 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4159,6 +4159,60 @@ gfc_has_default_initializer (gfc_symbol *der)
}
+/*
+ Generate an initializer expression which initializes the entirety of a
union.
+ A normal structure constructor is insufficient without undue effort, because
+ components of maps may be oddly aligned/overlapped. (For example if a
+ character is initialized from one map overtop a real from the other, only
one
+ byte of the real is actually initialized.) Unfortunately we don't know the
+ size of the union right now, so we can't generate a proper initializer, but
+ we use a NULL expr as a placeholder and do the right thing later in
+ gfc_trans_subcomponent_assign.
+ */
+static gfc_expr *
+generate_union_initializer (gfc_component *un)
+{
+ if (un == NULL || un->ts.type != BT_UNION)
+return NULL;
+
+ gfc_expr *placeholder = gfc_get_null_expr (&un->loc);
+ placeholder->ts = un->ts;
+ return placeholder;
+}
+
+
+/* Get the user-specified initializer for a union, if any. This means the user
+ has said to initialize component(s) of a map. For simplicity's sake we
+ only allow the user to initialize the first map. We don't have to worry
+ about overlapping initializers as they are released early in resolution (see
+ resolve_fl_struct). */
+
+static gfc_expr *
+get_union_initializer (gfc_symbol *union_type, gfc_component **map_p)
+{
+ gfc_component *map;
+ gfc_expr *init=NULL;
+
+ if (!union_type || union_type->attr.flavor != FL_UNION)
+return NULL;
+
+ for (map = union_type->components; map; map = map->next)
+{
+ if (gfc_has_default_initializer (map->ts.u.derived))
+{
+ init = gfc_default_initializer (&map->ts);
+ if (map_p)
+*map_p = map;
+ break;
+}
+}
+
+ if (map_p && !init)
+*map_p = NULL;
+
+ return init;
+}
+
/* Fetch or generate an initializer for the given component.
Only generate an initializer if generate is true. */
@@ -4176,6 +4230,43 @@ component_initializer (gfc_typespec *ts, gfc_component
*c, bool generate)
if (c->ts.type == BT_DERIVED || c->ts.type == BT_CLASS)
init = gfc_generate_initializer (&c->ts, true);
+ else if (c->ts.type == BT_UNION && c->ts.u.derived->components)
+{
+ gfc_component *map = NULL;
+ gfc_constructor *ctor;
+ gfc_expr *user_init;
+
+ /* If we don't have a user initializer and we aren't generating one, this
+ union has no initializer. */
+ user_init = get_union_initializer (c->ts.u.deri
[PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec
All-
Proposed here is another compatibility extension to the GNU Fortran
frontend which allows logical operations on integer operands with the
-fdec flag. In this case the logical operator is replaced with its
bitwise equivalent.
For example, GNU Fortran by default (correctly) produces an error for
the expression "A .AND. B" when A and/or B are integers. With this
patch when the -fdec legacy compatibility flag is asserted, GNU
Fortran instead silently replaces the expression with "IAND(A, B)",
performing a bitwise-and on the integers A and B. This behavior is to
match the behavior of legacy compilers, and expectations of some
legacy code.
This extension was originally implemented under its own flag
"-fdec-bitwise-ops", but following the recent trend I have just rolled
it into "-fdec". I thought the behavior might be too drastic for
-std=legacy, but if anyone has a different opinion I can certainly do
this with -std=legacy instead of -fdec.
Bootstraps and regtests on x86_64-redhat-linux, OK for trunk?
---
Fritz Reese
From: Fritz Reese
Date: Mon, 24 Oct 2016 13:47:38 -0400
Subject: [PATCH] Logical operations on integers become bitwise ops with -fdec.
gcc/fortran/
* gfortran.texi: Document.
* resolve.c (logical_to_bitwise): New function.
* resolve.c (resolve_operator): Wrap operands with logical_to_bitwise.
gcc/testsuite/gfortran.dg/
* dec_bitwise_ops_1.f90, dec_bitwise_ops_2.f90: New testcases.
---
gcc/fortran/gfortran.texi | 38 ++
gcc/fortran/resolve.c | 105 +++
gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90 | 106
gcc/testsuite/gfortran.dg/dec_bitwise_ops_2.f90 | 155 +++
4 files changed, 404 insertions(+), 0 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_bitwise_ops_2.f90
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 60b619f..0278bd6 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1469,6 +1469,7 @@ compatibility extensions along with those enabled by
@option{-std=legacy}.
* TYPE as an alias for PRINT::
* %LOC as an rvalue::
* .XOR. operator::
+* Bitwise logical operators::
@end menu
@node Old-style kind specifications
@@ -2567,6 +2568,43 @@ GNU Fortran supports @code{.XOR.} as a logical operator
with @code{-std=legacy}
for compatibility with legacy code. @code{.XOR.} is equivalent to
@code{.NEQV.}. That is, the output is true if and only if the inputs differ.
+@node Bitwise logical operators
+@subsection Bitwise logical operators
+@cindex logical, bitwise
+
+With @option{-fdec}, GNU Fortran relaxes the type constraints on
+logical operators to allow integer operands, and performs the corresponding
+bitwise operation instead. This flag is for compatibility only, and should be
+avoided in new code. Consider:
+
+@smallexample
+ INTEGER :: i, j
+ i = z'33'
+ j = z'cc'
+ print *, i .AND. j
+@end smallexample
+
+In this example, compiled with @option{-fdec}, GNU Fortran will
+replace the @code{.AND.} operation with a call to the intrinsic
+@code{@ref{IAND}} function, yielding the bitwise-and of @code{i} and @code{j}.
+
+Note that this conversion will occur if at least one operand is of integral
+type. As a result, a logical operand will be converted to an integer when the
+other operand is an integer in a logical operation. In this case,
+@code{.TRUE.} is converted to @code{1} and @code{.FALSE.} to @code{0}.
+
+Here is the mapping of logical operator to bitwise intrinsic used with
+@option{-fdec}:
+
+@multitable @columnfractions .25 .25 .5
+@headitem Operator @tab Intrinsic @tab Bitwise operation
+@item @code{.NOT.} @tab @code{@ref{NOT}} @tab complement
+@item @code{.AND.} @tab @code{@ref{IAND}} @tab intersection
+@item @code{.OR.} @tab @code{@ref{IOR}} @tab union
+@item @code{.NEQV.} @tab @code{@ref{IEOR}} @tab exclusive or
+@item @code{.EQV.} @tab @code{@ref{NOT}(@ref{IEOR})} @tab complement of
exclusive or
+@end multitable
+
@node Extensions not implemented in GNU Fortran
@section Extensions not implemented in GNU Fortran
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 4645b57..3c5892b 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -3522,6 +3522,88 @@ compare_shapes (gfc_expr *op1, gfc_expr *op2)
return t;
}
+/* Convert a logical operator to the corresponding bitwise intrinsic call.
+ For example A .AND. B becomes IAND(A, B). */
+static gfc_expr *
+logical_to_bitwise (gfc_expr *e)
+{
+ gfc_expr *tmp, *op1, *op2;
+ gfc_isym_id isym;
+ gfc_actual_arglist *args = NULL;
+
+ gcc_assert (e->expr_type == EXPR_OP);
+
+ isym = GFC_ISYM_NONE;
+ op1 = e->value.op.op1;
+ op2 = e->value.op.op2;
+
+ switch (e->value.op.op)
+{
+case INTRINSIC_NOT:
+
[PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
All, Here's the big one. This patch proposes an extension to both the GNU Fortran front-end and runtime library (libgfortran) to support three additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for compatibility with legacy compilers/code. Here's a summary of what the specifiers actually do: CARRIAGECONTROL is to control line termination settings between output records. READONLY implies ACTION='READ' and additionally prevents STATUS='DELETE' from deleting a file on CLOSE. SHARE provides OS-level locks. These specifiers are designed to match the syntax and behavior of legacy compilers. For more info see the attached test cases, source code, and documentation. Each comes with an IOPARM_OPEN_ bit, and CC+SHARE have IOPARM_INQUIRE_ bits. The st_parameter_dt structure needs an additional two bytes to propagate information with CARRIAGECONTROL='FORTRAN'. These two bytes still leave plenty of trailing 'pad' for future expansion. Bootstraps and regtests on x86_64-redhat-linux. There's a fair bit to sift through, so feel free to ask for clarification or provide comments/constructive criticism. OK for trunk? --- Fritz Reese From: Fritz Reese Date: Wed, 5 Oct 2016 20:18:16 -0400 Subject: [PATCH] New I/O specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec gcc/fortran/ * gfortran.texi: Document. * frontend-passes.c (gfc_code_walker): Add SHARE and CARRIAGECONTROL. * io.c (gfc_free_open, gfc_resolve_open, gfc_match_open): Ditto. * gfortran.h (gfc_open): Add SHARE, CARRIAGECONTROL, and READONLY. * io.c (io_tag, match_open_element): Ditto. * ioparm.def: Ditto. * trans-io.c (gfc_trans_open): Ditto. * io.c (match_dec_etag, match_dec_ftag): New functions. libgfortran/io/ * libgfortran.h (IOPARM_OPEN_HAS_READONLY, IOPARM_OPEN_HAS_SHARE, IOPARM_OPEN_HAS_CC): New for READONLY, SHARE, and CARRIAGECONTROL. * close.c (st_close): Support READONLY. * io.h (st_parameter_open, unit_flags): Support SHARE, CARRIAGECONTROL, and READONLY. * open.c (st_open): Ditto. * transfer.c (data_transfer_init): Ditto. * io.h (st_parameter_dt): New member 'cc' for CARRIAGECONTROL. * write.c (write_check_cc, write_cc): New functions for CARRIAGECONTROL. * transfer.c (next_record_cc): Ditto. * file_pos.c (st_endfile): Support SHARE and CARRIAGECONTROL. * io.h (st_parameter_inquire): Ditto. * open.c (edit_modes, new_unit): Ditto. * inquire.c (inquire_via_unit, inquire_via_filename): Ditto. * io.h (unit_share, unit_cc, cc_fortran, IOPARM_INQUIRE_HAS_SHARE, IOPARM_INQUIRE_HAS_CC): New for SHARE and CARRIAGECONTROL. * open.c (share_opt, cc_opt): Ditto. * read.c (read_x): Support CARRIAGECONTROL. * transfer.c (read_sf, next_record_r, next_record_w): Ditto. * write.c (list_formatted_write_scalar, write_a): Ditto. * unix.h (close_share): New prototype. * unix.c (open_share, close_share): New functions to handle SHARE. * unix.c (open_external): Handle READONLY. Call open_share. * close.c (st_close): Call close_share. gcc/testsuite/ * dec_io_1.f90: New test. * dec_io_2.f90: New test. * dec_io_3.f90: New test. * dec_io_4.f90: New test. * dec_io_5.f90: New test. * dec_io_6.f90: New test. --- gcc/fortran/frontend-passes.c |2 + gcc/fortran/gfortran.h |6 +- gcc/fortran/gfortran.texi | 92 - gcc/fortran/io.c | 177 +++- gcc/fortran/ioparm.def |6 + gcc/fortran/trans-io.c | 15 +++ gcc/testsuite/gfortran.dg/dec_io_1.f90 | 101 ++ gcc/testsuite/gfortran.dg/dec_io_2.f90 | 104 +++ gcc/testsuite/gfortran.dg/dec_io_3.f90 | 15 +++ gcc/testsuite/gfortran.dg/dec_io_4.f90 | 17 +++ gcc/testsuite/gfortran.dg/dec_io_5.f90 | 17 +++ gcc/testsuite/gfortran.dg/dec_io_6.f90 | 15 +++ libgfortran/io/close.c | 16 ++- libgfortran/io/file_pos.c |2 + libgfortran/io/inquire.c | 58 +++ libgfortran/io/io.h| 51 + libgfortran/io/open.c | 47 + libgfortran/io/read.c |3 +- libgfortran/io/transfer.c | 59 +-- libgfortran/io/unit.c |6 + libgfortran/io/unix.c | 89 - libgfortran/io/unix.h |3 + libgfortran/io/write.c | 141 +- libgfortran/libgfortran.h |4 + 24 files changed, 1024 insertions(+), 22 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/dec_io_1.f90 create mode 1006
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Tue, Oct 25, 2016 at 5:29 PM, Jerry DeLisle wrote: > On 10/25/2016 11:52 AM, Fritz Reese wrote: >> >> All, >> >> Here's the big one. This patch proposes an extension to both the GNU >> Fortran front-end and runtime library (libgfortran) to support three >> additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for >> compatibility with legacy compilers/code. ... >> > I have started reviewing this. I assume you have tested on some if not all > of your DEC code base. Have you compared results with ifort? Yes, my original development process is to match outputs with the version of ifort I have where it makes sense. I have compared the CARRIAGECONTROL in particular quite extensively with ifort and it gives the same output for inputs I can think of, which mostly comprise of the ones in the DG tests. READONLY functions the same. > How have you tested the SHARE feature? Do you have a test with multiple > threads accessing a single file? or do I misunderstand that feature? (I > don't mean in the testsuite, I mean as just your own testing.) For SHARE, I had test programs open files with the various SHARE= types and try to read/write them from separate processes (manually through separate terminal windows), verifying that the locking occurs according to the OS specs. I believe you understand correctly. I also used 'strace' on those programs to verify the OS calls occured in the correct order. Not sure how I could put such tests into DG so I didn't bother. Thanks again for all the help with the reviews. --- Fritz Reese
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Tue, Oct 25, 2016 at 11:36 PM, Jerry DeLisle wrote: > On 10/25/2016 11:52 AM, Fritz Reese wrote: >> >> All, >> >> Here's the big one. This patch proposes an extension to both the GNU >> Fortran front-end and runtime library (libgfortran) to support three >> additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for >> compatibility with legacy compilers/code. ... >> OK for trunk? >> > > Patch applies with a few minor offsets, regression tests OK, indentation > looks good. Test cases are thorough. I appreciate that you guarded the > open_share and close_share with the #if defined(HAVE_FCNTL) && > defined(F_SETLK) && defined(F_UNLCK). I am pretty sure not all platforms > will support these. > > Good Job, > > Yes, OK to commit. > > Jerry > Thanks- committed r241550. ((big sigh of relief)) --- Fritz Reese
Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec
On Wed, Oct 26, 2016 at 6:16 AM, Andreas Schwab wrote: > On Okt 25 2016, Fritz Reese wrote: > >> * dec_bitwise_ops_1.f90, dec_bitwise_ops_2.f90: New testcases. > > I'm getting these errors on ia64: > > FAIL: gfortran.dg/dec_bitwise_ops_1.f90 -O0 (test for excess errors) > Excess errors: > /usr/local/gcc/gcc-20161026/gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90:33:16: > Error: Can't convert INTEGER(4) to INTEGER(4) at (1) ... Looking into this. --- Fritz Reese
Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec
On Wed, Oct 26, 2016 at 6:16 AM, Andreas Schwab wrote:
> On Okt 25 2016, Fritz Reese wrote:
>
>> * dec_bitwise_ops_1.f90, dec_bitwise_ops_2.f90: New testcases.
>
> I'm getting these errors on ia64:
>
> FAIL: gfortran.dg/dec_bitwise_ops_1.f90 -O0 (test for excess errors)
> Excess errors:
> /usr/local/gcc/gcc-20161026/gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90:33:16:
> Error: Can't convert INTEGER(4) to INTEGER(4) at (1)
> /usr/local/gcc/gcc-20161026/gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90:34:16:
> Error: Can't convert INTEGER(4) to INTEGER(4) at (1)
> /usr/local/gcc/gcc-20161026/gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90:35:24:
> Error: Can't convert INTEGER(4) to INTEGER(4) at (1)
...
Andreas,
I can't seem to reproduce this on x86-64. Did you fully apply the
patch? I think this section of code in resolve.c should be guarding
against type to same-type conversions in this case:
>>> resolve.c:3719 (resolve_operator)
/* Logical ops on integers become bitwise ops with -fdec. */
else if (flag_dec
&& (op1->ts.type == BT_INTEGER || op2->ts.type == BT_INTEGER))
{
e->ts.type = BT_INTEGER;
e->ts.kind = gfc_kind_max (op1, op2);
if (op1->ts.type != e->ts.type || op1->ts.kind != e->ts.kind)
gfc_convert_type (op1, &e->ts, 1);
if (op2->ts.type != e->ts.type || op2->ts.kind != e->ts.kind)
gfc_convert_type (op2, &e->ts, 1);
e = logical_to_bitwise (e);
return resolve_function (e);
}
<<<
---
Fritz Reese
[PATCH, Fortran] DEC Compatibility: Default missing exponents to 0 with -fdec
All,
Attached is a patch to the GNU Fortran front-end and runtime library
(libgfortran) which accepts real numbers with missing exponents as if
'0' was given as the exponent when the compile flag -fdec is given,
for further compatibility with legacy compilers. By default, GNU
Fortran will reject real constants such as '9e' or '15.2e'. With the
patch and -fdec, such numbers are accepted and treated as '9e0' (9) or
'15.2e0' (15.2), both at compile-time through the front-end and at
runtime through libgfortran.
For compile-time this is trivial. For runtime, An IOPARM_DT flag bit
is added to the usual flags to track whether a program was compiled
with the "default exponent" behavior, which the library can detect at
runtime for programs individually. No space is required in the
st_parameter_dt structure, and the behavior should be
backwards-compatible (by design of the IOPARM structures/flags).
Bootstraps and regtests on x86_64-redhat-linux. OK for trunk?
---
Fritz Reese
From: Fritz Reese
Date: Wed, 5 Oct 2016 18:27:56 -0400
Subject: [PATCH] Default missing exponents to 0 with -fdec.
gcc/fortran/
* gfortran.texi: Document.
* gfortran.h (gfc_dt): New field default_exp.
* primary.c (match_real_constant): Default exponent with -fdec.
* io.c (match_io): Set dt.default_exp with -fdec.
* ioparm.def (IOPARM_dt_default_exp): New.
* trans-io.c (build_dt): Set IOPARM_dt_default_exp with -fdec.
libgfortran/io/
* io.h (IOPARM_DT_DEFAULT_EXP): New flag bit.
* list_read.c (parse_real, read_real): Allow omission of exponent with
IOPARM_DT_DEFAULT_EXP.
* read.c (read_f): Ditto.
gcc/testsuite/gfortran.dg/
* dec_exp_1.f90, dec_exp_2.f90, dec_exp_3.f90: New testcases.
---
gcc/fortran/gfortran.h |1 +
gcc/fortran/gfortran.texi | 10
gcc/fortran/io.c|4 +++
gcc/fortran/ioparm.def |1 +
gcc/fortran/primary.c | 19
gcc/fortran/trans-io.c |3 ++
gcc/testsuite/gfortran.dg/dec_exp_1.f90 | 35 +++
gcc/testsuite/gfortran.dg/dec_exp_2.f90 | 13 +++
gcc/testsuite/gfortran.dg/dec_exp_3.f90 | 15 +
libgfortran/io/io.h |1 +
libgfortran/io/list_read.c | 22 +-
libgfortran/io/read.c |8 ++-
12 files changed, 124 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_exp_1.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_exp_2.f90
create mode 100644 gcc/testsuite/gfortran.dg/dec_exp_3.f90
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index ea4437c..a0dcf6d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2336,6 +2336,7 @@ typedef struct
gfc_expr *io_unit, *format_expr, *rec, *advance, *iostat, *size, *iomsg,
*id, *pos, *asynchronous, *blank, *decimal, *delim, *pad, *round,
*sign, *extra_comma, *dt_io_kind, *udtio;
+ char default_exp;
gfc_symbol *namelist;
/* A format_label of `format_asterisk' indicates the "*" format */
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index e65c2de..85ab31b 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1471,6 +1471,7 @@ compatibility extensions along with those enabled by
@option{-std=legacy}.
* .XOR. operator::
* Bitwise logical operators::
* Extended I/O specifiers::
+* Default exponents::
@end menu
@node Old-style kind specifications
@@ -2696,6 +2697,15 @@ supported on other systems.
@end table
+@node Default exponents
+@subsection Default exponents
+@cindex exponent
+
+For compatibility, GNU Fortran supports a default exponent of zero in real
+constants with @option{-fdec}. For example, @code{9e} would be
+interpreted as @code{9e0}, rather than an error.
+
+
@node Extensions not implemented in GNU Fortran
@section Extensions not implemented in GNU Fortran
@cindex extensions, not implemented
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index dce0f7c..5f50969 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -4163,6 +4163,10 @@ get_io_list:
goto syntax;
}
+ /* See if we want to use defaults for missing exponents in real transfers.
*/
+ if (flag_dec)
+dt->default_exp = 1;
+
/* A full IO statement has been matched. Check the constraints. spec_end is
supplied for cases where no locus is supplied. */
m = check_io_constraints (k, dt, io_code, &spec_end);
diff --git a/gcc/fortran/ioparm.def b/gcc/fortran/ioparm.def
index f1bf733..4669187 100644
--- a/gcc/fortran/ioparm.def
+++ b/gcc/fortran/ioparm.def
@@ -118,4 +118,5 @@ IOPARM (dt, round, 1 << 23, char2)
IOPARM (dt, sign, 1 <&
Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec
On Wed, Oct 26, 2016 at 10:32 AM, Andreas Schwab wrote: > On Okt 26 2016, Fritz Reese wrote: > >> I can't seem to reproduce this on x86-64. Did you fully apply the >> patch? > > I don't have any patches. > Sorry for the confusion, I meant the originally attached dec_bitwise_ops.diff. I am just wondering whether your compiler build is up-to-date with trunk. If so, I am not sure how to narrow down the issue without more debug info like a traceback or memory dump at the point of error. It looks to be working for me, and the code path executes as I expect for me with a manual trace through the compilation. --- Fritz Reese
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Thu, Oct 27, 2016 at 7:02 AM Andreas Schwab wrote: ... > At line 12 of file > /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = 8) > Fortran runtime error: Cannot open file 'test.txt': No such file or directory > Indeed. From: Fritz Reese Date: Thu, 27 Oct 2016 07:07:43 -0400 Subject: [PATCH] Fix open of nonexistant file in DEC I/O testcase. gcc/testsuite/gfortran.dg/ * dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt' * dec_io_6.f90: Create 'dec_io_6.txt' before reading it --- gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +- gcc/testsuite/gfortran.dg/dec_io_6.f90 |8 +++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/gcc/testsuite/gfortran.dg/dec_io_5.f90 b/gcc/testsuite/gfortran.dg/dec_io_5.f90 index 9d44c6e..a99aa76 100644 --- a/gcc/testsuite/gfortran.dg/dec_io_5.f90 +++ b/gcc/testsuite/gfortran.dg/dec_io_5.f90 @@ -8,7 +8,7 @@ implicit none integer :: fd = 8 -character(*), parameter :: f = "test.txt" +character(*), parameter :: f = "dec_io_5.txt" character(10), volatile :: c c = 'write' diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90 b/gcc/testsuite/gfortran.dg/dec_io_6.f90 index a0c0256..3c9ae5d 100644 --- a/gcc/testsuite/gfortran.dg/dec_io_6.f90 +++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90 @@ -7,9 +7,15 @@ implicit none integer :: fd = 8 -character(*), parameter :: f = "test.txt" +character(*), parameter :: f = "dec_io_6.txt" + +open(unit=fd,file=f,action='write') +close(unit=fd) open(unit=fd,file=f,action='read',readonly) close(unit=fd,status='delete') ! XFAIL "protected by READONLY" +open(unit=fd,file=f,action='write') +close(unit=fd,status='delete') + end
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Thu, Oct 27, 2016 at 7:32 AM, Jakub Jelinek wrote: > On Thu, Oct 27, 2016 at 07:25:24AM -0400, Fritz Reese wrote: >> On Thu, Oct 27, 2016 at 7:02 AM Andreas Schwab wrote: >> ... >> > At line 12 of file >> > /usr/local/gcc/gcc-20161027/gcc/testsuite/gfortran.dg/dec_io_6.f90 (unit = >> > 8) >> > Fortran runtime error: Cannot open file 'test.txt': No such file or >> > directory >> > >> >> Indeed. > > Shouldn't something also remove dec_io_5.txt file if it is created? > Shall the (now xfailed, so not implemented yet?) runtime error terminate > the program, or can it be also just deleted later on? If not, > we'll need some dg-final cleanup-target-file or something similar that will > remote_file target delete the file (similarly to cleanup-modules etc.). > > Jakub For dec_io_5, the program (intentionally) crashes because "ACTION conflicts with READONLY" so dec_io_5.txt is never created. For dec_io_6, the "protected by READONLY" message is (intentionally) a runtime warning and does not terminate the program, so the following lines safely delete dec_io_6.txt. I am not familiar enough with DG to know whether there is a better way to express the intended behavior of the test programs. XFAIL is the closest thing I could determine. --- Fritz Reese
Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec
How odd. Good catch. --- Fritz Reese On Thu, Oct 27, 2016 at 4:41 AM, Andreas Schwab wrote: > I have filed PR78128, this may be a target bug. > > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Thu, Oct 27, 2016 at 8:16 AM, Jakub Jelinek wrote: > On Thu, Oct 27, 2016 at 07:46:16AM -0400, Fritz Reese wrote: >> > Shouldn't something also remove dec_io_5.txt file if it is created? >> > Shall the (now xfailed, so not implemented yet?) runtime error terminate >> > the program, or can it be also just deleted later on? If not, >> > we'll need some dg-final cleanup-target-file or something similar that will >> > remote_file target delete the file (similarly to cleanup-modules etc.). >> > >> > Jakub >> >> For dec_io_5, the program (intentionally) crashes because "ACTION >> conflicts with READONLY" so dec_io_5.txt is never created. > > So why dec_io_6.f90 worked at all (if it ever worked)? > And why the xfail when it works as expected? >> >> For dec_io_6, the "protected by READONLY" message is (intentionally) a >> runtime warning and does not terminate the program, so the following >> lines safely delete dec_io_6.txt. The presence of "test.txt" in dec_io_6.f90 was an artifact of me using the same "test.txt" file for all dec_io_1 through dec_io_5 in my own private tests. Thus since "test.txt" already existed from my own tests I didn't catch when I forgot to switch to "dec_io_6.txt" before submitting. I had the XFAIL in because I thought the DG failure was coming from the runtime warning. I guess the fail was actually happening because "test.txt" didn't exist - now that I correctly renamed it to "dec_io_6.txt" you are right and the XFAIL is erroneous. I should actually use INQUIRE to check whether the file was deleted on close (it should not be for READONLY). Do you know if there is there any way from DG to verify that a runtime warning is emitted? --- Fritz Reese From: Fritz Reese Date: Thu, 27 Oct 2016 08:46:33 -0400 Subject: [PATCH] Fix some DEC I/O testcases. gcc/testsuite/gfortran.dg/ * dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt'. * dec_io_6.f90: Use 'dec_io_6.txt' and INQUIRE instead of XFAIL. --- gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +- gcc/testsuite/gfortran.dg/dec_io_6.f90 | 19 --- 2 files changed, 17 insertions(+), 4 deletions(-)
Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec
On Thu, Oct 27, 2016 at 8:49 AM, Fritz Reese wrote:
> From: Fritz Reese
> Date: Thu, 27 Oct 2016 08:46:33 -0400
> Subject: [PATCH] Fix some DEC I/O testcases.
>
> gcc/testsuite/gfortran.dg/
> * dec_io_5.f90: Rename 'test.txt' to 'dec_io_5.txt'.
> * dec_io_6.f90: Use 'dec_io_6.txt' and INQUIRE instead of XFAIL.
> ---
> gcc/testsuite/gfortran.dg/dec_io_5.f90 |2 +-
> gcc/testsuite/gfortran.dg/dec_io_6.f90 | 19 ---
> 2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/dec_io_5.f90
b/gcc/testsuite/gfortran.dg/dec_io_5.f90
index 9d44c6e..a99aa76 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_5.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_5.f90
@@ -8,7 +8,7 @@
implicit none
integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_5.txt"
character(10), volatile :: c
c = 'write'
diff --git a/gcc/testsuite/gfortran.dg/dec_io_6.f90
b/gcc/testsuite/gfortran.dg/dec_io_6.f90
index a0c0256..c34879a 100644
--- a/gcc/testsuite/gfortran.dg/dec_io_6.f90
+++ b/gcc/testsuite/gfortran.dg/dec_io_6.f90
@@ -1,4 +1,4 @@
-! { dg-do run "xfail *-*-*" }
+! { dg-do run }
! { dg-options "-fdec" }
!
! Test that we get a run-time error for close-on-delete with READONLY.
@@ -7,9 +7,22 @@
implicit none
integer :: fd = 8
-character(*), parameter :: f = "test.txt"
+character(*), parameter :: f = "dec_io_6.txt"
+logical :: exists
+
+open(unit=fd,file=f,action='write')
+close(unit=fd)
open(unit=fd,file=f,action='read',readonly)
-close(unit=fd,status='delete') ! XFAIL "protected by READONLY"
+close(unit=fd,status='delete') ! WARN "protected by READONLY"
+
+inquire(file=f, EXIST=exists)
+if (.not. exists) then
+ print *, 'file was not protected by READONLY!'
+ call abort()
+endif
+
+open(unit=fd,file=f,action='write')
+close(unit=fd,status='delete') ! cleanup
end
