On Mar 26, 2012, at 4:57 PM, Mike Stump wrote:
> On Mar 26, 2012, at 1:03 PM, Richard Sandiford wrote:
>> I think:
>>
>> ...copies of the top bit. Note however that values are neither inherently
>> signed nor inherently unsigned; where necessary, signedness is determined
>> by the rtl operation i
On Mar 26, 2012, at 1:03 PM, Richard Sandiford wrote:
> I think:
>
> ...copies of the top bit. Note however that values are neither inherently
> signed nor inherently unsigned; where necessary, signedness is determined
> by the rtl operation instead.
Sounds good to me, changed.
> Same idea here
Mike Stump writes:
> On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:
>> ...it doesn't mean that we interpret the value as a negative _rtx_.
>> As with all rtx calculations, things like signedness and saturation are
>> decided by the operation rather than the "type" ("type" == rtx mode).
>
>
On Mar 23, 2012, at 3:01 AM, Richard Sandiford wrote:
> ...it doesn't mean that we interpret the value as a negative _rtx_.
> As with all rtx calculations, things like signedness and saturation are
> decided by the operation rather than the "type" ("type" == rtx mode).
Ah... [ light goes on ] Le
Mike Stump writes:
>> Sorry, with this bit, I meant that the current svn code is correct
>> for GET_MODE_BITSIZE (op_mode) == HOST_BITS_PER_WIDE_INT * 2.
>> In that case, hv < 0 can just mean that we have a uint128_t
>> (or whatever) whose high bit happens to be set.
(To be clear, I was using uin
On Mar 22, 2012, at 3:16 AM, Richard Sandiford wrote:
> Sorry, meant we should leave the svn version as it is.
Ah, I see now, I agree, I removed that bit (extend in the floating point case)
of my change from the patch.
> I think this should be s/is smaller than/is different from/.
Sounds good,
On Mar 22, 2012, at 7:12 AM, Michael Matz wrote:
> I see that you didn't remove the assert as part of this patch.
I'll include that in my next patch.
> I'd like to see what you like to do to this routine once the rest goes in.
> In
> particular I don't think just removing the assert will be e
On Mar 22, 2012, at 6:15 AM, Michael Matz wrote:
> That certainly is strictly better than any of the other possibilities, I
> just didn't get the impression from your second mail to this thread that
> you were even considering doing that. Good I was wrong.
All I wanted, was to remove the assert
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -531,10 +531,9 @@ immed_double_const (HOST_WIDE_INT i0, HOST_WIDE_INT i1,
> enum machine_mode mode)
>
> 1) If GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT, then we use
> gen_int_mode.
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
> > If the high bit of i1 is set then currently you will get a negative
> > number produced no matter the absolute value of it.
>
> Ok, in the new patch, I'm pushing to change the spec so that the value
> is sign extended and fixing all the code that
Richard Sandiford writes:
> Should be:
>
> if (add_double_with_sign (l1, h1, l2, h2, &lv, &hv, false))
> /* Sorry, we have no way to represent overflows this
>wide. To fix, add constant support wider than
>CONST_DOUBLE. */
> gcc_assert (GET_MODE_BITS
Mike Stump writes:
>> This is changing the real case, where sign extension doesn't make
>> much sense.
>
> I'm not sure I followed. Do you want me to remove the change for the
> second case, leave it as it, or something else? I've left it as I had
> modified it.
Sorry, meant we should leave the
On Mar 21, 2012, at 6:17 AM, Richard Sandiford wrote:
> Sounds good.
Cool, a path forward.
> For this I think we should make plus_constant a wrapper:
Ah, yes, much better, thanks. I'd expanded the comments on plus_constant_mode
so that one might have a better idea why the code is that way and
On Mar 21, 2012, at 6:47 AM, Michael Matz wrote:
> Actually, I wouldn't.
Ok, thanks for explaining. In light of that, I'd just say, I want to change
the spec, the details don't change any for me, only the terminology I might
use. The problem is the spec is causing aborts on valid code, and hen
Hi,
On Tue, 20 Mar 2012, Mike Stump wrote:
> > Actually you did. I've tried yesterday to come up with a text that
> > would do the same (because I agree with you that deleting the assert
> > changes the spec of the function,
>
> The spec of the function is the text above the definition of the
Mike Stump writes:
> diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
> index de45a22..0c6dc45 100644
> --- a/gcc/doc/rtl.texi
> +++ b/gcc/doc/rtl.texi
> @@ -1530,7 +1530,9 @@ Represents either a floating-point constant of mode
> @var{m} or an
> integer constant too large to fit into @code{HOST_
On Mar 20, 2012, at 5:26 AM, Richard Sandiford wrote:
> So what I was trying to say was that if we remove the assert
> altogether, and allow CONST_DOUBLEs to be wider than 2 HWIs,
> we need to define what the "implicit" high-order HWIs of a
> CONST_DOUBLE are, just like we already do for CONST_INT.
On Mar 20, 2012, at 6:55 AM, Michael Matz wrote:
> Actually you did. I've tried yesterday to come up with a text that would
> do the same (because I agree with you that deleting the assert changes
> the spec of the function,
The spec of the function is the text above the definition of the funct
On Mar 20, 2012, at 5:26 AM, Richard Sandiford wrote:
> So what I was trying to say was that if we remove the assert
> altogether, and allow CONST_DOUBLEs to be wider than 2 HWIs,
> we need to define what the "implicit" high-order HWIs of a
> CONST_DOUBLE are, just like we already do for CONST_INT.
Hi,
On Tue, 20 Mar 2012, Richard Sandiford wrote:
> If Mike or anyone is up to doing that, then great. But if instead it's
> just a case of handling zero correctly, moving rather than removing the
> assert seems safer.
>
> I'm obviously not explaining this well :-)
Actually you did. I've tr
On Tue, Mar 20, 2012 at 1:26 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> I've no objection to moving the assert down to after the GEN_INT.
>>> But it sounds like I'm on my own with the whole CONST_DOUBLE sign thing.
>>> (That is, if we remove the assert altogether, we effectively
Richard Guenther writes:
>> I've no objection to moving the assert down to after the GEN_INT.
>> But it sounds like I'm on my own with the whole CONST_DOUBLE sign thing.
>> (That is, if we remove the assert altogether, we effectively treat the
>> number as sign-extended if it happens to fit in a C
On Tue, Mar 20, 2012 at 11:49 AM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Tue, Mar 20, 2012 at 12:31 AM, Mike Stump wrote:
>>> On Mar 19, 2012, at 2:44 PM, Richard Sandiford wrote:
Mike Stump writes:
>> If we're going to remove the assert, we need to define stuff like
Richard Guenther writes:
> On Tue, Mar 20, 2012 at 12:31 AM, Mike Stump wrote:
>> On Mar 19, 2012, at 2:44 PM, Richard Sandiford wrote:
>>> Mike Stump writes:
> If we're going to remove the assert, we need to define stuff like
> that.
Orthogonal. The rest of the compiler defin
On Tue, Mar 20, 2012 at 12:31 AM, Mike Stump wrote:
> On Mar 19, 2012, at 2:44 PM, Richard Sandiford wrote:
>> Mike Stump writes:
If we're going to remove the assert, we need to define stuff like
that.
>>>
>>> Orthogonal. The rest of the compiler defines what happens, it either
>>> is
On Mar 19, 2012, at 2:44 PM, Richard Sandiford wrote:
> Mike Stump writes:
>>> If we're going to remove the assert, we need to define stuff like
>>> that.
>>
>> Orthogonal. The rest of the compiler defines what happens, it either
>> is inconsistent, in which case it is by fiat, undefined, or it
Mike Stump writes:
>> If we're going to remove the assert, we need to define stuff like
>> that.
>
> Orthogonal. The rest of the compiler defines what happens, it either
> is inconsistent, in which case it is by fiat, undefined, or it is
> consistent, in which case that consistency defines it. T
On Mar 18, 2012, at 3:16 AM, Richard Sandiford wrote:
> Mike Stump writes:
>>> We currently only support constant integer
>>> widths <= 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
>>> triggering if we try to build a wider constant.
>>
>> Can you give me a concrete example of what will f
Mike Stump writes:
>> We currently only support constant integer
>> widths <= 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly
>> triggering if we try to build a wider constant.
>
> Can you give me a concrete example of what will fail with the constant
> 0 generated by:
>
> return GEN_I
On Mar 17, 2012, at 12:37 AM, Richard Sandiford wrote:
> Mike Stump writes:
>> This removes some wrong code.
>>
>> Ok?
>>
>> Index: gcc/emit-rtl.c
>> ===
>> --- gcc/emit-rtl.c (revision 184563)
>> +++ gcc/emit-rtl.c (worki
Mike Stump writes:
> This removes some wrong code.
>
> Ok?
>
> Index: gcc/emit-rtl.c
> ===
> --- gcc/emit-rtl.c (revision 184563)
> +++ gcc/emit-rtl.c (working copy)
> @@ -540,8 +540,6 @@ immed_double_const (HOST_WIDE_INT i0
On Mar 16, 2012, at 3:03 PM, Steven Bosscher wrote:
> On Fri, Mar 16, 2012 at 10:54 PM, Mike Stump wrote:
>> This removes some wrong code.
>>
>> Ok?
>
> ChangeLog is missing.
* emit-rtl.c (immed_double_const): Remove bogus assert.
> Tested how?
Compiles a user program for my port.
>
On Fri, Mar 16, 2012 at 10:54 PM, Mike Stump wrote:
> This removes some wrong code.
>
> Ok?
ChangeLog is missing. Tested how?
And why is this wrong anyway?
Ciao!
Steven
> Index: gcc/emit-rtl.c
> ===
> --- gcc/emit-rtl.c (rev
This removes some wrong code.
Ok?
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 184563)
+++ gcc/emit-rtl.c (working copy)
@@ -540,8 +540,6 @@ immed_double_const (HOST_WIDE_INT i0, HO
if (GET_MODE_BITSIZE (
34 matches
Mail list logo
