This is the mail archive of the
mailing list for the GCC project.
Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Fri, 5 Oct 2001 12:02:32 +0100 (BST)
- cc: <gcc at gcc dot gnu dot org>
On Fri, 5 Oct 2001, Jakub Jelinek wrote:
> Maybe both kinds of type comparisons are useful, so perhaps we could have
> __builtin_types_equal_p (x, y) which would return non-zero if
> TYPE_MAIN_VARIANTs are the same and __builtin_modes_equal_p (x, y) which
> would return non-zero if the TYPE_MODEs are the same. I guess the latter
> would be what altivec would like to use (and probably tgmath.h as well).
tgmath.h should use the types, not the modes. If float, double and long
double all have the same representation, calls should still go to the
correct function (even though the functions are probably aliases).
I think the following (which would need to be grammer symbols rather than
simple built-in functions) should suffice:
__builtin_types_compatible_p (T1, T2) - returns 1 if the unqualified
versions of the types T1 and T2 (which are types, not expressions) are
compatible, 0 otherwise, and can be used in integer constant expressions.
__builtin_choose_expr (C, E1, E2) - returns E1 (and has the type of E1) if
C is true, otherwise returns E2 (and has the type of E2). C must be an
integer constant expression.
The first needs to be a grammer symbol because it takes types as
arguments. The second needs to be a grammar symbol because of the
variable return type and to avoid default argument promotions on its
Optionally, __builtin_choose_type could be provided as well as
Joseph S. Myers