Re: [patch, fortran] PR20373 - intrinsic symbols can be given the wrong type

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Daniel,

I guess that you need to go through the specific types of a generic intrinsic.
ie;
typedef struct gfc_intrinsic_sym
{
 const char *name, *lib_name;
 gfc_intrinsic_arg *formal;
 gfc_typespec ts;
 int elemental, pure, generic, specific, actual_ok, standard, noreturn;

 gfc_simplify_f simplify;
 gfc_check_f check;
 gfc_resolve_f resolve;
 struct gfc_intrinsic_sym *specific_head, *next;
 gfc_isym_id id;

}
gfc_intrinsic_sym;

Look for 'generic' and then burrow down through from 'specific_head'.

Paul

On 6/19/07, Daniel Franke <franke.daniel@gmail.com> wrote:
> 2007/6/19, Paul Richard Thomas <paul.richard.thomas@gmail.com>:
> > >Some functions whose return type depends on their respective arguments had
> > > not set a type at all, i.e. isym->ts.type == BT_UNKNOWN. The functions in
> > > question are: ALL, ANY, DOT_PRODUCT, AND, OR, XOR, MIN, MAX and SUM
> > >  (but not e.g. PRODUCT).
> >
> > OK
> > >
> > >To unify this, the "most likely" default types were added to these
> > > functions as done for other functions, e.g. PRODUCT. Also, instead
> > > of an unconditional warning for different types, the warning will only
> > > be shown if -Wsurprinsing/-Wall was specified at the command line.
> >
> > I am much happier with this.
>
> Paul,
> thanks for your review :)
>
> In private mail, Janne pointed out that, while better than before,
> gfortran now would whine at valid code as "complex, intrinsic :: sum"
> (default type set to real). That said, I'm not sure how to proceed as
> this patch would replace "no warning" by an overly picky approach. As
> enumerating valid cases is out of question, maybe a warning that the
> given type is ignored would be sufficient (and correct in all cases)?
>
> Regards
>     Daniel


--
I love deadlines. I love the whooshing sound they make as they go by.
--Douglas Adams