This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)
- To: Daniel Jacobowitz <drow at mvista 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: Thu, 4 Oct 2001 14:02:19 +0100 (BST)
- cc: Aldy Hernandez <aldyh at redhat dot com>, Magnus Fromreide <magfr at lysator dot liu dot se>, <gcc at gcc dot gnu dot org>
On Wed, 3 Oct 2001, Daniel Jacobowitz wrote:
> On Wed, Oct 03, 2001 at 11:19:45PM -0400, Aldy Hernandez wrote:
> > thought about it. like it. nice and clean.
> >
> > is everyone ok with this approach? it's pretty. it's got
> > documentation. it's got a test case. :)
>
> ... but it could be prettier... I'd still like to push for a function
> which takes types as arguments. You can use something like:
> __builtin_equal_types (typeof(x), float)
Indeed, I think this is the preferred approach (so as a grammar element
rather than a simple built-in function) - once the notion of equality has
been defined. (Though it should be called __builtin_types_equal_p.)
Since the concept of type compatibility is defined by ISO C, the
appropriate test might be that (after removing toplevel qualifiers)
instead of equality - in which case it should be
__builtin_types_compatible_p.
Does the present patch, which removes conversions, proerly compare a float
cast to double as being a double, and a double cast to float as being a
float?
The present patch needs to document the return type (int?) of the
built-in.
> Also, how does this function deal with qualifiers? Is a const double
> equivalent to a double? How about volatile? Is 'signed int' the same
> as 'int'?
rvalues shouldn't have qualified type - but when used with typeof in
macros, it will need to allow for qualified type, and remove the
qualifiers. signed int should count the same as int here, since the only
difference is when declaring bit-fields.
> From reading the patch, you're comparing modes, not types. That needs
> to be reflected in the documentation, and possibly in the name of the
> function. Saying two types are the 'same' without defining sameness
> isn't going to be enough.
Comparing modes isn't appropriate. This should e.g. distinguish long and
int even on systems where they are the same size.
--
Joseph S. Myers
jsm28@cam.ac.uk