On 14/07/12 04:21, Mike Stump wrote:
On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote:
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
On Fri, 13 Jul 2012, Mike Stump wrote:
I don't have time to re-implement __int128 support in the compiler for
you.
So, are there any other specific actionable things I can do for you to
make the patch acceptable?
No. The right way to make __int256 support - the feature, not the present
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote:
This patch adds __int256 to the front-ends.
We have another patch underway to do N-bit constant ints, where N is defined
by the port. This patch is in the process
On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump mikest...@comcast.net wrote:
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote:
This patch adds __int256 to the front-ends.
We have another patch underway to do N-bit
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
Mike Stump wrote:
This patch adds __int256 to the front-ends. We follow the __int128 code
fairly closely...
So, an outstanding question would be, how do I get the mangle codes
allocated for the type? I just choose two unused codes, for now. All in
all, the patch was pretty straight
by exposing __int256 ;) Docs
should have a pretty big fat warning on it.
Ah, ok, thanks. Now, the problem, OImode I believe is _already_ exposed to the
user:
int __attribute__((mode(SI))) a;
int __attribute__((mode(OI))) b;
This just changes the exposure slightly to be higher visibility
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE (OI, 32);
./spu/spu-modes.def:29:INT_MODE (OI, 32);
On Fri, 13 Jul 2012, Georg-Johann Lay wrote:
The avr port defines __int24 and __uint24.
Is that compatible with a generic __int24?
In my view, given suitable generic support ports like that should move to
__intN keywords (usable with unsigned, so unsigned __intN would be the
unsigned version
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
don't
know what you mean by compatible. In the language standard, compatible is a
very specific term, and it relates to the front-end code. I'm not altering or
changing any front end semantics for any type, other than __int256, so the
answer post my patch, is the same answer as previous to my
).
Included here are the double-word arithmetic supported by the
code in @file{optabs.c}.
@end deftypefn
I'll wait. You'll notice that my patch uses that answer to determine if
support for __int256 is enabled.
it transparent to the reviewer that any
questions they thought up have already been addressed (because they can
see relevant testcases added to the testsuite, for example).
Hum, how about this, if you fix __int128 to do it the way you want, then
I will fix __int256 to copy the style that is set
On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote:
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE
time to craft abis for all gcc ports. I don't have time to
implement argument passing for all other ports. I don't have time to validate
__int256 for you. I don't have time to re-implement __int128 support in the
compiler for you.
So, are there any other specific actionable things I can do
This patch adds __int256 to the front-ends. We follow the __int128 code fairly
closely...
So, an outstanding question would be, how do I get the mangle codes allocated
for the type? I just choose two unused codes, for now. All in all, the patch
was pretty straight forward.
We have another
16 matches
Mail list logo
