Re: [C/gomp PATCH] Convert OMP_CLAUSE_IF_EXPR to boolean_type_node

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 31 Mar 2006, Richard Henderson wrote:
> On Tue, Mar 28, 2006 at 11:18:51PM -0700, Roger Sayle wrote:
> > 	* c-parser.c (c_parser_omp_clause_if): Ensure that the conditional
> > 	OMP_CLAUSE_IF_EXPR of an OMP_CLAUSE_IF has been suitably converted
> > 	to a boolean_type_node.
>
> I see no reason to do this here.  We should, however, use gimple_boolify
> on OMP_CLAUSE_IF instead of just gimplify_expr in gimplify_scan_omp_clauses.

Hi Richard,

Unfortunately, this won't help as its the call to "convert" in
gimple_boolify that causes/exposes/hides the problem.

To reproduce this issue for yourself, replace the call to
convert in gimple_boolify with a call to fold_convert, and the
only regressions in the entire testsuite are libgomp.c/nestedfn-3.c
and libgomp.c/omp-parallel-if.c (both OMP_CLAUSE_IF issues).
The proposed patch resolves both of these failures.

By this point in the middle-end, all implicit int->bool conversions
are (could be) assumed to be truncations with the integer holding a
zero or one value (or more accurately with the result in the least
significant bit).  Normally, for front-ends where this is not the case,
such as the C/C++ family, the function c_common_truthvalue_conversion
is invoked to produce an explicit "i != 0" NE_EXPR during lowering to
GENERIC.

The whole issue is resolved if OMP_CLAUSE_IF can guarantee
that its argument is a boolean_type_node, not just C/C++'s
truthvalue_type_node.  Perhaps once PR middle-end/26237 is
resolved, and the OMP_* tree codes are documented, we could
explicitly mention this as a requirement?  Both the C++ and
Fortran GOMP support already fulfill this useful invariant.

I hope this better explains my motivation, and now helps
you see a good reason to do this here.  I do agree that GCC
should also be calling gimple_boolify instead of gimple_expr
in gimplify_scan_omp_clauses, but that's an unrelated issue.

Roger
--