This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Confusion in pt.c


Hi Doug, Jason suggested that I write to you about this.  There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values.  The parameters are named "strict" for all functions, but in
some cases they are unification_kind_t and in some cases they are int.

The collision happens in unify_pack_expansion.  unify calls
unify_pack_expansion with a bitmask.  type_unification_real calls
unify_pack_expansion with a unification_kind_t.  Within
unify_pack_expansion, I see this:

        int arg_strict = strict;
        ...
        if (call_args_p)
          {
        ...
            switch (strict)
              {
              case DEDUCE_CALL:
                sub_strict = (UNIFY_ALLOW_OUTER_LEVEL 
                              | UNIFY_ALLOW_MORE_CV_QUAL
                              | UNIFY_ALLOW_DERIVED);
        ...
              }
        ...
            arg_strict = sub_strict;
        ...
          }
        ...
            if (unify (tparms, targs, parm, arg, arg_strict))
              return 1;

In other words, in the switch statement the parameter strict is
treated as a unification_kind_t.  arg_strict is set to either a
unification_kind_t (call_args_p false) or a UNIFY_ALLOW bitmask
(call_args_p true).  Either way, it is passed on to unify.

It's remotely possible that this code is working as intended.  But it
sure looks wrong.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]