Jeff Law writes:
> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>> This patch adds a tree representation for poly_ints. Unlike the
>> rtx version, the coefficients are INTEGER_CSTs rather than plain
>> integers, so that we can easily access them as poly_widest_ints
>> and poly_offset_ints.
>>
On 10/23/2017 11:00 AM, Richard Sandiford wrote:
> This patch adds a tree representation for poly_ints. Unlike the
> rtx version, the coefficients are INTEGER_CSTs rather than plain
> integers, so that we can easily access them as poly_widest_ints
> and poly_offset_ints.
>
> The patch also adjust
On 10/29/2017 09:14 PM, Trevor Saunders wrote:
On Sun, Oct 29, 2017 at 10:25:38AM -0600, Martin Sebor wrote:
On 10/27/2017 02:08 AM, Richard Sandiford wrote:
Martin Sebor writes:
On 10/26/2017 11:52 AM, Richard Sandiford wrote:
Martin Sebor writes:
For offset_int the default precision is 1
On 10/30/2017 04:19 AM, Pedro Alves wrote:
On 10/27/2017 12:29 AM, Martin Sebor wrote:
IMO, a good rule of thumb to follow in class design is to have
every class with any user-defined ctor either define a default
ctor that puts the object into a determinate state, or make
the default ctor in
On 10/27/2017 12:29 AM, Martin Sebor wrote:
>
> IMO, a good rule of thumb to follow in class design is to have
> every class with any user-defined ctor either define a default
> ctor that puts the object into a determinate state, or make
> the default ctor inaccessible (or deleted in new C++ vers
On Sun, Oct 29, 2017 at 10:25:38AM -0600, Martin Sebor wrote:
> On 10/27/2017 02:08 AM, Richard Sandiford wrote:
> > Martin Sebor writes:
> > > On 10/26/2017 11:52 AM, Richard Sandiford wrote:
> > > > Martin Sebor writes:
> > > > > For offset_int the default precision is 128-bits. Making that
>
On 10/27/2017 02:08 AM, Richard Sandiford wrote:
Martin Sebor writes:
On 10/26/2017 11:52 AM, Richard Sandiford wrote:
Martin Sebor writes:
For offset_int the default precision is 128-bits. Making that
the default also for wide_int should be unsurprising.
I think it'd be surprising. offs
Martin Sebor writes:
> On 10/26/2017 11:52 AM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> For offset_int the default precision is 128-bits. Making that
>>> the default also for wide_int should be unsurprising.
>>
>> I think it'd be surprising. offset_int should always be used in
>> pr
On 10/26/2017 11:52 AM, Richard Sandiford wrote:
Martin Sebor writes:
/* The tree and const_tree overload templates. */
namespace wi
{
+ class unextended_tree
+ {
+ private:
+const_tree m_t;
+
+ public:
+unextended_tree () {}
Defining no-op ctors is quite dangerous and error-
On 10/26/2017 01:17 PM, Pedro Alves wrote:
On 10/26/2017 07:54 PM, Martin Sebor wrote:
(...) in the general case, it is preferable to
declare each variable at the point where its initial value is known
(or can be computed) and initialize it on its declaration.
With that I fully agree, except
On 10/26/2017 07:54 PM, Martin Sebor wrote:
> (...) in the general case, it is preferable to
> declare each variable at the point where its initial value is known
> (or can be computed) and initialize it on its declaration.
With that I fully agree, except it's not always possible or
natural. The
On 10/26/2017 12:05 PM, Pedro Alves wrote:
On 10/26/2017 05:37 PM, Martin Sebor wrote:
I agree that the latter use case is more common in GCC, but I don't
see it as a good thing. GCC was written in C and most code still
uses now outdated C practices such as declaring variables at the top
of a
On 10/26/2017 05:37 PM, Martin Sebor wrote:
> I agree that the latter use case is more common in GCC, but I don't
> see it as a good thing. GCC was written in C and most code still
> uses now outdated C practices such as declaring variables at the top
> of a (often long) function, and usually wit
Martin Sebor writes:
>> /* The tree and const_tree overload templates. */
>> namespace wi
>> {
>> + class unextended_tree
>> + {
>> + private:
>> +const_tree m_t;
>> +
>> + public:
>> +unextended_tree () {}
>
> Defining no-op ctors i
/* The tree and const_tree overload templates. */
namespace wi
{
+ class unextended_tree
+ {
+ private:
+const_tree m_t;
+
+ public:
+unextended_tree () {}
Defining no-op ctors is quite dangerous and error-prone. I suggest
to instead default initialize the member(s):
unexte
Martin Sebor writes:
> On 10/25/2017 03:31 PM, Richard Sandiford wrote:
>> Martin Sebor writes:
>>> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
+#if NUM_POLY_INT_COEFFS == 1
+extern inline __attribute__ ((__gnu_inline__)) poly_int64
+tree_to_poly_int64 (const_tree t)
>>>
>>> I
On 10/25/2017 03:31 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 10/23/2017 11:00 AM, Richard Sandiford wrote:
+#if NUM_POLY_INT_COEFFS == 1
+extern inline __attribute__ ((__gnu_inline__)) poly_int64
+tree_to_poly_int64 (const_tree t)
I'm curious about the extern inline and __gnu_inl
Martin Sebor writes:
> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>> +#if NUM_POLY_INT_COEFFS == 1
>> +extern inline __attribute__ ((__gnu_inline__)) poly_int64
>> +tree_to_poly_int64 (const_tree t)
>
> I'm curious about the extern inline and __gnu_inline__ here and
> not in poly_int_tree_p
On 10/23/2017 11:00 AM, Richard Sandiford wrote:
+#if NUM_POLY_INT_COEFFS == 1
+extern inline __attribute__ ((__gnu_inline__)) poly_int64
+tree_to_poly_int64 (const_tree t)
I'm curious about the extern inline and __gnu_inline__ here and
not in poly_int_tree_p below. Am I correct in assuming th
19 matches
Mail list logo
