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]
