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 -
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 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.
>>>
>>> ./
s point to fix all 256-bit bugs in the
compiler. I don't have time to add support for all possible future ports of
gcc. I don't have 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
On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote:
> On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd 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);
>
to give them an A -
submit a patch series that makes 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 w
C types (as defined by the port).
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.
_int24, so I don't know what you mean, and I 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
>> 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
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 ve
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd 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);
> ./ia64/ia64-mod
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);
./ia64/ia64-modes.def:68:INT_MODE (OI, 32);
./i386/i386-modes.def:88:INT_MODE (
.
>
> No. Just you expose the users to those bugs 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;
Thi
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 w
he 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 p
On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump wrote:
> On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
>> On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump wrote:
>>> This patch adds __int256 to the front-ends.
>
>>> We have another patch underway to do N
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
> On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump 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
On Fri, Jul 13, 2012 at 3:59 AM, 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, f
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
18 matches
Mail list logo
