[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2019-08-04 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jerry DeLisle  ---
Fixed now on gcc9, so closing.

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2019-08-04 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Aug  5 00:47:41 2019
New Revision: 274104

URL: https://gcc.gnu.org/viewcvs?rev=274104=gcc=rev
Log:
2019-08-04  Jerry DeLisle  

Backport from trunk
PR fortran/87233
* expr.c (check_restricted): Relax constraint C1279 which was
removed from F2008 and above.

* gfortran.dg/initialization_14.f90: Modify to now pass by
removing two dg-error commands. Added comments.
* gfortran.dg/initialization_30.f90: New test that includes the
two tests removed above with the 'dg-options -std=f95'.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/initialization_30.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/expr.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/initialization_14.f90

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2019-07-14 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #7 from Jerry DeLisle  ---
Fixed on trunk. I am thinking backport this to enable gfortran 9 to not reject
valid.

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2019-07-14 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jul 14 22:52:58 2019
New Revision: 273484

URL: https://gcc.gnu.org/viewcvs?rev=273484=gcc=rev
Log:
2019-07-14  Jerry DeLisle  

PR fortran/87233
* expr.c (check_restricted): Relax constraint C1279 which was
removed from F2008 and above.

* gfortran.dg/initialization_14.f90: Modify to now pass by
removing two dg-error commands. Added comments.
* gfortran.dg/initialization_30.f90: New test that includes the
two tests removed above with the 'dg-options -std=f95'.

Added:
trunk/gcc/testsuite/gfortran.dg/initialization_30.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_14.f90

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2019-07-13 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #5 from Jerry DeLisle  ---
Patch submitted:

https://gcc.gnu.org/ml/fortran/2019-07/msg00035.html

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2018-11-18 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-18
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
(In reply to Jerry DeLisle from comment #1)
> The check is easy enough to delete:

More important: does gfortran generate the right code if the error is deleted?

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2018-09-06 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #3 from Jerry DeLisle  ---
(In reply to kargl from comment #2)
> (In reply to Jerry DeLisle from comment #1)
> > The check is easy enough to delete:
> > 
--- snip ---

> What happens with -std=f95 and -std=f2003?
> 
> -- 
> steve

Well obviously we dont have the hooks for f95 and f2003. AFAICT the code looks
acceptable per my read of f2008. So if we want to provide different levels of
diagnostics for the various version standards, I can add the hooks.  It
frustrates me since I feel like we are constantly chasing rabbits down the
rabit holes with these things. It would be nice if people just would conform to
the current standard, in this case it is more forgiving to to so.

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2018-09-05 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #1)
> The check is easy enough to delete:
> 
> diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
> index c5bf822cd24..a8e6dd389b0 100644
> --- a/gcc/fortran/expr.c
> +++ b/gcc/fortran/expr.c
> @@ -3073,19 +3073,6 @@ check_restricted (gfc_expr *e)
>sym = e->symtree->n.sym;
>t = false;
>  
> -  /* If a dummy argument appears in a context that is valid for a
> -restricted expression in an elemental procedure, it will have
> -already been simplified away once we get here.  Therefore we
> -don't need to jump through hoops to distinguish valid from
> -invalid cases.  */
> -  if (sym->attr.dummy && sym->ns == gfc_current_ns
> - && sym->ns->proc_name && sym->ns->proc_name->attr.elemental)
> -   {
> - gfc_error ("Dummy argument %qs not allowed in expression at %L",
> -sym->name, >where);
> - break;
> -   }
> -
>if (sym->attr.optional)
> {
>   gfc_error ("Dummy argument %qs at %L cannot be OPTIONAL",

What happens with -std=f95 and -std=f2003?

-- 
steve

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

2018-09-05 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
The check is easy enough to delete:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index c5bf822cd24..a8e6dd389b0 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3073,19 +3073,6 @@ check_restricted (gfc_expr *e)
   sym = e->symtree->n.sym;
   t = false;

-  /* If a dummy argument appears in a context that is valid for a
-restricted expression in an elemental procedure, it will have
-already been simplified away once we get here.  Therefore we
-don't need to jump through hoops to distinguish valid from
-invalid cases.  */
-  if (sym->attr.dummy && sym->ns == gfc_current_ns
- && sym->ns->proc_name && sym->ns->proc_name->attr.elemental)
-   {
- gfc_error ("Dummy argument %qs not allowed in expression at %L",
-sym->name, >where);
- break;
-   }
-
   if (sym->attr.optional)
{
  gfc_error ("Dummy argument %qs at %L cannot be OPTIONAL",