On Sep 5, 2013, at 2:00 PM, Richard Sandiford
wrote:
> Ping. I should have said that bootstrapping with rtl checking enabled
> is broken as things stand.
Yes, this is fine.
> Richard Sandiford writes:
>> Mike Stump writes:
>>> @@ -643,12 +653,14 @@ equality. */
>>>
Ping. I should have said that bootstrapping with rtl checking enabled
is broken as things stand.
Thanks,
Richard
Richard Sandiford writes:
> Mike Stump writes:
>> @@ -643,12 +653,14 @@ equality. */
>> __FUNCTION__); \
>> &_rtx->u.hwi
Mike Stump writes:
> @@ -643,12 +653,14 @@ equality. */
> __FUNCTION__); \
> &_rtx->u.hwint[_n]; }))
>
> -#define XHWIVEC_ELT(HWIVEC, I) __extension__ \
> -(*({ __typeof (HWIVEC) const _hwivec = (HWIVEC); const
On Thu, 29 Aug 2013, Mike Stump wrote:
> On Aug 29, 2013, at 12:36 AM, Richard Biener wrote:
> > On Wed, 28 Aug 2013, Mike Stump wrote:
> >
> >> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
> >>> Btw, rtl.h still wastes space with
> >>>
> >>> struct GTY((variable_size)) hwivec_def {
> >>
On Aug 29, 2013, at 12:36 AM, Richard Biener wrote:
> On Wed, 28 Aug 2013, Mike Stump wrote:
>
>> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
>>> Btw, rtl.h still wastes space with
>>>
>>> struct GTY((variable_size)) hwivec_def {
>>> int num_elem; /* number of elements */
>>> HOS
On 08/28/2013 05:08 AM, Richard Biener wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was n
On 08/29/2013 04:42 AM, Richard Biener wrote:
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have rand
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
>
> > > >Note that the bits above the precision are not defined and the
> > > >algorithms used here are careful not to depend on their value. In
> > > >particular, values that come in from rtx constants may have random
> > > >bits.
> > W
On Wed, 28 Aug 2013, Mike Stump wrote:
> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
> > Btw, rtl.h still wastes space with
> >
> > struct GTY((variable_size)) hwivec_def {
> > int num_elem; /* number of elements */
> > HOST_WIDE_INT elem[1];
> > };
> >
> > struct GTY((chain_ne
On Aug 28, 2013, at 1:41 PM, Kenneth Zadeck wrote:
> On 08/28/2013 12:45 PM, Mike Stump wrote:
>>
>> tree t;
>> wide_int w = t;
>>
>> wide_int_to_tree needs an additional type, so, the spelling is not as short
>> out of necessity.
> i made wide_int_to_tree a function that lives in tree.[ch], n
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentenc
On 08/28/2013 12:45 PM, Mike Stump wrote:
On Aug 28, 2013, at 5:48 AM, Richard Biener wrote:
Only if the precision is > HOST_BITS_PER_WIDE_INT. If the precision
is HOST_BITS_PER_WIDE_INT then both are { -1U }.
That wasn't my understanding on how things work.
You are thinking about prec==0 nu
On Aug 28, 2013, at 5:48 AM, Richard Biener wrote:
>> Only if the precision is > HOST_BITS_PER_WIDE_INT. If the precision
>> is HOST_BITS_PER_WIDE_INT then both are { -1U }.
>
> That wasn't my understanding on how things work.
You are thinking about prec==0 numbers. These are useful and import
On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
> Btw, rtl.h still wastes space with
>
> struct GTY((variable_size)) hwivec_def {
> int num_elem; /* number of elements */
> HOST_WIDE_INT elem[1];
> };
>
> struct GTY((chain_next ("RTX_NEXT (&%h)"),
>chain_prev ("RTX_PREV
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentenc
On Wed, 28 Aug 2013, Richard Sandiford wrote:
> Richard Biener writes:
>
> > On Wed, 28 Aug 2013, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> >> So the precision variable is good for the rtl level in several ways:
> >> >>
> >> >> - As you say, it avoids adding the explicit tr
Richard Biener writes:
> On Wed, 28 Aug 2013, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> >> So the precision variable is good for the rtl level in several ways:
>> >>
>> >> - As you say, it avoids adding the explicit truncations that (in practice)
>> >> every rtl operation would
On Wed, 28 Aug 2013, Richard Sandiford wrote:
> Richard Biener writes:
> >> So the precision variable is good for the rtl level in several ways:
> >>
> >> - As you say, it avoids adding the explicit truncations that (in practice)
> >> every rtl operation would need
> >>
> >> - It's more effic
Richard Biener writes:
>> So the precision variable is good for the rtl level in several ways:
>>
>> - As you say, it avoids adding the explicit truncations that (in practice)
>> every rtl operation would need
>>
>> - It's more efficient in that case, since we don't calculate high values
>>
On Wed, 28 Aug 2013, Richard Sandiford wrote:
> Richard Biener writes:
> >> * As above, constants coming from rtl are already in the right form,
> >> so if you create a wide_int from an rtx and only query it, no explicit
> >> extension is needed.
> >>
> >> * Things like logical operations an
Richard Biener writes:
>> * As above, constants coming from rtl are already in the right form,
>> so if you create a wide_int from an rtx and only query it, no explicit
>> extension is needed.
>>
>> * Things like logical operations and right shifts naturally preserve
>> the sign-extended fo
On Sun, 25 Aug 2013, Mike Stump wrote:
> On Aug 25, 2013, at 12:26 AM, Richard Sandiford
> wrote:
> > (2) Adding a new namespace, wi, for the operators. So far this
> >just contains the previously-static comparison functions
> >and whatever else was needed to avoid cross-dependencies
>
On Fri, 23 Aug 2013, Richard Sandiford wrote:
> Hi Kenny,
>
> This is the first time I've looked at the implementation of wide-int.h
> (rather than just looking at the rtl changes, which as you know I like
> in general), so FWIW here are some comments on wide-int.h. I expect
> a lot of them over
On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
> (2) Adding a new namespace, wi, for the operators. So far this
>just contains the previously-static comparison functions
>and whatever else was needed to avoid cross-dependencies
>between wi and wide_int_ro (except for the debu
On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers" wrote:
> On Sun, 25 Aug 2013, Mike Stump wrote:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependen
On Sun, 25 Aug 2013, Mike Stump wrote:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
> > We really need to get rid of the #include "tm.h" in wide-int.h.
> > MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> > thing in there. If that comes from tm.h then perhap
On Aug 25, 2013, at 11:29 AM, Richard Sandiford
wrote:
> Looks like wide-int is just using BITS_PER_UNIT to get the number of
> bits in "char". That's a host thing, so it should be CHAR_BIT instead.
Oh, Kenny did point out one sin:
diff --git a/gcc/wide-int.cc b/gcc/wide-int.cc
index 37ce5b3..
On Aug 25, 2013, at 11:29 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>>> thing in the
Mike Stump writes:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
>> We really need to get rid of the #include "tm.h" in wide-int.h.
>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>> thing in there. If that comes from tm.h then perhaps we should put it
>> in
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
> We really need to get rid of the #include "tm.h" in wide-int.h.
> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> thing in there. If that comes from tm.h then perhaps we should put it
> into a new header file instea
On 08/25/2013 02:42 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
us
Kenneth Zadeck writes:
> On 08/24/2013 08:05 AM, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> I wonder how easy it would be to restrict this use of "zero precision"
>>> (i.e. flexible precision) to those where primitive types like "int" are
>>> used as template arguments to operators
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts natur
fixed with the enclosed patch.
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
/* Return true if THIS is negative based on the interpretation of SGN.
For UNSIGNED, this is always false. This is correct even if
precision is 0. */
inline bool
wide_int::neg_p (signop sgn) const
It seems
On 08/24/2013 02:16 PM, Florian Weimer wrote:
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
In particular, the integration with trees is ve
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
used as template arguments to operators, and require a precision when
constru
Richard Sandiford writes:
> I wonder how easy it would be to restrict this use of "zero precision"
> (i.e. flexible precision) to those where primitive types like "int" are
> used as template arguments to operators, and require a precision when
> constructing a wide_int. I wouldn't have expected
Kenneth Zadeck writes:
>>> * Code that does widening conversions. The canonical way that
>>>this is performed is to sign or zero extend the input value to
>>>the max width based on the sign of the type of the source and
>>>then to truncate that value to the target typ
Mike Stump writes:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
>>> * When a constant that has an integer type is converted to a
>>>wide-int it comes in with precision 0. For these constants the
>>>top bit does accurately reflect the sign of that constant; this
>>>is an
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> * When a constant that has an integer type is converted to a
>>wide-int it comes in with precision 0. For these constants the
>>top bit does accurately reflect the sign of that constant; this
>>is an exception to the normal ru
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> #define addr_max_bitsize (64)
>> #define addr_max_precision \
>
> These should either be lower-case C++ constants or upper-case macros.
Fixed:
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index 9ccdf7c..b40962c 100644
--- a/gcc/wide-int.
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::operator - () const
>> {
>> wide_int_ro r;
>> r = wide_int_ro (0) - *this;
>> return r;
>> }
>>
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::neg () const
>> {
>>
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with Richard B.'s comments.
I also expect many of them
Thanks for doing this. I haven't had chance to look at the branch yet
(hope to soon), but the results on mips64-linux-gnu look pretty good:
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02033.html
The only failures that stand out as being possibly wide-int-related are:
FAIL: gcc.dg/fixed
Richi and everyone else who may be interested,
Congrats on your first child. They are a lot of fun, but are very
high maintenence.
Today we put up the wide-int branch for all to see and play with. See
svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int
At this point, we have completed testing it
48 matches
Mail list logo
