Hello, in debugging the remaining Ada failures on s390x, I've come to what looks a bug in the middle end. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19382 for details.
In short, the problem appears to be this code in fold_builtin_memcmp: /* If len parameter is one, return an expression corresponding to (*(const unsigned char*)arg1 - (const unsigned char*)arg2). */ if (host_integerp (len, 1) && tree_low_cst (len, 1) == 1) { tree cst_uchar_node = build_type_variant (unsigned_char_type_node, 1, 0); tree cst_uchar_ptr_node = build_pointer_type (cst_uchar_node); tree ind1 = fold_convert (integer_type_node, build1 (INDIRECT_REF, cst_uchar_node, fold_convert (cst_uchar_ptr_node, arg1))); tree ind2 = fold_convert (integer_type_node, build1 (INDIRECT_REF, cst_uchar_node, fold_convert (cst_uchar_ptr_node, arg2))); return fold_build2 (MINUS_EXPR, integer_type_node, ind1, ind2); } This generates code accessing the data pointed to by the arguments using a synthesized 'const unsigned char' type. This is only OK if that type is allowed to alias whatever type the arguments originally had. Now this is not an issue in the C family of languages, due to the special case of 'char' / 'signed char' / 'unsigned char' being explicitly allowed to alias every other type. However, when building for some *other* language, this assumption is not correct -- e.g. in the Ada test case in PR 19382, the type synthesized here is completely unknown to the front end and gets assigned a default alias set allowing it to alias *nothing* else. (Note that even for Ada, fold_builtin_memcmp *will* be called, e.g. from gimplify.c:gimplify_variable_sized_compare.) Any suggestions how to fix this? Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]