public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org
Subject: Re: [006/nnn] poly_int: tree constants
Date: Thu, 26 Oct 2017 16:45:00 -0000	[thread overview]
Message-ID: <2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com> (raw)
In-Reply-To: <8737662tlp.fsf@linaro.org>

>>>>>  /* 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):
>>>>
>>>>    unextended_tree (): m_t () {}
>>>>
>>>> Ditto everywhere else, such as in:
>>>
>>> This is really performance-senesitive code though, so I don't think
>>> we want to add any unnecessary initialisation.  Primitive types are
>>> uninitalised by default too, and the point of this class is to
>>> provide an integer-like interface.
>>
>> I understand the performance concern (more on that below), but
>> to clarify the usability issues,  I don't think the analogy with
>> primitive types is quite fitting here: int() evaluates to zero,
>> as do the values of i and a[0] and a[1] after an object of type
>> S is constructed using its default ctor, i.e., S ():
>>
>>    struct S {
>>      int i;
>>      int a[2];
>>
>>      S (): i (), a () { }
>>    };
>
> Sure, I realise that.  I meant that:
>
>   int x;
>
> doesn't initialise x to zero.  So it's a question of which case is the
> most motivating one: using "x ()" to initialise x to 0 in a constructor
> or "int x;" to declare a variable of type x, uninitialised.  I think the
> latter use case is much more common (at least in GCC).  Rearranging
> things, I said later:

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 without initializing them.
It's been established that it's far better to declare variables with
the smallest scope, and to initialize them on declaration.  Compilers
are smart enough these days to eliminate redundant initialization or
assignments.

>>> In your other message you used the example of explicit default
>>> initialisation, such as:
>>>
>>> class foo
>>> {
>>>   foo () : x () {}
>>>   unextended_tree x;
>>> };
>>>
>>> But I think we should strongly discourage that kind of thing.
>>> If someone wants to initialise x to a particular value, like
>>> integer_zero_node, then it would be better to do it explicitly.
>>> If they don't care what the initial value is, then for these
>>> integer-mimicing classes, uninitialised is as good as anything
>>> else. :-)
>
> What I meant was: if you want to initialise "i" to 1 in your example,
> you'd have to write "i (1)".  Being able to write "i ()" instead of
> "i (0)" saves one character but I don't think it adds much clarity.
> Explicitly initialising something only seems worthwhile if you say
> what you're initialising it to.

My comment is not motivated by convenience.  What I'm concerned
about is that defining a default ctor to be a no-op defeats the
zero-initialization semantics most users expect of T().

This is particularly concerning for a class designed to behave
like an [improved] basic integer type.  Such a class should act
as closely as possible to the type it emulates and in the least
surprising ways.  Any sort of a deviation that replaces well-
defined behavior with undefined is a gotcha and a bug waiting
to happen.

It's also a concern in generic (template) contexts where T() is
expected to zero-initialize.  A template designed to work with
a fundamental integer type should also work with a user-defined
type designed to behave like an integer.

>> With the new (and some existing) classes that's not so, and it
>> makes them harder and more error-prone to use (I just recently
>> learned this the hard way about offset_int and the debugging
>> experience is still fresh in my memory).
>
> Sorry about the bad experience.  But that kind of thing cuts
> both ways.  If I write:
>
> poly_int64
> foo (void)
> {
>   poly_int64 x;
>   x += 2;
>   return x;
> }
>
> then I get a warning about x being used uninitialised, without
> having had to run anything.  If we add default initialisation
> then this becomes something that has to be debugged against
> a particular test case, i.e. we've stopped the compiler from
> giving us useful static analysis.

With default initialization the code above becomes valid and has
the expected effect of adding 2 to zero.  It's just more robust
than the same code with that uses a basic type instead.  This
seems no more unexpected and no less desirable than the well-
defined semantics of something like:

   std::string x;
   x += "2";
   return x;

or using any other C++ standard library type in a similar way.

(Incidentally, although I haven't tried with poly_int, I get no
warnings for the code above with offset_int or wide_int.)

>> When the cor is inline and the initialization unnecessary then
>> GCC will in most instances eliminate it, so I also don't think
>> the suggested change would have a significant impact on
>> the efficiency of optimized code, but...
>>
>> ...if it is thought essential to provide a no-op ctor, I would
>> suggest to consider making its property explicit, e.g., like so:
>>
>>    struct unextended_tree {
>>
>>      struct Uninit { };
>>
>>      // ...
>>      unextended_tree (Uninit) { /* no initialization */ }
>>      // ...
>>    };
>>
>> This way the programmer has to explicitly opt in to using the
>> unsafe ctor.  (This ctor is suitable for single objects, not
>> arrays of such things, but presumably that would be sufficient.
>> If not, there are tricks to make that work too.)
>
> The default constructors for unextended_tree and extended_tree
> are only there for the array case (in poly-int.h).

My main concern is with the new poly_int classes (and the existing
wide int classes) because I think those are or will be widely used,
far more so than the unextended_tree class (I confess this review
is the first time I've ever noticed it).

> Part of the problem here is that we still have to live by C++03
> POD rules.  If we moved to C++11, the need for the poly_int_pod/
> poly_int split would go away and things would probably be much
> simpler. :-)

Understood.  With the heavy use of templates, template templates,
and partial specialization, the poly_int classes will push older
C++ 98 compilers to their limits.  It seems that for stability's
sake it would make sense to require a more modern compiler.

>>> Note that for this class NULL_TREE is not a safe default value.
>>> The same goes for the wide-int.h classes, where a length or precision
>>> of 0 is undefined and isn't necessarily going to be handled gracefully
>>> or predictably.
>>
>> For offset_int both precision and length are known so I think
>> it would make sense to have the default ctor value-initialize
>> the object.  For wide_int, it seems to me that choosing some
>> default precision and length in the default ctor would still
>> be preferable to leaving the members indeterminate.  (That
>> functionality could still be provided by some other ctor as
>> I suggested above).
>
> But which precision though?  If we pick a commonly-used one
> then we make a missing initialisation bug very data-dependent.
> Even if we pick a rarely-used one, we create a bug in which
> the wide_int has the wrong precision even though all assignments
> to it "obviously" have the right precision.

For offset_int the default precision is 128-bits.  Making that
the default also for wide_int should be unsurprising.

>> I only meant to suggest that the comment be reworded so as
>> not to imply that such pointers (that are farther apart than
>> PTRDIFF_MAX) can point to the same object and be subtracted.
>
> OK, how about:
>
> /* Return true if T holds a polynomial pointer difference, storing it in
>    *VALUE if so.  A true return means that T's precision is no greater
>    than 64 bits, which is the largest address space we support, so *VALUE
>    never loses precision.  However, the signedness of the result does
>    not necessarily match the signedness of T: sometimes an unsigned type
>    like sizetype is used to encode a value that is actually negative.  */

That looks good to me.

Thanks
Martin

  reply	other threads:[~2017-10-26 16:37 UTC|newest]

Thread overview: 302+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 16:57 [000/nnn] poly_int: representation of runtime offsets and sizes Richard Sandiford
2017-10-23 16:58 ` [001/nnn] poly_int: add poly-int.h Richard Sandiford
2017-10-25 16:17   ` Martin Sebor
2017-11-08  9:44     ` Richard Sandiford
2017-11-08 16:51       ` Martin Sebor
2017-11-08 16:56         ` Richard Sandiford
2017-11-08 17:33           ` Martin Sebor
2017-11-08 17:34           ` Martin Sebor
2017-11-08 18:34             ` Richard Sandiford
2017-11-09  9:10               ` Martin Sebor
2017-11-09 11:14                 ` Richard Sandiford
2017-11-09 17:42                   ` Martin Sebor
2017-11-13 17:59                   ` Jeff Law
2017-11-13 23:57                     ` Richard Sandiford
2017-11-14  1:21                       ` Martin Sebor
2017-11-14  9:46                         ` Richard Sandiford
2017-11-17  3:31                       ` Jeff Law
2017-11-08 10:03   ` Richard Sandiford
2017-11-14  0:42     ` Richard Sandiford
2017-12-06 20:11       ` Jeff Law
2017-12-07 14:46         ` Richard Biener
2017-12-07 15:08           ` Jeff Law
2017-12-07 22:39             ` Richard Sandiford
2017-12-07 22:48               ` Jeff Law
2017-12-15  3:40                 ` Martin Sebor
2017-12-15  9:08                   ` Richard Biener
2017-12-15 15:19                     ` Jeff Law
2017-10-23 16:59 ` [002/nnn] poly_int: IN_TARGET_CODE Richard Sandiford
2017-11-17  3:35   ` Jeff Law
2017-12-15  1:08     ` Richard Sandiford
2017-12-15 15:22       ` Jeff Law
2017-10-23 17:00 ` [004/nnn] poly_int: mode query functions Richard Sandiford
2017-11-17  3:37   ` Jeff Law
2017-10-23 17:00 ` [003/nnn] poly_int: MACRO_MODE Richard Sandiford
2017-11-17  3:36   ` Jeff Law
2017-10-23 17:01 ` [005/nnn] poly_int: rtx constants Richard Sandiford
2017-11-17  4:17   ` Jeff Law
2017-12-15  1:25     ` Richard Sandiford
2017-12-19  4:52       ` Jeff Law
2017-10-23 17:02 ` [006/nnn] poly_int: tree constants Richard Sandiford
2017-10-25 17:14   ` Martin Sebor
2017-10-25 21:35     ` Richard Sandiford
2017-10-26  5:52       ` Martin Sebor
2017-10-26  8:40         ` Richard Sandiford
2017-10-26 16:45           ` Martin Sebor [this message]
2017-10-26 18:05             ` Richard Sandiford
2017-10-26 23:53               ` Martin Sebor
2017-10-27  8:33                 ` Richard Sandiford
2017-10-29 16:56                   ` Martin Sebor
2017-10-30  6:36                     ` Trevor Saunders
2017-10-31 20:25                       ` Martin Sebor
2017-10-26 18:11             ` Pedro Alves
2017-10-26 19:12               ` Martin Sebor
2017-10-26 19:19                 ` Pedro Alves
2017-10-26 23:41                   ` Martin Sebor
2017-10-30 10:26                     ` Pedro Alves
2017-10-31 16:12                       ` Martin Sebor
2017-11-17  4:51   ` Jeff Law
2017-11-18 15:48     ` Richard Sandiford
2017-10-23 17:02 ` [007/nnn] poly_int: dump routines Richard Sandiford
2017-11-17  3:38   ` Jeff Law
2017-10-23 17:03 ` [008/nnn] poly_int: create_integer_operand Richard Sandiford
2017-11-17  3:40   ` Jeff Law
2017-10-23 17:04 ` [009/nnn] poly_int: TRULY_NOOP_TRUNCATION Richard Sandiford
2017-11-17  3:40   ` Jeff Law
2017-10-23 17:04 ` [010/nnn] poly_int: REG_OFFSET Richard Sandiford
2017-11-17  3:41   ` Jeff Law
2017-10-23 17:05 ` [013/nnn] poly_int: same_addr_size_stores_p Richard Sandiford
2017-11-17  4:11   ` Jeff Law
2017-10-23 17:05 ` [012/nnn] poly_int: fold_ctor_reference Richard Sandiford
2017-11-17  3:59   ` Jeff Law
2017-10-23 17:05 ` [011/nnn] poly_int: DWARF locations Richard Sandiford
2017-11-17 17:40   ` Jeff Law
2017-10-23 17:06 ` [014/nnn] poly_int: indirect_refs_may_alias_p Richard Sandiford
2017-11-17 18:11   ` Jeff Law
2017-11-20 13:31     ` Richard Sandiford
2017-11-21  0:49       ` Jeff Law
2017-10-23 17:06 ` [015/nnn] poly_int: ao_ref and vn_reference_op_t Richard Sandiford
2017-11-18  4:25   ` Jeff Law
2017-10-23 17:07 ` [017/nnn] poly_int: rtx_addr_can_trap_p_1 Richard Sandiford
2017-11-18  4:46   ` Jeff Law
2017-10-23 17:07 ` [016/nnn] poly_int: dse.c Richard Sandiford
2017-11-18  4:30   ` Jeff Law
2017-10-23 17:08 ` [018/nnn] poly_int: MEM_OFFSET and MEM_SIZE Richard Sandiford
2017-12-06 18:27   ` Jeff Law
2017-10-23 17:08 ` [020/nnn] poly_int: store_bit_field bitrange Richard Sandiford
2017-12-05 23:43   ` Jeff Law
2017-10-23 17:08 ` [019/nnn] poly_int: lra frame offsets Richard Sandiford
2017-12-06  0:16   ` Jeff Law
2017-10-23 17:09 ` [023/nnn] poly_int: store_field & co Richard Sandiford
2017-12-05 23:49   ` Jeff Law
2017-10-23 17:09 ` [021/nnn] poly_int: extract_bit_field bitrange Richard Sandiford
2017-12-05 23:46   ` Jeff Law
2017-10-23 17:09 ` [022/nnn] poly_int: C++ bitfield regions Richard Sandiford
2017-12-05 23:39   ` Jeff Law
2017-10-23 17:10 ` [025/nnn] poly_int: SUBREG_BYTE Richard Sandiford
2017-12-06 18:50   ` Jeff Law
2017-10-23 17:10 ` [024/nnn] poly_int: ira subreg liveness tracking Richard Sandiford
2017-11-28 21:10   ` Jeff Law
2017-12-05 21:54     ` Richard Sandiford
2017-10-23 17:11 ` [026/nnn] poly_int: operand_subword Richard Sandiford
2017-11-28 17:51   ` Jeff Law
2017-10-23 17:11 ` [027/nnn] poly_int: DWARF CFA offsets Richard Sandiford
2017-12-06  0:40   ` Jeff Law
2017-10-23 17:12 ` [030/nnn] poly_int: get_addr_unit_base_and_extent Richard Sandiford
2017-12-06  0:26   ` Jeff Law
2017-10-23 17:12 ` [028/nnn] poly_int: ipa_parm_adjustment Richard Sandiford
2017-11-28 17:47   ` Jeff Law
2017-10-23 17:12 ` [029/nnn] poly_int: get_ref_base_and_extent Richard Sandiford
2017-12-06 20:03   ` Jeff Law
2017-10-23 17:13 ` [031/nnn] poly_int: aff_tree Richard Sandiford
2017-12-06  0:04   ` Jeff Law
2017-10-23 17:13 ` [032/nnn] poly_int: symbolic_number Richard Sandiford
2017-11-28 17:45   ` Jeff Law
2017-10-23 17:13 ` [033/nnn] poly_int: pointer_may_wrap_p Richard Sandiford
2017-11-28 17:44   ` Jeff Law
2017-10-23 17:14 ` [034/nnn] poly_int: get_inner_reference_aff Richard Sandiford
2017-11-28 17:56   ` Jeff Law
2017-10-23 17:14 ` [036/nnn] poly_int: get_object_alignment_2 Richard Sandiford
2017-11-28 17:37   ` Jeff Law
2017-10-23 17:14 ` [035/nnn] poly_int: expand_debug_expr Richard Sandiford
2017-12-05 17:08   ` Jeff Law
2017-10-23 17:16 ` [037/nnn] poly_int: get_bit_range Richard Sandiford
2017-12-05 23:19   ` Jeff Law
2017-10-23 17:17 ` [038/nnn] poly_int: fold_comparison Richard Sandiford
2017-11-28 21:47   ` Jeff Law
2017-10-23 17:17 ` [039/nnn] poly_int: pass_store_merging::execute Richard Sandiford
2017-11-28 18:00   ` Jeff Law
2017-12-20 12:59     ` Richard Sandiford
2017-10-23 17:18 ` [042/nnn] poly_int: reload1.c Richard Sandiford
2017-12-05 17:23   ` Jeff Law
2017-10-23 17:18 ` [040/nnn] poly_int: get_inner_reference & co Richard Sandiford
2017-12-06 17:26   ` Jeff Law
2018-12-21 11:17   ` Thomas Schwinge
2018-12-21 11:40     ` Jakub Jelinek
2018-12-28 14:34       ` Thomas Schwinge
2017-10-23 17:18 ` [041/nnn] poly_int: reload.c Richard Sandiford
2017-12-05 17:10   ` Jeff Law
2017-10-23 17:19 ` [045/nnn] poly_int: REG_ARGS_SIZE Richard Sandiford
2017-12-06  0:10   ` Jeff Law
2017-12-22 21:56   ` Andreas Schwab
2017-12-23  9:36     ` Richard Sandiford
2017-12-24 12:49       ` Andreas Schwab
2017-12-28 20:37         ` RFA: Fix REG_ARGS_SIZE handling when pushing TLS addresses Richard Sandiford
2018-01-02 19:07           ` Jeff Law
2017-10-23 17:19 ` [044/nnn] poly_int: push_block/emit_push_insn Richard Sandiford
2017-11-28 22:18   ` Jeff Law
2017-10-23 17:19 ` [043/nnn] poly_int: frame allocations Richard Sandiford
2017-12-06  3:15   ` Jeff Law
2017-10-23 17:20 ` [047/nnn] poly_int: argument sizes Richard Sandiford
2017-12-06 20:57   ` Jeff Law
2017-12-20 11:37     ` Richard Sandiford
2017-10-23 17:20 ` [046/nnn] poly_int: instantiate_virtual_regs Richard Sandiford
2017-11-28 18:00   ` Jeff Law
2017-10-23 17:21 ` [048/nnn] poly_int: cfgexpand stack variables Richard Sandiford
2017-12-05 23:22   ` Jeff Law
2017-10-23 17:21 ` [049/nnn] poly_int: emit_inc Richard Sandiford
2017-11-28 17:30   ` Jeff Law
2017-10-23 17:21 ` [050/nnn] poly_int: reload<->ira interface Richard Sandiford
2017-11-28 16:55   ` Jeff Law
2017-10-23 17:22 ` [051/nnn] poly_int: emit_group_load/store Richard Sandiford
2017-12-05 23:26   ` Jeff Law
2017-10-23 17:22 ` [053/nnn] poly_int: decode_addr_const Richard Sandiford
2017-11-28 16:53   ` Jeff Law
2017-10-23 17:22 ` [052/nnn] poly_int: bit_field_size/offset Richard Sandiford
2017-12-05 17:25   ` Jeff Law
2017-10-23 17:23 ` [054/nnn] poly_int: adjust_ptr_info_misalignment Richard Sandiford
2017-11-28 16:53   ` Jeff Law
2017-10-23 17:23 ` [055/nnn] poly_int: find_bswap_or_nop_load Richard Sandiford
2017-11-28 16:52   ` Jeff Law
2017-10-23 17:24 ` [057/nnn] poly_int: build_ref_for_offset Richard Sandiford
2017-11-28 16:51   ` Jeff Law
2017-10-23 17:24 ` [056/nnn] poly_int: MEM_REF offsets Richard Sandiford
2017-12-06  0:46   ` Jeff Law
2017-10-23 17:24 ` [058/nnn] poly_int: get_binfo_at_offset Richard Sandiford
2017-11-28 16:50   ` Jeff Law
2017-10-23 17:25 ` [060/nnn] poly_int: loop versioning threshold Richard Sandiford
2017-12-05 17:31   ` Jeff Law
2017-10-23 17:25 ` [059/nnn] poly_int: tree-ssa-loop-ivopts.c:iv_use Richard Sandiford
2017-12-05 17:26   ` Jeff Law
2017-10-23 17:25 ` [061/nnn] poly_int: compute_data_ref_alignment Richard Sandiford
2017-11-28 16:49   ` Jeff Law
2017-10-23 17:26 ` [063/nnn] poly_int: vectoriser vf and uf Richard Sandiford
2017-12-06  2:46   ` Jeff Law
2018-01-03 21:23   ` [PATCH] Fix gcc.dg/vect-opt-info-1.c testcase Jakub Jelinek
2018-01-03 21:30     ` Richard Sandiford
2018-01-04 17:32     ` Jeff Law
2017-10-23 17:26 ` [062/nnn] poly_int: prune_runtime_alias_test_list Richard Sandiford
2017-12-05 17:33   ` Jeff Law
2017-10-23 17:27 ` [066/nnn] poly_int: omp_max_vf Richard Sandiford
2017-12-05 17:40   ` Jeff Law
2017-10-23 17:27 ` [064/nnn] poly_int: SLP max_units Richard Sandiford
2017-12-05 17:41   ` Jeff Law
2017-10-23 17:27 ` [065/nnn] poly_int: vect_nunits_for_cost Richard Sandiford
2017-12-05 17:35   ` Jeff Law
2017-10-23 17:28 ` [068/nnn] poly_int: current_vector_size and TARGET_AUTOVECTORIZE_VECTOR_SIZES Richard Sandiford
2017-12-06  1:52   ` Jeff Law
2017-10-23 17:28 ` [067/nnn] poly_int: get_mask_mode Richard Sandiford
2017-11-28 16:48   ` Jeff Law
2017-10-23 17:29 ` [069/nnn] poly_int: vector_alignment_reachable_p Richard Sandiford
2017-11-28 16:48   ` Jeff Law
2017-10-23 17:29 ` [070/nnn] poly_int: vectorizable_reduction Richard Sandiford
2017-11-22 18:11   ` Richard Sandiford
2017-12-06  0:33     ` Jeff Law
2017-10-23 17:29 ` [071/nnn] poly_int: vectorizable_induction Richard Sandiford
2017-12-05 17:44   ` Jeff Law
2017-10-23 17:30 ` [072/nnn] poly_int: vectorizable_live_operation Richard Sandiford
2017-11-28 16:47   ` Jeff Law
2017-10-23 17:30 ` [074/nnn] poly_int: vectorizable_call Richard Sandiford
2017-11-28 16:46   ` Jeff Law
2017-10-23 17:30 ` [073/nnn] poly_int: vectorizable_load/store Richard Sandiford
2017-12-06  0:51   ` Jeff Law
2017-10-23 17:31 ` [075/nnn] poly_int: vectorizable_simd_clone_call Richard Sandiford
2017-11-28 16:45   ` Jeff Law
2017-10-23 17:31 ` [077/nnn] poly_int: vect_get_constant_vectors Richard Sandiford
2017-11-28 16:43   ` Jeff Law
2017-10-23 17:31 ` [076/nnn] poly_int: vectorizable_conversion Richard Sandiford
2017-11-28 16:44   ` Jeff Law
2017-11-28 18:15     ` Richard Sandiford
2017-12-05 17:49       ` Jeff Law
2017-10-23 17:32 ` [079/nnn] poly_int: vect_no_alias_p Richard Sandiford
2017-12-05 17:46   ` Jeff Law
2017-10-23 17:32 ` [080/nnn] poly_int: tree-vect-generic.c Richard Sandiford
2017-12-05 17:48   ` Jeff Law
2017-10-23 17:32 ` [078/nnn] poly_int: two-operation SLP Richard Sandiford
2017-11-28 16:41   ` Jeff Law
2017-10-23 17:33 ` [082/nnn] poly_int: omp-simd-clone.c Richard Sandiford
2017-11-28 16:36   ` Jeff Law
2017-10-23 17:33 ` [081/nnn] poly_int: brig vector elements Richard Sandiford
2017-10-24  7:10   ` Pekka Jääskeläinen
2017-10-23 17:34 ` [083/nnn] poly_int: fold_indirect_ref_1 Richard Sandiford
2017-11-28 16:34   ` Jeff Law
2017-10-23 17:34 ` [084/nnn] poly_int: folding BIT_FIELD_REFs on vectors Richard Sandiford
2017-11-28 16:33   ` Jeff Law
2017-10-23 17:34 ` [085/nnn] poly_int: expand_vector_ubsan_overflow Richard Sandiford
2017-11-28 16:33   ` Jeff Law
2017-10-23 17:35 ` [087/nnn] poly_int: subreg_get_info Richard Sandiford
2017-11-28 16:29   ` Jeff Law
2017-10-23 17:35 ` [088/nnn] poly_int: expand_expr_real_2 Richard Sandiford
2017-11-28  8:49   ` Jeff Law
2017-10-23 17:35 ` [086/nnn] poly_int: REGMODE_NATURAL_SIZE Richard Sandiford
2017-12-05 23:33   ` Jeff Law
2017-10-23 17:36 ` [089/nnn] poly_int: expand_expr_real_1 Richard Sandiford
2017-11-28  8:41   ` Jeff Law
2017-10-23 17:36 ` [090/nnn] poly_int: set_inc_state Richard Sandiford
2017-11-28  8:35   ` Jeff Law
2017-10-23 17:37 ` [091/nnn] poly_int: emit_single_push_insn_1 Richard Sandiford
2017-11-28  8:33   ` Jeff Law
2017-10-23 17:37 ` [092/nnn] poly_int: PUSH_ROUNDING Richard Sandiford
2017-11-28 16:21   ` Jeff Law
2017-11-28 18:01     ` Richard Sandiford
2017-11-28 18:10       ` PUSH_ROUNDING Jeff Law
2017-10-23 17:37 ` [093/nnn] poly_int: adjust_mems Richard Sandiford
2017-11-28  8:32   ` Jeff Law
2017-10-23 17:38 ` [094/nnn] poly_int: expand_ifn_atomic_compare_exchange_into_call Richard Sandiford
2017-11-28  8:31   ` Jeff Law
2017-10-23 17:39 ` [096/nnn] poly_int: reloading complex subregs Richard Sandiford
2017-11-28  8:09   ` Jeff Law
2017-10-23 17:39 ` [095/nnn] poly_int: process_alt_operands Richard Sandiford
2017-11-28  8:14   ` Jeff Law
2017-10-23 17:40 ` [099/nnn] poly_int: struct_value_size Richard Sandiford
2017-11-21  8:14   ` Jeff Law
2017-10-23 17:40 ` [098/nnn] poly_int: load_register_parameters Richard Sandiford
2017-11-28  8:08   ` Jeff Law
2017-10-23 17:40 ` [097/nnn] poly_int: alter_reg Richard Sandiford
2017-11-28  8:08   ` Jeff Law
2017-10-23 17:41 ` [101/nnn] poly_int: GET_MODE_NUNITS Richard Sandiford
2017-12-06  2:05   ` Jeff Law
2017-10-23 17:41 ` [100/nnn] poly_int: memrefs_conflict_p Richard Sandiford
2017-12-05 23:29   ` Jeff Law
2017-10-23 17:42 ` [102/nnn] poly_int: vect_permute_load/store_chain Richard Sandiford
2017-11-21  8:01   ` Jeff Law
2017-10-23 17:42 ` [103/nnn] poly_int: TYPE_VECTOR_SUBPARTS Richard Sandiford
2017-10-24  9:06   ` Richard Biener
2017-10-24  9:40     ` Richard Sandiford
2017-10-24 10:01       ` Richard Biener
2017-10-24 11:20         ` Richard Sandiford
2017-10-24 11:30           ` Richard Biener
2017-10-24 16:24             ` Richard Sandiford
2017-12-06  2:31   ` Jeff Law
2017-10-23 17:43 ` [106/nnn] poly_int: GET_MODE_BITSIZE Richard Sandiford
2017-11-21  7:49   ` Jeff Law
2017-10-23 17:43 ` [105/nnn] poly_int: expand_assignment Richard Sandiford
2017-11-21  7:50   ` Jeff Law
2017-10-23 17:43 ` [104/nnn] poly_int: GET_MODE_PRECISION Richard Sandiford
2017-11-28  8:07   ` Jeff Law
2017-10-23 17:48 ` [107/nnn] poly_int: GET_MODE_SIZE Richard Sandiford
2017-11-21  7:48   ` Jeff Law
2017-10-24  9:25 ` [000/nnn] poly_int: representation of runtime offsets and sizes Eric Botcazou
2017-10-24  9:58   ` Richard Sandiford
2017-10-24 10:53     ` Eric Botcazou
2017-10-24 11:25       ` Richard Sandiford
2017-10-24 12:24         ` Richard Biener
2017-10-24 13:07           ` Richard Sandiford
2017-10-24 13:18             ` Richard Biener
2017-10-24 13:30               ` Richard Sandiford
2017-10-25 10:27                 ` Richard Biener
2017-10-25 10:45                   ` Jakub Jelinek
2017-10-25 11:39                   ` Richard Sandiford
2017-10-25 13:09                     ` Richard Biener
2017-11-08  9:51                       ` Richard Sandiford
2017-11-08 11:57                         ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).