2011/5/13 Kai Tietz <ktiet...@googlemail.com>: > 2011/5/13 Andrew Pinski <pins...@gmail.com>: >> On Fri, May 13, 2011 at 4:31 AM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> >>> case TRUTH_NOT_EXPR: >>> + if (!useless_type_conversion_p (boolean_type_node, rhs1_type) >>> + || !useless_type_conversion_p (boolean_type_node, lhs_type)) >> >> In Fortran (and maybe other langauges) there are booleans with >> different sizes but the same precision. >> Can you explain how you handle those and why this can't just be a >> BOOLEAN_TYPE type? > > Well, the issue is to be found in gimple_boolify. It is necessary that > it is ensured that operands getting boolified on demand. Doing this by > default boolean_type_node is used. > To verify that, patch converts also for wider-mode BOOLEAN-types back > to boolean_type_node type. > Before thi no boolification of operands were done for expressions with > any boolean type. As we want to make sure that operands getting fixed, > too, but gimplifier doesn't know which resulting type it should have, > we truncate it back to 1-bit boolean. > I assume that the underlying issue is here that some places introduce > - via the backdoor - gimple trees, with abitrary boolean-type. IMHO > those places should be fixed and use for this gimplication to make > sure things getting normalized.
I investigate this a bit more in detail and indeed it is the fortran FE which do here enter in trans-*.c files their own gimple code. And this code doesn't run over the gimplify_expr routines and so it gets in conflict with tree-cfg.c checks. There are two ways to go. A) Adjust fortran's trans-* stuff so that it uses for conditionals and logical-expressions boolean_type consequent (as in some place this type is used, but sometimes artifical boolean_types direct). Or B) We relax tree-cfg checks for logical ops to allow also BOOLEAN types with wider size then 1-bit. Regards, Kai
