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


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