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

On Fri, 13 Jul 2012, Mike Stump wrote:

> As I said, in Kenny's next patch, we add support for all constants of 
> any size the port needs.  I don't know if you've ever tried to use the 
> compiler with OImode, but, what I can say is the bugs are not terribly 
> latent at times and they are not hidden very well at all, today.  The 
> goal of course, is to improve that and make it work better.  These 
> issues that I know about existed, prior to my patch, and we are in the 
> process of fixing them.  Some have been fixed, others remain to be 
> fixed.  The issues I'm thinking about exist with or without my patch to 
> the frontend to support __int256.  Merely adding __int256 doesn't make 
> any of the issues I'm aware of appear, and the issues I'm aware of don't 
> appear with sizes less than 256.

I think the patches allowing constants of such a type to work should go in 
first, and the libgcc support, before we consider the support for the type 
from the front ends using keywords as opposed to mode attributes.

You're using OImode in target-independent code.  But I don't see a change 
to machmode.def to add it as a machine-independent mode.  Nor do I think 
it *should* be a machine-independent mode; it's sufficiently specialised 
that it should be possible to do things without it needing to be one.  
See my comments (several messages on 1 July 2011) about 40-bit integer 
support; carefully designed target hooks to specify the keywords / modes 
for target-specific integer types are better than adding more and more 
cases to several difference places in the target-independent compiler.

__int128_t and __uint128_t are legacy built-in typedef names and I don't 
think there should be any analogue for 256-bit integers; just __int256 and 
unsigned __int256.

> I have put the patch through the C test suite, and it doesn't show any 
> failures.

Certainly you should add analogues of 
gcc.dg/torture/fp-int-convert-*timode.c for the new type and verify that 
those tests all work for it.  It would seem advisable to add tests 
covering pure integer operations for the new type (all the C integer 
operations), for both constants and runtime evaluation, as well.

Joseph S. Myers

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