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

Re: __intN patch 3/5: main __int128 -> __intN conversion.


> I don't see any corresponding HOST_BITS_PER_WIDE_INT test for __int128 
> being removed (and anyway HOST_BITS_PER_WIDE_INT is now always 64, so such 
> a test for __int128 would be dead code).

It was there when I started the patch, honest!  :-)

Removed ;-)

> > For each __int<N> we need to provide an __INT<N>_MIN__ and
> > __INT<N>_MAX__, just like for "char" we provide __CHAR_MIN__ and
> > __CHAR_MAX__.
> 
> No, those are provided for use by <limits.h>, which only covers standard C 
> types (and in particular does not cover __int128).

Ok, removed.


> Maybe you need to refactor __glibcxx_digits so there is a version
> taking the bitsize as an argument rather than using sizeof(T) *
> __CHAR_BIT__, but that should be the only change needed to handle
> such types with the existing macros.

Since the other macros use this macro, we'd need a complete second set
of macros just for the __intN types anyway, each of which takes a
bitsize and passes it down.  Since gcc already knows all the right
answers for the __intN types and needs to emit other macros for them
anyway, where's the benefit?

Also, consider that the specialization for all the other types is
duplicated in full, I'm already using less source code for my 1..4
types than the library would have used for its 1..4 types ;-)


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