[patch] Minor improvement to typeclass.h

[patch] Minor improvement to typeclass.h

[Jerry Quinn]

2004-06-05  Jerry Quinn  <jlquinn@optonline.net>

	* typeclass.h:  Add license and include guard.

--- typeclass.h.~1.3.~	1998-12-16 15:58:40.000000000 -0500
+++ typeclass.h	2004-05-24 21:31:31.000000000 -0400
@@ -1,3 +1,26 @@
+/* Type class enum
+   Copyright (C) 2004 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 59 Temple Place - Suite 330, Boston, MA
+02111-1307, USA.  */
+
+#ifndef GCC_TYPECLASS_H
+#define GCC_TYPECLASS_H
+
 /* Values returned by __builtin_classify_type.  */
 
 enum type_class
@@ -12,3 +35,5 @@
   array_type_class, string_type_class, set_type_class, file_type_class,
   lang_type_class
 };
+
+#endif /* GCC_TYPECLASS_H */

Re: [patch] Minor improvement to typeclass.h

[Zack Weinberg]

Jerry Quinn <jlquinn@optonline.net> writes:

> 2004-06-05  Jerry Quinn  <jlquinn@optonline.net>
>
> 	* typeclass.h:  Add license and include guard.

I think this file should be under the libgcc exception.

zw

Re: [patch] Minor improvement to typeclass.h

[Jerry Quinn]

Here it is with the libgcc exception.

Zack Weinberg writes:
 > Jerry Quinn <jlquinn@optonline.net> writes:
 > 
 > > 2004-06-05  Jerry Quinn  <jlquinn@optonline.net>
 > >
 > > 	* typeclass.h:  Add license and include guard.
 > 
 > I think this file should be under the libgcc exception.

--- typeclass.h.~1.3.~	1998-12-16 15:58:40.000000000 -0500
+++ typeclass.h	2004-06-05 17:42:01.000000000 -0400
@@ -1,3 +1,33 @@
+/* Type class enum
+   Copyright (C) 2004 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 59 Temple Place - Suite 330, Boston, MA
+02111-1307, USA.  */
+
+/* As a special exception, if you link this library with other files,
+   some of which are compiled with GCC, to produce an executable,
+   this library does not by itself cause the resulting executable
+   to be covered by the GNU General Public License.
+   This exception does not however invalidate any other reasons why
+   the executable file might be covered by the GNU General Public License.  */
+
+#ifndef GCC_TYPECLASS_H
+#define GCC_TYPECLASS_H
+
 /* Values returned by __builtin_classify_type.  */
 
 enum type_class
@@ -12,3 +42,5 @@
   array_type_class, string_type_class, set_type_class, file_type_class,
   lang_type_class
 };
+
+#endif /* GCC_TYPECLASS_H */

Re: [patch] Minor improvement to typeclass.h

[Jeffrey A Law]

On Sat, 2004-06-05 at 14:31, Zack Weinberg wrote:
> Jerry Quinn <jlquinn@optonline.net> writes:
> 
> > 2004-06-05  Jerry Quinn  <jlquinn@optonline.net>
> >
> > 	* typeclass.h:  Add license and include guard.
> 
> I think this file should be under the libgcc exception.
Why?

typeclass.h isn't used inside libgcc at all, nor is it installed
for use by users.  It's usage appears to be strictly within GCC
itself -- which would indicate to me it ought to be straight GPL.

jeff

Re: [patch] Minor improvement to typeclass.h

[Zack Weinberg]

Jeffrey A Law <law@redhat.com> writes:

>> I think this file should be under the libgcc exception.
> Why?
>
> typeclass.h isn't used inside libgcc at all, nor is it installed
> for use by users.  It's usage appears to be strictly within GCC
> itself -- which would indicate to me it ought to be straight GPL.

It defines the return values of __builtin_classify_type.  Assuming
that's an extension we still need (it's not used anywhere in the
current source tree, and the documentation mentions it only in the
junk description of how we used to implement stdarg.h) it might be a
useful header to install, and therefore ought to be under the libgcc
exception, in case we decide to do that in the future.

zw

Re: [patch] Minor improvement to typeclass.h

[Phil Edwards]

On Thu, Jun 10, 2004 at 11:20:42AM -0700, Zack Weinberg wrote:
> Jeffrey A Law <law@redhat.com> writes:
> 
> >> I think this file should be under the libgcc exception.
> > Why?
> >
> > typeclass.h isn't used inside libgcc at all, nor is it installed
> > for use by users.  It's usage appears to be strictly within GCC
> > itself -- which would indicate to me it ought to be straight GPL.
> 
> It defines the return values of __builtin_classify_type.  Assuming
> that's an extension we still need (it's not used anywhere in the
> current source tree, and the documentation mentions it only in the
> junk description of how we used to implement stdarg.h) it might be a
> useful header to install, and therefore ought to be under the libgcc
> exception, in case we decide to do that in the future.

(Haven't been reading this thread, spologies if I'm out of date.)

I tried getting rid of this header when I was doing compile-time type
reflection/introspection on Gaby's now-dead branch.  It turned out that
glibc used it for some twisted purpose, even though gcc doesn't.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: [patch] Minor improvement to typeclass.h

[Zack Weinberg]

Phil Edwards <phil@codesourcery.com> writes:

>> It defines the return values of __builtin_classify_type.  Assuming
>> that's an extension we still need (it's not used anywhere in the
>> current source tree, and the documentation mentions it only in the
>> junk description of how we used to implement stdarg.h) it might be a
>> useful header to install, and therefore ought to be under the libgcc
>> exception, in case we decide to do that in the future.
>
> (Haven't been reading this thread, spologies if I'm out of date.)
>
> I tried getting rid of this header when I was doing compile-time type
> reflection/introspection on Gaby's now-dead branch.  It turned out that
> glibc used it for some twisted purpose, even though gcc doesn't.

Ah.  tgmath.h.  Yeah, that's good enough reason to keep the extension,
although here's a place where a dialogue with glibc people could
probably result in a better implementation.  (Same sort of icky macros
you find in altivec.h.)

zw

Re: [patch] Minor improvement to typeclass.h

[Jeffrey A Law]

On Thu, 2004-06-10 at 12:31, Phil Edwards wrote:
> (Haven't been reading this thread, spologies if I'm out of date.)
> 
> I tried getting rid of this header when I was doing compile-time type
> reflection/introspection on Gaby's now-dead branch.  It turned out that
> glibc used it for some twisted purpose, even though gcc doesn't.
So how did glibc manage to use the header when GCC doesn't actually
install the header?

Regardless, for now, let's go ahead with libgcc exception clause.

Jerry -- consider the version which used the libgcc exception 
approved.


jeff 

Re: [patch] Minor improvement to typeclass.h

[Jakub Jelinek]

On Thu, Jun 10, 2004 at 01:07:38PM -0600, Jeffrey A Law wrote:
> So how did glibc manage to use the header when GCC doesn't actually
> install the header?

glibc tgmath.h has hardcoded knowledge that real_type_class == 8,
i.e. always compares __builtin_classify_type (something) == 8 or != 8.

	Jakub

Re: [patch] Minor improvement to typeclass.h

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Phil Edwards <phil@codesourcery.com> writes:

> On Thu, Jun 10, 2004 at 11:20:42AM -0700, Zack Weinberg wrote:
>> Jeffrey A Law <law@redhat.com> writes:
>> 
>> >> I think this file should be under the libgcc exception.
>> > Why?
>> >
>> > typeclass.h isn't used inside libgcc at all, nor is it installed
>> > for use by users.  It's usage appears to be strictly within GCC
>> > itself -- which would indicate to me it ought to be straight GPL.
>> 
>> It defines the return values of __builtin_classify_type.  Assuming
>> that's an extension we still need (it's not used anywhere in the
>> current source tree, and the documentation mentions it only in the
>> junk description of how we used to implement stdarg.h) it might be a
>> useful header to install, and therefore ought to be under the libgcc
>> exception, in case we decide to do that in the future.
>
> (Haven't been reading this thread, spologies if I'm out of date.)
>
> I tried getting rid of this header when I was doing compile-time type
> reflection/introspection on Gaby's now-dead branch.  It turned out that
> glibc used it for some twisted purpose, even though gcc doesn't.

I just did a grep through the current glibc sources and see no
references to typeclass.h at all.   Especially tgmath.h does not
include it.  It might be that tgmath.h could be written in a better
way with typeclass...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [patch] Minor improvement to typeclass.h

[Joseph S. Myers]

On Thu, 10 Jun 2004, Zack Weinberg wrote:

> Ah.  tgmath.h.  Yeah, that's good enough reason to keep the extension,
> although here's a place where a dialogue with glibc people could
> probably result in a better implementation.  (Same sort of icky macros
> you find in altivec.h.)

Though I helped with the design of the built-ins used to implement
altivec.h, having seen the resulting altivec.h and the problems associated
with it I don't think it's proved to be a good direction to go in.  (Part
of the blame must be laid at the designers of an Altivec specification
that didn't give its extensions as amendments to ISO C fitting cleanly
within the text and spirit of the document.)  I'd still prefer the sort of
overloaded built-ins described in projects/index.html to implement
<tgmath.h> (in particular, to avoid the explosion of nested macro text
expansions, each parameter should appear once only in the macro text).  
OTOH I don't really care for adding new extensions either, though this
sort of extension (rather than the mess we have) is clearly envisaged by
ISO C.

(The __builtin_classify_type uses were in Ulrich's part of

2000-08-01  Ulrich Drepper  <drepper@redhat.com>
            Joseph S. Myers  <jsm28@cam.ac.uk>

        * math/tgmath.h: Make standard compliant.  Don't ask how.

<http://sources.redhat.com/ml/libc-alpha/2000-08/msg00014.html>; I had
expected Ulrich to have better taste for comprehensibility of code than to
consider such obscure code as
<http://sources.redhat.com/ml/libc-alpha/2000-07/msg00288.html> a serious
candidate for inclusion in glibc rather than proof that something *could*
be done with GCC as is but you wouldn't want to use the necessary code.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: [patch] Minor improvement to typeclass.h

[Zack Weinberg]

Andreas Jaeger <aj@suse.de> writes:

>> I tried getting rid of this header when I was doing compile-time type
>> reflection/introspection on Gaby's now-dead branch.  It turned out that
>> glibc used it for some twisted purpose, even though gcc doesn't.
>
> I just did a grep through the current glibc sources and see no
> references to typeclass.h at all.   Especially tgmath.h does not
> include it.  It might be that tgmath.h could be written in a better
> way with typeclass...

I was unclear.  glibc tgmath.h uses __builtin_classify_type.  It
doesn't use typeclass.h (nor could it - gcc doesn't install it);
it has hardwired numeric constants for the builtin's return value.

Y'all might find __builtin_types_compatible_p a useable replacement,
but I can't be sure.  (Take a look at gcc/config/rs6000/altivec.h for
example usage.)

zw

Re: [patch] Minor improvement to typeclass.h

[Zack Weinberg]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> On Thu, 10 Jun 2004, Zack Weinberg wrote:
>
>> Ah.  tgmath.h.  Yeah, that's good enough reason to keep the extension,
>> although here's a place where a dialogue with glibc people could
>> probably result in a better implementation.  (Same sort of icky macros
>> you find in altivec.h.)
>
> Though I helped with the design of the built-ins used to implement
> altivec.h, having seen the resulting altivec.h and the problems associated
> with it I don't think it's proved to be a good direction to go in.

I agree.  That rather cryptic parenthetical was meant to convey
"tgmath.h currently contains the same sort of icky macros you find in
altivec.h", not "tgmath.h should be revamped using the same sort
of icky macros..."

zw