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: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review

On Sat, 9 Jan 2010, Kai Tietz wrote:

> Is this patch to apply to 4.6 as soon as 4.6 will be in stage 1?

No.  You need to give a proper explanation of the rationale and design.  
The key thing to remember is: *in ISO C terms this is not an integer 
type*.  So you need to explain how you ensure that nothing that in ISO C 
requires an integer type ever gets this type (unless the target defines 
intmax_t to be this type or wider) and that attempts to use this type are 
properly diagnosed with -pedantic.  You also need to avoid any hardcoded 
link between this type and TImode; if char (QImode) is wider than 8 bits, 
TImode will be wider than 128 bits, and this type if it exists will have 
another mode.

Combinations such as "__int128 int" should be invalid; "__int128" should 
only be able to appear in combination with at most one of signed and 
unsigned, and optionally _Complex (so six combinations).  Your 
documentation claims "__int128 int" is valid, while your testcase includes 
combinations claiming it is both valid and invalid.  You also need 
*accurate* comments on the testcase, explaining how it was really 
generated; don't copy without thinking.  I attach the script originally 
used to generate the testcase for PR 4319, which you should be able to 
adapt to generate an accurate testcase for this extension.

Note the typo in "@code[__int128}".

The claim in the documentation that "C/C++ supports data types for 
integers that are 128 bits wide" is simply wrong.  Think about what you 
are writing.  You can't just copy documentation for long long.  That talks 
about what ISO C99 supports, but these new types are pure GNU extensions 
and pure GNU extensions need documenting differently from features in one 
ISO C version supported in other modes as extensions.  There is no need 
for the documentation to talk about details of how operations are coded, 
or whether they need library functions (probably a legacy of when there 
was a combined user/porting manual), or about pitfalls without prototypes 
(once relevant when people had much unprototyped code, not relevant now 
ISO C is twenty years old).  The basic principle is that these types are 
pure GNU extensions, they act somewhat like integer types in terms of the 
operations permitted with them, but they are not integer types.

Joseph S. Myers

Attachment: 4319-gen
Description: Text document

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