Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-09-01 Thread Paul Richard Thomas
Hi Steve, Thanks for the remarks and the OK. Committed as revision 275269. Onward to PDTs! Cheers Paul On Sat, 31 Aug 2019 at 18:46, Steve Kargl wrote: > > On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > > > > Bootstraps and regtests on FC29/x86_64 - OK for trunk? > > W

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > > Bootstraps and regtests on FC29/x86_64 - OK for trunk? Well, I've made it through to the trans-* files. Reading that part of the patch will take a awhile. I'm think you should commit. -- steve

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
On Sat, Aug 31, 2019 at 06:34:43PM +0100, Paul Richard Thomas wrote: > Hi Steve, > > > > > > If an error occurs, should this set m = MATCH_ERROR and goto cleanup? > > > > OR, set m = MATCH_ERROR, free expr1 and expr2 and return m? > > > > IOW, if an error occurs, why should gfortran continue to m

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
In resolve_select_rank you have a comment about casading error. + /* Loop over RANK cases. Note that returning on the errors causes a + cascade of further errors because the case blocks do not compile + correctly. */ Shouldn't gfortran stop looping if an error occurs? See below...

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Paul Richard Thomas
Hi Steve, > > > If an error occurs, should this set m = MATCH_ERROR and goto cleanup? > > > OR, set m = MATCH_ERROR, free expr1 and expr2 and return m? > > > IOW, if an error occurs, why should gfortran continue to match select > > > rank? This prevents or reduces the deluge of errors that come

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
On Sat, Aug 31, 2019 at 10:12:55AM -0700, Steve Kargl wrote: > On Sat, Aug 31, 2019 at 09:56:52AM -0700, Steve Kargl wrote: > > On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > > > + > > > + /* Match a SELECT RANK statement. */ > > > + > > > + match > > > + gfc_match_select

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
On Sat, Aug 31, 2019 at 09:56:52AM -0700, Steve Kargl wrote: > On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > > + > > + /* Match a SELECT RANK statement. */ > > + > > + match > > + gfc_match_select_rank (void) > > + { > > + gfc_expr *expr1, *expr2 = NULL; > > + match

Re: [Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Steve Kargl
On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > + > + /* Match a SELECT RANK statement. */ > + > + match > + gfc_match_select_rank (void) > + { > + gfc_expr *expr1, *expr2 = NULL; > + match m; > + char name[GFC_MAX_SYMBOL_LEN]; > + gfc_symbol *sym, *sym2; > + gfc

[Patch, fortran] Implementation of F2018 SELECT RANK

2019-08-31 Thread Paul Richard Thomas
When I started on this about three months ago, I thought that with SELECT TYPE as a template this was going to be low hanging fruit. Not so :-) Among the issues on the way were: class selectors; unlimited polymorphic selectors even more so; and error recovery. It's a good starting point but I am n