On Sat, Nov 10, 2012 at 3:00 PM, Thomas Koenig wrote: > I wrote: > >> after the dicsussion on c.l.f, it become clear that passing a DO loop >> variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error. >> The attached patch throws an error for both cases.
But should we really isse an error for INTENT(INOUT)? IMHO a warning suffices, with maybe an error only for strict (i.e. non-GNU) standard settings. >> I chose to issue the errors as a front-end pass because we cannot check >> for formal arguments during parsing (where the other checks are >> implemented). >> >> Regression-tested. OK for trunk? > > > Ping ** 1.4285 ? You don't have to list do_list twice in the ChangeLog, you probably wanted one of those to be do_level ;-) >> + do_list = XNEWVEC(gfc_code *, do_size); Taste nit: Why not just toss do_list, do_level, and do_size around as a function argument, instead of making them global variable? Just define a struct containing them and pass it around via the "data" argument for gfc_code_walker should work, I think. IMHO names like "do_warn" and "do_list" are not very descriptive, if not to say confusing. do_* names are used elsewhere in the compiler for functions that perform ("do") a task, whereas your do_* functions are for the Fortran DO construct. I'd prefer different names. >> + to an INTENt(OUT) or INTENT(INOUT) dummy variable. */ s/INTENt/INTENT/ >> + /* Withot a formal arglist, there is only unknown INTENT, s/Withot/Without/ >> + for (i=0; i<do_level; i++) for (i = 0; i < do_level; i++) >> + "inside loop beginning at %L as INTENT(OUT) " Extraneous space after loop. How do you handle OPTIONAL args? Ciao! Steven