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

[Paul Richard Thomas]

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