* [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
@ 2016-08-26 18:28 Steve Kargl
2016-08-26 18:33 ` Paul Richard Thomas
2016-08-26 20:28 ` Mikael Morin
0 siblings, 2 replies; 7+ messages in thread
From: Steve Kargl @ 2016-08-26 18:28 UTC (permalink / raw)
To: fortran, gcc-patches
Here are two possible patches for PR fortran/77391. The first
patch treats the invalid code as a GNU Fortran extension as
gfortran current accepts the invalid code. The second patch
enforces the standard. As I think gfortran should encourage
standard conformance, I am inclined to commit the second patch.
I will however commit the most popular of the two patches tomorrow.
Voting starts now and will remain open for 24 hours (give or take
a few hours depend on when I awaken).
Patch 1:
Index: decl.c
===================================================================
--- decl.c (revision 239762)
+++ decl.c (working copy)
@@ -4798,11 +4798,23 @@ gfc_match_data_decl (void)
ok:
/* If we have an old-style character declaration, and no new-style
- attribute specifications, then there a comma is optional between
+ attribute specifications, then a comma is optional between
the type specification and the variable list. */
if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
gfc_match_char (',');
+ /* F2008(C402): A colon shall not be used as a type-param-value except
+ in the declaration of an entity or component that has the POINTER
+ or ALLOCATABLE attribute. */
+ if (current_ts.type == BT_CHARACTER && current_ts.deferred
+ && !(current_attr.allocatable || current_attr.pointer)
+ && !gfc_notify_std (GFC_STD_GNU, "Deferred length type parameter "
+ "without POINTER or ALLOCATABLE attribute at %C"))
+ {
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+
/* Give the types/attributes to symbols that follow. Give the element
a number so that repeat character length expressions can be copied. */
elem = 1;
Patch 2:
Index: decl.c
===================================================================
--- decl.c (revision 239762)
+++ decl.c (working copy)
@@ -4798,11 +4798,24 @@ gfc_match_data_decl (void)
ok:
/* If we have an old-style character declaration, and no new-style
- attribute specifications, then there a comma is optional between
+ attribute specifications, then a comma is optional between
the type specification and the variable list. */
if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
gfc_match_char (',');
+ /* F2008(C402): A colon shall not be used as a type-param-value except
+ in the declaration of an entity or component that has the POINTER
+ or ALLOCATABLE attribute. */
+ if (current_ts.type == BT_CHARACTER && current_ts.deferred
+ && !(current_attr.allocatable || current_attr.pointer))
+ {
+
+ gfc_error ("Deferred length type parameter without POINTER or "
+ "ALLOCATABLE attribute at %C")
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+
/* Give the types/attributes to symbols that follow. Give the element
a number so that repeat character length expressions can be copied. */
elem = 1;
--
Steve
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-26 18:28 [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer Steve Kargl
@ 2016-08-26 18:33 ` Paul Richard Thomas
2016-08-26 20:28 ` Mikael Morin
1 sibling, 0 replies; 7+ messages in thread
From: Paul Richard Thomas @ 2016-08-26 18:33 UTC (permalink / raw)
To: Steve Kargl; +Cc: fortran, gcc-patches
Hi Steve,
I am strongly for the enforcement of the standard. Please apply patch #2.
Cheers
Paul
On 26 August 2016 at 20:27, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> Here are two possible patches for PR fortran/77391. The first
> patch treats the invalid code as a GNU Fortran extension as
> gfortran current accepts the invalid code. The second patch
> enforces the standard. As I think gfortran should encourage
> standard conformance, I am inclined to commit the second patch.
> I will however commit the most popular of the two patches tomorrow.
> Voting starts now and will remain open for 24 hours (give or take
> a few hours depend on when I awaken).
>
> Patch 1:
>
> Index: decl.c
> ===================================================================
> --- decl.c (revision 239762)
> +++ decl.c (working copy)
> @@ -4798,11 +4798,23 @@ gfc_match_data_decl (void)
>
> ok:
> /* If we have an old-style character declaration, and no new-style
> - attribute specifications, then there a comma is optional between
> + attribute specifications, then a comma is optional between
> the type specification and the variable list. */
> if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
> gfc_match_char (',');
>
> + /* F2008(C402): A colon shall not be used as a type-param-value except
> + in the declaration of an entity or component that has the POINTER
> + or ALLOCATABLE attribute. */
> + if (current_ts.type == BT_CHARACTER && current_ts.deferred
> + && !(current_attr.allocatable || current_attr.pointer)
> + && !gfc_notify_std (GFC_STD_GNU, "Deferred length type parameter "
> + "without POINTER or ALLOCATABLE attribute at %C"))
> + {
> + m = MATCH_ERROR;
> + goto cleanup;
> + }
> +
> /* Give the types/attributes to symbols that follow. Give the element
> a number so that repeat character length expressions can be copied. */
> elem = 1;
>
> Patch 2:
>
> Index: decl.c
> ===================================================================
> --- decl.c (revision 239762)
> +++ decl.c (working copy)
> @@ -4798,11 +4798,24 @@ gfc_match_data_decl (void)
>
> ok:
> /* If we have an old-style character declaration, and no new-style
> - attribute specifications, then there a comma is optional between
> + attribute specifications, then a comma is optional between
> the type specification and the variable list. */
> if (m == MATCH_NO && current_ts.type == BT_CHARACTER && old_char_selector)
> gfc_match_char (',');
>
> + /* F2008(C402): A colon shall not be used as a type-param-value except
> + in the declaration of an entity or component that has the POINTER
> + or ALLOCATABLE attribute. */
> + if (current_ts.type == BT_CHARACTER && current_ts.deferred
> + && !(current_attr.allocatable || current_attr.pointer))
> + {
> +
> + gfc_error ("Deferred length type parameter without POINTER or "
> + "ALLOCATABLE attribute at %C")
> + m = MATCH_ERROR;
> + goto cleanup;
> + }
> +
> /* Give the types/attributes to symbols that follow. Give the element
> a number so that repeat character length expressions can be copied. */
> elem = 1;
>
> --
> Steve
--
The difference between genius and stupidity is; genius has its limits.
Albert Einstein
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-26 18:28 [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer Steve Kargl
2016-08-26 18:33 ` Paul Richard Thomas
@ 2016-08-26 20:28 ` Mikael Morin
2016-08-26 20:38 ` Steve Kargl
` (2 more replies)
1 sibling, 3 replies; 7+ messages in thread
From: Mikael Morin @ 2016-08-26 20:28 UTC (permalink / raw)
To: Steve Kargl, fortran, gcc-patches
Hello,
Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> Here are two possible patches for PR fortran/77391. The first
> patch treats the invalid code as a GNU Fortran extension as
> gfortran current accepts the invalid code. The second patch
> enforces the standard. As I think gfortran should encourage
> standard conformance, I am inclined to commit the second patch.
> I will however commit the most popular of the two patches tomorrow.
> Voting starts now and will remain open for 24 hours (give or take
> a few hours depend on when I awaken).
>
I don't think it's sufficient to check current_attr because of this case:
character(:) :: a
pointer :: a
end
The statement should be accepted, and the check be postponed at a time
after the symbol has been initialised, at resolution time for example.
Mikael
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-26 20:28 ` Mikael Morin
@ 2016-08-26 20:38 ` Steve Kargl
2016-08-26 23:04 ` Steve Kargl
2016-08-27 0:06 ` Steve Kargl
2 siblings, 0 replies; 7+ messages in thread
From: Steve Kargl @ 2016-08-26 20:38 UTC (permalink / raw)
To: Mikael Morin; +Cc: fortran, gcc-patches
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code. The second patch
> > enforces the standard. As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
>
> I don't think it's sufficient to check current_attr because of this case:
>
> character(:) :: a
> pointer :: a
> end
>
> The statement should be accepted, and the check be postponed at a time
> after the symbol has been initialised, at resolution time for example.
Hmmm, yes indeed. I guess I'll need to wade through resolve.c.
--
Steve
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-26 20:28 ` Mikael Morin
2016-08-26 20:38 ` Steve Kargl
@ 2016-08-26 23:04 ` Steve Kargl
2016-08-27 0:06 ` Steve Kargl
2 siblings, 0 replies; 7+ messages in thread
From: Steve Kargl @ 2016-08-26 23:04 UTC (permalink / raw)
To: Mikael Morin; +Cc: fortran, gcc-patches
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code. The second patch
> > enforces the standard. As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
>
> I don't think it's sufficient to check current_attr because of this case:
>
> character(:) :: a
> pointer :: a
> end
>
> The statement should be accepted, and the check be postponed at a time
> after the symbol has been initialised, at resolution time for example.
>
Well, this is interesting. It seems that gfortran tried to detect
this issue. In resolve.c(resolve_fl_variable) at lines 11443-11454,
one finds
/* Constraints on deferred type parameter. */
if (sym->ts.deferred
&& !(sym->attr.pointer
|| sym->attr.allocatable
|| sym->attr.omp_udr_artificial_var))
{
gfc_error ("Entity %qs at %L has a deferred type parameter and "
"requires either the pointer or allocatable attribute",
sym->name, &sym->declared_at);
specification_expr = saved_specification_expr;
return false;
}
resolve_fl_variable is never entered for
program picky
character(len=:),parameter :: ident2="which appears"
end program picky
--
Steve
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-26 20:28 ` Mikael Morin
2016-08-26 20:38 ` Steve Kargl
2016-08-26 23:04 ` Steve Kargl
@ 2016-08-27 0:06 ` Steve Kargl
2016-08-27 12:51 ` Jerry DeLisle
2 siblings, 1 reply; 7+ messages in thread
From: Steve Kargl @ 2016-08-27 0:06 UTC (permalink / raw)
To: Mikael Morin; +Cc: fortran, gcc-patches
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code. The second patch
> > enforces the standard. As I think gfortran should encourage
> > standard conformance, I am inclined to commit the second patch.
> > I will however commit the most popular of the two patches tomorrow.
> > Voting starts now and will remain open for 24 hours (give or take
> > a few hours depend on when I awaken).
> >
>
> I don't think it's sufficient to check current_attr because of this case:
>
> character(:) :: a
> pointer :: a
> end
>
> The statement should be accepted, and the check be postponed at a time
> after the symbol has been initialised, at resolution time for example.
>
So, I've come up the following. We now need to debate whether
Dominiq's observations mean that C402 does not apply to named
constant.
2016-08-26 Steven G. Kargl <kargl@gcc.gnu.org>
PR fortran/77391
* resolve.c (deferred_requirements): New function to check F2008:C402.
(resolve_fl_variable,resolve_fl_parameter): Use it.
2016-08-26 Steven G. Kargl <kargl@gcc.gnu.org>
PR fortran/77391
* gfortran.dg/pr77391.f90: New test.
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 239762)
+++ gcc/fortran/resolve.c (working copy)
@@ -11402,6 +11402,27 @@ resolve_fl_variable_derived (gfc_symbol
}
+/* F2008, C402 (R401): A colon shall not be used as a type-param-value
+ except in the declaration of an entity or component that has the POINTER
+ or ALLOCATABLE attribute. */
+
+static bool
+deferred_requirements (gfc_symbol *sym)
+{
+ if (sym->ts.deferred
+ && !(sym->attr.pointer
+ || sym->attr.allocatable
+ || sym->attr.omp_udr_artificial_var))
+ {
+ gfc_error ("Entity %qs at %L has a deferred type parameter and "
+ "requires either the POINTER or ALLOCATABLE attribute",
+ sym->name, &sym->declared_at);
+ return false;
+ }
+ return true;
+}
+
+
/* Resolve symbols with flavor variable. */
static bool
@@ -11441,17 +11462,8 @@ resolve_fl_variable (gfc_symbol *sym, in
}
/* Constraints on deferred type parameter. */
- if (sym->ts.deferred
- && !(sym->attr.pointer
- || sym->attr.allocatable
- || sym->attr.omp_udr_artificial_var))
- {
- gfc_error ("Entity %qs at %L has a deferred type parameter and "
- "requires either the pointer or allocatable attribute",
- sym->name, &sym->declared_at);
- specification_expr = saved_specification_expr;
- return false;
- }
+ if (!deferred_requirements (sym))
+ return false;
if (sym->ts.type == BT_CHARACTER)
{
@@ -13570,6 +13582,10 @@ resolve_fl_parameter (gfc_symbol *sym)
return false;
}
+ /* Constraints on deferred type parameter. */
+ if (!deferred_requirements (sym))
+ return false;
+
/* Make sure a parameter that has been implicitly typed still
matches the implicit type, since PARAMETER statements can precede
IMPLICIT statements. */
Index: gcc/testsuite/gfortran.dg/pr77391.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr77391.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77391.f90 (working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+program picky
+character(len=:), parameter :: a="whoops" ! { dg-error "POINTER or ALLOCATABLE" }
+character(len=:) :: b="whoops" ! { dg-error "POINTER or ALLOCATABLE" }
+character(len=:) :: good
+pointer good
+end program picky
--
Steve
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer
2016-08-27 0:06 ` Steve Kargl
@ 2016-08-27 12:51 ` Jerry DeLisle
0 siblings, 0 replies; 7+ messages in thread
From: Jerry DeLisle @ 2016-08-27 12:51 UTC (permalink / raw)
To: kargl, Mikael Morin; +Cc: fortran, gcc-patches
On 08/26/2016 05:06 PM, Steve Kargl wrote:
--- snip ---
>
> So, I've come up the following. We now need to debate whether
> Dominiq's observations mean that C402 does not apply to named
> constant.
>
See my comment in the PR. The standard gives the explicit way to accomplish what
the user wants to do by use of the asterisk.
C402 Holds
Jerry
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-08-27 12:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-26 18:28 [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer Steve Kargl
2016-08-26 18:33 ` Paul Richard Thomas
2016-08-26 20:28 ` Mikael Morin
2016-08-26 20:38 ` Steve Kargl
2016-08-26 23:04 ` Steve Kargl
2016-08-27 0:06 ` Steve Kargl
2016-08-27 12:51 ` Jerry DeLisle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).