Fortran patches to be reviewed (was: [Patch, Fortran] PR91640 – Fix call to contiguous dummy)

[Thomas Koenig]

Hi Tobias,

PS: I lost a bit the overview. Is there any patch pending review or 
otherwise pending?


From my side, there is the patch for PR 65428,

https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00040.html

Apart from that, I don't see any outstanding patches.

Regards

Thomas

Re: Fortran patches

[Steve Kargl]

On Thu, Dec 06, 2018 at 05:21:32PM -0800, Steve Kargl wrote:
> 
> Here's an alternative patch that would reject a subroutine
> with an alternate return dummy argument with the bind(c)
> attributes.  I'm still trying to determine if the code 
> should be legal.  The c.l.f thread I started isn't helping :(

I think I have found the restriction.  In F2018,

C1554  If proc-language-binding-spec is specified for a procedure, each
   of its dummy arguments shall be an interoperable procedure (18.3.7)
   or a variable that is interoperable (18.3.5, 18.3.6), assumed-shape,
   assumed-rank, assumed-type, of type CHARACTER with assumed length,
   or that has the ALLOCATABLE or POINTER attribute.


> 
> Index: decl.c
> ===
> --- decl.c(revision 266766)
> +++ decl.c(working copy)
> @@ -7467,6 +7467,7 @@ gfc_match_subroutine (void)
>match is_bind_c;
>char peek_char;
>bool allow_binding_name;
> +  locus loc;
>  
>if (gfc_current_state () != COMP_NONE
>&& gfc_current_state () != COMP_INTERFACE
> @@ -7532,6 +7533,8 @@ gfc_match_subroutine (void)
>/* Here, we are just checking if it has the bind(c) attribute, and if
>   so, then we need to make sure it's all correct.  If it doesn't,
>   we still need to continue matching the rest of the subroutine line.  */
> +  gfc_gobble_whitespace ();
> +  loc = gfc_current_locus;
>is_bind_c = gfc_match_bind_c (sym, allow_binding_name);
>if (is_bind_c == MATCH_ERROR)
>  {
> @@ -7543,6 +7546,8 @@ gfc_match_subroutine (void)
>  
>if (is_bind_c == MATCH_YES)
>  {
> +  gfc_formal_arglist *arg;
> +
>/* The following is allowed in the Fortran 2008 draft.  */
>if (gfc_current_state () == COMP_CONTAINS
> && sym->ns->proc_name->attr.flavor != FL_MODULE
> @@ -7556,8 +7561,17 @@ gfc_match_subroutine (void)
>gfc_error ("Missing required parentheses before BIND(C) at %C");
>return MATCH_ERROR;
>  }
> -  if (!gfc_add_is_bind_c (&(sym->attr), sym->name,
> -   &(sym->declared_at), 1))
> +
> +  /* Scan the dummy arguments for an alternate return.  */
> +  for (arg = sym->formal; arg; arg = arg->next)
> + if (!arg->sym)
> +   {
> + gfc_error ("Alternate return dummy argument cannot appear in a "
> +"SUBROUTINE with the BIND(C) attribute at %L", );
> + return MATCH_ERROR;
> +   }
> +
> +  if (!gfc_add_is_bind_c (&(sym->attr), sym->name, &(sym->declared_at), 
> 1))
>  return MATCH_ERROR;
>  }
> 
> -- 
> steve

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: Fortran patches

[Steve Kargl]

On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote:
> On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl
> >
> > > 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.

Here's an alternative patch that would reject a subroutine
with an alternate return dummy argument with the bind(c)
attributes.  I'm still trying to determine if the code 
should be legal.  The c.l.f thread I started isn't helping :(

Index: decl.c
===
--- decl.c  (revision 266766)
+++ decl.c  (working copy)
@@ -7467,6 +7467,7 @@ gfc_match_subroutine (void)
   match is_bind_c;
   char peek_char;
   bool allow_binding_name;
+  locus loc;
 
   if (gfc_current_state () != COMP_NONE
   && gfc_current_state () != COMP_INTERFACE
@@ -7532,6 +7533,8 @@ gfc_match_subroutine (void)
   /* Here, we are just checking if it has the bind(c) attribute, and if
  so, then we need to make sure it's all correct.  If it doesn't,
  we still need to continue matching the rest of the subroutine line.  */
+  gfc_gobble_whitespace ();
+  loc = gfc_current_locus;
   is_bind_c = gfc_match_bind_c (sym, allow_binding_name);
   if (is_bind_c == MATCH_ERROR)
 {
@@ -7543,6 +7546,8 @@ gfc_match_subroutine (void)
 
   if (is_bind_c == MATCH_YES)
 {
+  gfc_formal_arglist *arg;
+
   /* The following is allowed in the Fortran 2008 draft.  */
   if (gfc_current_state () == COMP_CONTAINS
  && sym->ns->proc_name->attr.flavor != FL_MODULE
@@ -7556,8 +7561,17 @@ gfc_match_subroutine (void)
   gfc_error ("Missing required parentheses before BIND(C) at %C");
   return MATCH_ERROR;
 }
-  if (!gfc_add_is_bind_c (&(sym->attr), sym->name,
- &(sym->declared_at), 1))
+
+  /* Scan the dummy arguments for an alternate return.  */
+  for (arg = sym->formal; arg; arg = arg->next)
+   if (!arg->sym)
+ {
+   gfc_error ("Alternate return dummy argument cannot appear in a "
+  "SUBROUTINE with the BIND(C) attribute at %L", );
+   return MATCH_ERROR;
+ }
+
+  if (!gfc_add_is_bind_c (&(sym->attr), sym->name, &(sym->declared_at), 1))
 return MATCH_ERROR;
 }

-- 
steve

Re: Fortran patches

[Steve Kargl]

On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote:
> >>> 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.
> 
> I know :-)
> 
> > 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 also does not allow this, and does not offer a valid interpretation
> of what it should mean.
> 
> If it has a meaning, it should be translatable into something prescribed
> by the standard with -fc-prototypes.
> 
> I have assigned the error to myself, so I will not forget to fix
> it before the gcc 9 release.
> 

I have asked on c.l.f.  It seems NAG rejects alternate return
mixed with bind(c).  FortranFan provided a complete testcase:

   subroutine foo(*) bind(C, name='f')
   end subroutine foo
program p
   interface
  subroutine bar(*) bind(C, name='f')
  end subroutine bar
   end interface
   call bar( *10 )
   print *, "Return following 'bar' invocation: jumping to 20"
   go to 20
10 print *, "THIS IS UNEXPECTED: Alternate return to 10 after bar"
20 continue
   stop
end program p

NAG rejects it.  Intel, PGI, and gfortran accept it.

-- 
Steve

Re: Fortran patches

[Steve Kargl]

On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote:
> 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, >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;
> }

Intersting.  I wonder why resolve_function() appears here.  
Hmmm, 'svn annotate' points to r241535 with the committer
being foreese. :-)  Log message says you are trying to convert
logical op on integers for DEC.  Were trying to catch the
logical functions like NOT()?

I'll include the above in my patch Saturday activities.


> > > >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

Yep.

> 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

I think we should determine what other compilers do with
BIND(C) and alternate return dummy arguments, and follow
suit.  


> > > >PR fortran/88205
> > > >* io.c (gfc_match_open): STATUS must be CHARACTER type.
> [...]
> > If I used e->where one gets
> >
> > a.f90:2:32:
> >
> > 2 |character(3), parameter :: a(0) = [character(3)::]
> >   |   1
> > Error: FORMAT tag at (1) cannot be a zero-sized array
> >
> > Now, imagine a few hundred lines separating the two statements.
> > I think the latter error locus is preferable.
> 
> Yes, I agree.
> 
> Swapping gfc_current_locus definitely works, but is possibly less
> readable(+maintainable) than my other suggestion of passing loc down
> as an argument... But that suggestion touches more code, so there are
> merits to either approach. In either case I have no real issue with
> this part of the patch regardless of implementation of the locus
> workaround.

I agree that this could get messy, but I'm hoping only
format strings need this special handling.  A Fortran
string must contain '(' and ')', so 

Re: Fortran patches

[Steve Kargl]

On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> >>> 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.
> 
> I know :-)
> 
> > 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 also does not allow this, and does not offer a valid interpretation
> of what it should mean.
> 
> If it has a meaning, it should be translatable into something prescribed
> by the standard with -fc-prototypes.
> 
> I have assigned the error to myself, so I will not forget to fix
> it before the gcc 9 release.

I think it comes down to F2018, 18.3.7, where one has

  A Fortran procedure interface is interoperable with a C functioni
  prototype if

   (1) ...
   (2) ...
   (3) ...
   (4) ...
   (5) any dummy argument without the VALUE attribute corresponds to
   a formal parameter of the prototype that is of a pointer type,
   and either (4 bullets which cannot be satisfied).

I suppose we should check what other compilers do on the 
testcase, but I only have access to gfortran.

BTW, write_proc() starts to write out the prototype before the
argument list is checked.  If the current gfc_error
is trigger, you get 

void foo (Error: Cannot convert %qs to interoperable type... 

I think you want to scan the formal argument list for errors
before writing out "void foo (".

-- 
Steve

Re: Fortran patches

[Fritz Reese]

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, >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
output the actual interoperable prototype: in this case we would
output 'int' as the return type (rather than void, as usual for
subroutines) and alternate return dummy arguments would be ignored
(not output). So the output for the example in the PR should really be
'int f()'. Something 

Re: Fortran patches

[Thomas Koenig]

Hi Steve,


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.


I know :-)


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 also does not allow this, and does not offer a valid interpretation
of what it should mean.

If it has a meaning, it should be translatable into something prescribed
by the standard with -fc-prototypes.

I have assigned the error to myself, so I will not forget to fix
it before the gcc 9 release.

Regards

Thomas

Re: Fortran patches

[Steve Kargl]

On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote:
> 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?

The patch passed regression testing on i586-*-freebsd.
I'll also do regression testing on x86_64-*-freebsd 
prior to the commit.

> 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.

> 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.

> 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.

OK. I'll check to see if this works.

> 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 (_format, dt->format_expr);
> >+  loc_tmp = gfc_current_locus;
> >+  gfc_current_locus = *loc;
> >+  if (!resolve_tag (_format, dt->format_expr))
> >+{
> >+  gfc_current_locus = loc_tmp;
> >+  return false;
> >+}
> >+  gfc_current_locus = loc_tmp;
> >+
> >   RESOLVE_TAG (_rec, dt->rec);
> >   RESOLVE_TAG (_spos, dt->pos);
> >   RESOLVE_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?

program p
   

Re: Fortran patches

[Fritz Reese]

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 (_format, dt->format_expr);
>+  loc_tmp = gfc_current_locus;
>+  gfc_current_locus = *loc;
>+  if (!resolve_tag (_format, dt->format_expr))
>+{
>+  gfc_current_locus = loc_tmp;
>+  return false;
>+}
>+  gfc_current_locus = loc_tmp;
>+
>   RESOLVE_TAG (_rec, dt->rec);
>   RESOLVE_TAG (_spos, dt->pos);
>   RESOLVE_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 != NULL) \
>+  

Fortran patches

[Steve Kargl]

I intend to commit the attached patch on Saturday.

2018-12-02  Steven G. Kargl  

PR fortran/87922
* io.c (gfc_match_open): ASYNCHRONOUS must be scalar.

PR fortran/87945
* decl.c (var_element): Inquiry parameter cannot be a data object.
(match_data_constant): Inquiry parameter can be a data
in a data statement.

PR fortran/88139
* dump-parse-tree.c (write_proc): Alternate return.

PR fortran/88025
* expr.c (gfc_apply_init): Remove asserts and check for valid
ts->u.cl->length.

PR fortran/88048
* resolve.c (check_data_variable): Convert gfc_internal_error to 
an gfc_error.  Add a nearby missing 'return false;'

PR fortran/88116
* simplify.c: Remove internal error and return gfc_bad_expr.

PR fortran/88205
* io.c (gfc_match_open): STATUS must be CHARACTER type.

PR fortran/88206
* match.c (gfc_match_type_spec): REAL can be an intrinsic function.

PR fortran/88228
* expr.c (check_null, check_elemental): Work around -fdec and
initialization with logical operators operating on integers.

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos
* io.c (gfc_resolve_filepos): Accept the locus to include in errors.
* resolve.c (gfc_resolve_code): Pass locus.
 
PR fortran/88269
* io.c (io_constraint): Update macro.  Remove incompatible use
of io_constraint and give explicit error.
 
PR fortran/88328
* io.c (resolve_tag_format): Detect zero-sized array.

2018-12-02  Steven G. Kargl  

PR fortran/87922
* gfortran.dg/pr87922.f90: New test.

PR fortran/887945
* gfortran.dg/pr87945_1.f90: New test.
* gfortran.dg/pr87945_2.f90: New test.

PR fortran/87994
* gfortran.dg/pr87994_1.f90: New test.
* gfortran.dg/pr87994_2.f90: New test.
* gfortran.dg/pr87994_3.f90: New test.

PR fortran/88025
* gfortran.dg/pr88025.f90: New test.

PR fortran/88048
* gfortran.dg/pr88048.f90: New test.

PR fortran/88116
* gfortran.dg/pr88116_1.f90: New test.
* gfortran.dg/pr88116_2.f90: New test.

PR fortran/88139
* gfortran.dg/pr88139.f90: New test.

PR fortran/88205
* gfortran.dg/pr88205.f90: New test.

PR fortran/88206
* gfortran.dg/pr88206.f90: New test.

PR fortran/88228
* gfortran.dg/pr88228.f90: New test.

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

PR fortran/88328
* gfortran.dg/pr88328.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 266718)
+++ gcc/fortran/decl.c	(working copy)
@@ -281,6 +281,14 @@ var_element (gfc_data_variable *new_var)
   if (m != MATCH_YES)
 return m;
 
+  if (new_var->expr->expr_type == EXPR_CONSTANT
+  && new_var->expr->symtree == NULL)
+{
+  gfc_error ("Inquiry parameter cannot appear in a "
+		 "data-stmt-object-list at %C");
+  return MATCH_ERROR;
+}
+
   sym = new_var->expr->symtree->n.sym;
 
   /* Symbol should already have an associated type.  */
@@ -391,6 +399,14 @@ match_data_constant (gfc_expr **result)
 }
   else if (m == MATCH_YES)
 {
+  /* If a parameter inquiry ends up here, symtree is NULL but **result
+	 contains the right constant expression.  Check here.  */
+  if ((*result)->symtree == NULL
+	  && (*result)->expr_type == EXPR_CONSTANT
+	  && ((*result)->ts.type == BT_INTEGER 
+	  || (*result)->ts.type == BT_REAL))
+	return m;
+
   /* F2018:R845 data-stmt-constant is initial-data-target.
 	 A data-stmt-constant shall be ... initial-data-target if and
 	 only if the corresponding data-stmt-object has the POINTER
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c	(revision 266718)
+++ gcc/fortran/dump-parse-tree.c	(working copy)
@@ -3259,6 +3259,14 @@ write_proc (gfc_symbol *sym)
 {
   gfc_symbol *s;
   s = f->sym;
+
+  if (!s)
+	{
+	  gfc_error_now ("Par %L, \"Nous sommes tous nes pour le mal\"",
+			 >declared_at);
+	  return;
+	}
+
   rok = get_c_type_name (&(s->ts), NULL, , _name, ,
 			 , false);
   if (rok == T_ERROR)
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 266718)
+++ gcc/fortran/expr.c	(working copy)
@@ -2688,6 +2688,9 @@ check_transformational (gfc_expr *e)
 static match
 check_null (gfc_expr *e)
 {
+  if (flag_dec && e->expr_type == EXPR_CONSTANT)
+   return MATCH_NO;
+
   if (strcmp ("null", e->symtree->n.sym->name) != 0)
 return MATCH_NO;
 
@@ -2698,6 +2701,9 @@ 

Re: [PATCH] Backport of 25 fortran patches

[Jerry DeLisle]

On 09/28/2016 12:12 PM, Steve Kargl wrote:

The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are

  fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
  fortran/69867 fortran/69962 fortran/70006 fortran/71067 fortran/71730
  fortran/71799 fortran/71859 fortran/71862 fortran/77260 fortran/77351
  fortran/77372 fortran/77380 fortran/77391 fortran/77420 fortran/77429
  fortran/77460 fortran/77506 fortran/77507 fortran/77612 fortran/77694

The patch has been bootstrapped and regression tested on
x86_64-*-freebsd.  Ok to commit?



Well, though it is preferred to backport one at a time to help with 
backtracking, I also don't think we should be too pedantic either. Thanks for 
all the work.


OK

Jerry

[PATCH] Backport of 25 fortran patches

[Steve Kargl]

The attached patch and ChangeLog entries are for the
backporting of 25 patches from trunk to the 6-branch.
The bugzilla PR's contained in the patch are

  fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514
  fortran/69867 fortran/69962 fortran/70006 fortran/71067 fortran/71730
  fortran/71799 fortran/71859 fortran/71862 fortran/77260 fortran/77351
  fortran/77372 fortran/77380 fortran/77391 fortran/77420 fortran/77429 
  fortran/77460 fortran/77506 fortran/77507 fortran/77612 fortran/77694

The patch has been bootstrapped and regression tested on
x86_64-*-freebsd.  Ok to commit?

-- 
Steve
2016-09-28  Steven G. Kargl  

PR fortran/41922
* target-memory.c (expr_to_char): Pass in locus and use it in error
messages.
(gfc_merge_initializers): Ditto.
* target-memory.h: Update prototype for gfc_merge_initializers ().
* trans-common.c (get_init_field): Use the correct locus.

PR fortran/60774
* parse.c (next_free,next_fixed): Issue error for statement label
without a statement.

PR fortran/61318
* interface.c (compare_parameter): Use better locus for error message.

PR fortran/68566
* check.c (gfc_check_reshape): Check for constant expression.

PR fortran/69514
* array.c (gfc_match_array_constructor):  If type-spec is present,
walk the array constructor performing possible conversions for 
numeric types.

PR fortran/69867
* decl.c (build_struct): Ensure that pointers point to something.

PR fortran/69962
* decl.c (gfc_set_constant_character_len):  if expr is not
constant issue an error instead of an ICE.

PR fortran/70006
* io.c (gfc_resolve_dt): Use correct locus.
* resolve.c (resolve_branch): Ditto.

PR fortran/71067
* decl.c (match_data_constant): On error, set 'result' to NULL.

PR fortran/71730
* decl.c (char_len_param_value): Check return value of
gfc_reduce_init_expr().

PR fortran/71799
* resolve.c(gfc_resolve_iterator): Failure of type conversion need
not ICE.

PR fortran/71859
* check.c(numeric_check): Prevent ICE.  Issue error for invalid
subroutine as an actual argument when numeric argument is expected.

PR fortran/71862
* class.c: Remove assert.  Iterate over component only if non-null.

PR fortran/77260
* gcc/fortran/trans-decl.c (generate_local_decl): Suppress warning
for unused variable if symbol is entry point.

PR fortran/77351
* frontend-passes.c (remove_trim,combine_array_constructor): Check for
NULL pointer.

PR fortran/77372
simplify.c (simplify_ieee_selected_real_kind): Check for NULL pointers.

PR fortran/77380
* dependency.c (gfc_check_dependency): Do not assert with
-fcoarray=lib.

PR fortran/77391
* resolve.c (deferred_requirements): New function to check F2008:C402.
(resolve_fl_variable,resolve_fl_parameter): Use it.

PR fortran/77420
* trans-common.c:  Handle array elements in equivalence when
the lower and upper bounds of array spec are NULL.

PR fortran/77429 
* dependency.c (gfc_check_dependency):  Convert gcc_assert() to
a conditional and possible call to  gfc_internal_error().

PR fortran/77460
* simplify.c (simplify_transformation_to_scalar):  On error, result
may be NULL, simply return.

PR fortran/77506
* array.c (gfc_match_array_constructor): CHARACTER(len=*) cannot
appear in an array constructor.

PR fortran/77507
* intrinsic.c (add_functions):  Use correct keyword.

PR fortran/77612
* decl.c (char_len_param_value): Check parent namespace for 
seen_implicit_none.

PR fortran/77694
* frontend-passes.c (optimize_binop_array_assignment): Check pointer
for NULL.

2016-09-28  Steven G. Kargl  

PR fortran/77507
* ieee/ieee_arithmetic.F90 (IEEE_VALUE_4,IEEE_VALUE_8,IEEE_VALULE_10,
IEEE_VALUE_16):  Use correct keyword.

2016-09-28  Steven G. Kargl  

PR fortran/41922
* gfortran.dg/equiv_constraint_5.f90: Adjust the error message.
* gfortran.dg/equiv_constraint_7.f90: Ditto.
* gfortran.dg/pr41922.f90: New test.

PR fortran/60774
* gfortran.dg/empty_label.f: Adjust test for new error message.
* gfortran.dg/empty_label.f90: Ditto.
* gfortran.dg/empty_label_typedecl.f90: Ditto.
* gfortran.dg/label_3.f90: Deleted (redundant with empty_label.f90).
* gfortran.dg/warnings_are_errors_1.f90: Remove invalid statement label.

PR fortran/61318
* gfortran.dg/pr61318.f90: New test.

PR fortran/68566
* 

Re: [fortran, patches] Two short patches to review

[FX]

 Although I suspect you've been lurking in the background,
 welcome back to the land of gfortran hacking.  Your first
 screw up is free, additional screw ups require you to
 fix your screw up and fix an additional bug as your reward.



Attached patch committed as revision 181200.
FX



convert.diff
Description: Binary data

[fortran, patches] Two short patches to review

[FX]

PRs 50540 and 50404 each contain a short patch, written by Steve. Both patches 
are straightforward:

  -- 50404: refuse to have a CLOSE statement without a UNIT (F2008's C908 A 
file-unit-number shall be specified in a close-spec-list) 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
  -- 50540: issue a normal error instead of an internal error, in conditions 
that could reasonably be triggered by invalid code 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540)

Both patches seem fine to me, and I have regtested them. Could someone review 
them and approve them for trunk? I'll then add the testcase from the PR and 
commit.

Cheers,
FX

Re: [fortran, patches] Two short patches to review

[Steve Kargl]

On Wed, Nov 09, 2011 at 12:13:10AM +0100, FX wrote:
 PRs 50540 and 50404 each contain a short patch, written by Steve.
 Both patches are straightforward:
 
 -- 50404: refuse to have a CLOSE statement without a UNIT
 (F2008's C908 A file-unit-number shall be specified in a
 close-spec-list) (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)

jerry already approved this one.

 -- 50540: issue a normal error instead of an internal error, in
 conditions that could reasonably be triggered by invalid code
 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540)

Given that you've read the patch and my comments in the PR,
and that you've contributed/reviewed/committed hundreds of
patches, I think that this is sufficient review.  I certainly
have no problems with committing the patch.

PS: I would have committed these patch except I have spent a
week or so trying to get gcc to build again after I migrated my
systems to FreeBSD 10.0 (ie., the bleeding edge).

-- 
Steve

Re: [fortran, patches] Two short patches to review

[FX]

 -- 50404: refuse to have a CLOSE statement without a UNIT
 (F2008's C908 A file-unit-number shall be specified in a
 close-spec-list) (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
 
 jerry already approved this one.

And I committed it as rev. , with a slight modification to add a decent locus 
(otherwise, the current locus is at a totally wrong place) and a testcase. 
Committed patch is attached.



close.diff
Description: Binary data



 -- 50540: issue a normal error instead of an internal error, in
 conditions that could reasonably be triggered by invalid code
 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540)
 
 Given that you've read the patch and my comments in the PR,
 and that you've contributed/reviewed/committed hundreds of
 patches, I think that this is sufficient review.  I certainly
 have no problems with committing the patch.

Well, given the amount of compliment, I'm sure to screw up and then hide :)
I'll get to it tomorrow morning, after some sleep.

Thanks,
FX

Re: [fortran, patches] Two short patches to review

[Steve Kargl]

On Wed, Nov 09, 2011 at 12:57:29AM +0100, FX wrote:
  -- 50404: refuse to have a CLOSE statement without a UNIT
  (F2008's C908 A file-unit-number shall be specified in a
  close-spec-list) (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404)
  
  jerry already approved this one.
 
 And I committed it as rev. , with a slight modification to add
 a decent locus (otherwise, the current locus is at a totally
 wrong place) and a testcase. Committed patch is attached.

Thanks!

  -- 50540: issue a normal error instead of an internal error, in
  conditions that could reasonably be triggered by invalid code
  (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540)
  
  Given that you've read the patch and my comments in the PR,
  and that you've contributed/reviewed/committed hundreds of
  patches, I think that this is sufficient review.  I certainly
  have no problems with committing the patch.
 
 Well, given the amount of compliment, I'm sure to screw up and then hide :)
 I'll get to it tomorrow morning, after some sleep.

Although I suspect you've been lurking in the background,
welcome back to the land of gfortran hacking.  Your first
screw up is free, additional screw ups require you to
fix your screw up and fix an additional bug as your reward.

:-)

-- 
Steve

Re: Fortran Patches

[Janus Weil]

 Regarding the last patch, the GNU style puts a line break after the ) in:

 +  if (!sym) return NULL;
 +

 In principle I'm aware of the GNU coding style, but apparently I
 didn't pay enough attention. Sorry again. I'll fix it ...


Fixed with r178928.

Cheers,
Janus

Fortran Patches

[Tobias Burnus]

Hi Janus,

could you also patches, which you commit as obvious to the mailing lists?

Regarding the last patch, the GNU style puts a line break after the ) in:

+  if (!sym) return NULL;
+

Tobias
commit 12c8610481cc199a6019cd41d07dbdf8906032d0
Author: janus janus@138bc75d-0d04-0410-961f-82ee72b054a4
Date:   Thu Sep 15 17:48:27 2011 +

2011-09-15  Janus Weil  ja...@gcc.gnu.org

	PR fortran/50401
	* resolve.c (resolve_transfer): Check if component 'ref' is defined.

	PR fortran/50403
	* symbol.c (gfc_use_derived): Check if argument 'sym' is defined.


2011-09-15  Janus Weil  ja...@gcc.gnu.org

	PR fortran/50401
	PR fortran/50403
	* gfortran.dg/function_types_3.f90: New.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@178889 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index eeb462f..a8e0273 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,11 @@
+2011-09-15  Janus Weil  ja...@gcc.gnu.org
+
+	PR fortran/50401
+	* resolve.c (resolve_transfer): Check if component 'ref' is defined.
+
+	PR fortran/50403
+	* symbol.c (gfc_use_derived): Check if argument 'sym' is defined.
+
 2011-09-14  Tobias Burnus  bur...@net-b.de
 
 	PR fortran/34547
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 9aab836..62750af 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8222,7 +8222,7 @@ resolve_transfer (gfc_code *code)
 	}
 }
 
-  if (sym-as != NULL  sym-as-type == AS_ASSUMED_SIZE
+  if (sym-as != NULL  sym-as-type == AS_ASSUMED_SIZE  exp-ref
exp-ref-type == REF_ARRAY  exp-ref-u.ar.type == AR_FULL)
 {
   gfc_error (Data transfer element at %L cannot be a full reference to 
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index b2f0f2b..e2f13b8 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -1945,6 +1945,8 @@ gfc_use_derived (gfc_symbol *sym)
   gfc_symtree *st;
   int i;
 
+  if (!sym) return NULL;
+
   if (sym-components != NULL || sym-attr.zero_comp)
 return sym;   /* Already defined.  */
 
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 86cdde0..0accd60 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2011-09-15  Janus Weil  ja...@gcc.gnu.org
+
+	PR fortran/50401
+	PR fortran/50403
+	* gfortran.dg/function_types_3.f90: New.
+
 2011-09-15  Jason Merrill  ja...@redhat.com
 
 	PR c++/50365
diff --git a/gcc/testsuite/gfortran.dg/function_types_3.f90 b/gcc/testsuite/gfortran.dg/function_types_3.f90
new file mode 100644
index 000..8d00f5f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/function_types_3.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+!
+! Contributed by Vittorio Zecca zec...@gmail.com
+!
+! PR 50401: SIGSEGV in resolve_transfer
+
+  interface 
+function f()  ! { dg-error must be a dummy argument }
+  dimension f(*)
+end function
+  end interface
+  print *,f()
+end
+
+! PR 50403: SIGSEGV in gfc_use_derived
+
+type(f) function f()  ! { dg-error conflicts with DERIVED attribute|is not accessible }
+  f=110   ! { dg-error Unclassifiable statement }
+end
commit cde48a27b12d2c4d1a5aababb94f6695e9c00469
Author: janus janus@138bc75d-0d04-0410-961f-82ee72b054a4
Date:   Tue Sep 13 18:37:33 2011 +

2011-09-13  Janus Weil  ja...@gcc.gnu.org

	PR fortran/50379
	* symbol.c (check_conflict): Check conflict between GENERIC and RESULT
	attributes.


2011-09-13  Janus Weil  ja...@gcc.gnu.org

	PR fortran/50379
	* gfortran.dg/result_2.f90: New.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@178829 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 836967d..6e82538 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2011-09-13  Janus Weil  ja...@gcc.gnu.org
+
+	PR fortran/50379
+	* symbol.c (check_conflict): Check conflict between GENERIC and RESULT
+	attributes.
+
 2011-09-11  Thomas Koenig  tkoe...@gcc.gnu.org
 
 	PR fortran/50327
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index ce4ab3d..b2f0f2b 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -373,7 +373,7 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where)
 *volatile_ = VOLATILE, *is_protected = PROTECTED,
 *is_bind_c = BIND(C), *procedure = PROCEDURE,
 *asynchronous = ASYNCHRONOUS, *codimension = CODIMENSION,
-*contiguous = CONTIGUOUS;
+*contiguous = CONTIGUOUS, *generic = GENERIC;
   static const char *threadprivate = THREADPRIVATE;
 
   const char *a1, *a2;
@@ -490,8 +490,6 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where)
   conf (in_common, codimension);
   conf (in_common, result);
 
-  conf (dummy, result);
-
   conf (in_equivalence, use_assoc);
   conf (in_equivalence, codimension);
   conf (in_equivalence, dummy);
@@ 

Re: Fortran Patches

[Janus Weil]

Hi Tobias,

 could you also patches, which you commit as obvious to the mailing lists?

yes, I usually do this, but this time I just forgot. Sorry.


 Regarding the last patch, the GNU style puts a line break after the ) in:

 +  if (!sym) return NULL;
 +

In principle I'm aware of the GNU coding style, but apparently I
didn't pay enough attention. Sorry again. I'll fix it ...

Cheers,
Janus