------- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-10 11:34 ------- The problem here is that some times we use build_pointer_type () and sometimes we use build_pointer_type_for_mode (). If the latter is called with ref-all true (as done from builtins.c for unsigned char) we get inconsistencies dependent on code-ordering on what is TYPE_POINTER_TO for such type. Quoting from build_pointer_type_for_mode:
/* First, if we already have a type for pointers to TO_TYPE and it's the proper mode, use it. */ for (t = TYPE_POINTER_TO (to_type); t; t = TYPE_NEXT_PTR_TO (t)) if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all) return t; t = make_node (POINTER_TYPE); TREE_TYPE (t) = to_type; TYPE_MODE (t) = mode; TYPE_REF_CAN_ALIAS_ALL (t) = can_alias_all; TYPE_NEXT_PTR_TO (t) = TYPE_POINTER_TO (to_type); TYPE_POINTER_TO (to_type) = t; so we queue all pointer-to types here, even the incompatible ones. This leads to the verification failure because we simply chose the first pointer-to type during verification: if (TYPE_POINTER_TO (TREE_TYPE (op)) && !useless_type_conversion_p (type, TYPE_POINTER_TO (TREE_TYPE (op))) ... now, the original problem with the unsigned char speciality was introduced by +2005-10-04 Ulrich Weigand <[EMAIL PROTECTED]> + + PR ada/19382 + * builtins.c (fold_builtin_memcmp): When constructing the pointer + type used to access data in the inlined length == 1 case, use + build_pointer_type_for_mode with CAN_ALIAS_ALL set to true. + (fold_builtin_strcmp, fold_builtin_strncmp): Likewise. A simple work-around would be to queue ref-all pointers after old pointed-to types. Though I think having more than one here is bogus in the end. -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |uweigand at gcc dot gnu dot | |org BugsThisDependsOn| |19382 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33724