This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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
joseph@codesourcery.com