This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)


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
arguments.

Optionally, __builtin_choose_type could be provided as well as
__builtin_choose_expr.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]