This is the mail archive of the 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]
Other format: [Raw text]

Re: builtins: choose_expr and types_compatible_p

On 7 Dec 2001, Aldy Hernandez wrote:

> + 		  $$ = e1 == e2 ? build_int_2 (1, 0) : build_int_2 (0, 0);

The test should be *compatibility* (comptypes), not comparing the tree
nodes for equality.

I think this is the only code (as opposed to docs and testcases) issue - 
provided that you make clear in the docs that

* this is C-only (otherwise, the code would need to support it for C++ as
well); and

* the unused part of __builtin_choose_expr may still generate errors
(though this should be fixed when the necessary diagnostics support is on
the mainline, and the docs should note that it may change).

> + @deftypefn {Built-in Function} int __builtin_types_compatible_p (@var{type1}, @var{type2})
> + 
> + You can use the builtin function @code{__builtin_types_compatible_p} to

"builtin" is not a word; see codingconventions.html.  You should say
"built-in function" as a noun; or phrases such as "this is built in".

> + This builtin ignores top level qualifiers (e.g., const, static).  For

@code{const}, @code{volatile}.  static isn't a qualifier, it's a storage
class specifier.

> + The type @code{int[]} and @code{int[5]} are compatible.  On the other

All examples in the documentation should be covered in the testcases.  As
is, some of them don't work.

> + An @code{enum} type is not considered to be compatible with another
> + @code{enum} type.  For example, @code{enum @{foo, bar@}} is not similar

This is wrong - they should be compatible (and this should be tested) when
the implementation-defined types the enums are compatible with (  
are the same.

> + to @code{enum @{hot, dog@}}.  However, the type of an @code{enum}
> + element is considered to be of the same type as the type of any another
> + @code{enum} element.  In the above example, @code{hot} has the same type
> + as @code{bar}.  Lastly, @code{enum} elements are considered to have the
> + same type as an @code{int}.  In the above example, @code{foo} has the
> + same type as @code{int}.

Enumeration constants *have* type int (  Can't we assume users
are familiar with the basics of the language?

> + @deftypefn {Built-in Function} int __builtin_choose_expr (@var{const_exp}, @var{exp1}, @var{exp2})

The return type isn't int - it should be written @var{type}.

> + expression that must be able to be determined at runtime, is non zero.


> +       /* The void expression results in a compile-time error                 \
> +          when assigning the result to something.  */                         \
> +       (void)0))
> + @end smallexample

Use @r{} around English text in comments in examples.

> + /* Assertion that the type of a conditional expression between E1 and E2
> +   is T.  Checks the expression both ways round.  */
> + #define ASSERT_COND_TYPE(E1, E2, T)                     \
> +         do {                                            \
> +           typedef T type;                               \
> +           typedef type **typepp;                        \
> +           typedef __typeof(0 ? (E1) : (E2)) ctype;      \
> +           typedef __typeof(0 ? (E2) : (E1)) ctype2;     \
> +           typedef ctype **ctypepp;                      \
> +           typedef ctype2 **ctype2pp;                    \
> +           typepp x = 0;                                 \
> +           ctypepp y = 0;                                \
> +           ctype2pp z = 0;                               \
> +           x = y;                                        \
> +           x = z;                                        \
> +         } while (0)

This isn't what you want here - since you're not checking conditional
expressions, but __builtin_choose_expr - you want to adapt it to test that
with 0 used __builtin_choose_expr has the type of one argument, and with 1
used it has the type of the other argument.

Joseph S. Myers

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