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 23:53:00 -0000 [thread overview]
Message-ID: <86b2e46b-4cb5-57cb-63db-aacc2cb41c47@gmail.com> (raw)
In-Reply-To: <87tvyl23v7.fsf@linaro.org>
On 10/26/2017 11:52 AM, Richard Sandiford wrote:
> Martin Sebor <msebor@gmail.com> 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-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.
>
> But that kind of situation is one where using "T (0)" over "T ()"
> is useful. It means that template substitution will succeed for
> T that are sufficiently integer-like to have a single well-defined
> zero but not for T that aren't (such as wide_int).
That strikes me as a little too subtle. But it also doesn't
sound like wide_int is as close to an integer as its name
suggests. After all, it doesn't support relational operators
either, or even assignment from other integer types. It's
really a different beast. But that still doesn't in my mind
justify the no-op initialization semantics.
>> 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
> preference to wide_int if the precision is known to be 128 bits
> in advance, and there doesn't seem any reason to prefer the
> precision of offset_int over widest_int, HOST_WIDE_INT or int.
>
> We would end up with:
>
> wide_int
> f (const wide_int &y)
> {
> wide_int x;
> x += y;
> return x;
> }
>
> being valid if y happens to have 128 bits as well, and a runtime error
> otherwise.
Surely that would be far better than the undefined behavior we
have today.
>
> Also, I think it'd be inconsistent to allow the specific case of 0
> to be assigned by default construction, but not also allow:
>
> wide_int x (0);
>
> wide_int x;
> x = 0;
>
> wide_int x;
> x = 1;
>
> etc. And wide_int wasn't intended for that use case.
Then perhaps I don't fully understand wide_int. I would expect
the above assignments to also "just work" and I can't imagine
why we would not want them to. In what way is rejecting
the above helpful when the following is accepted but undefined?
wide_int f ()
{
wide_int x;
x += 0;
return x;
}
Martin
next prev parent reply other threads:[~2017-10-26 23:42 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 ` [007/nnn] poly_int: dump routines Richard Sandiford
2017-11-17 3:38 ` 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
2017-10-26 18:05 ` Richard Sandiford
2017-10-26 23:53 ` Martin Sebor [this message]
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:03 ` [008/nnn] poly_int: create_integer_operand 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:04 ` [009/nnn] poly_int: TRULY_NOOP_TRUNCATION Richard Sandiford
2017-11-17 3:40 ` 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:05 ` [013/nnn] poly_int: same_addr_size_stores_p Richard Sandiford
2017-11-17 4:11 ` 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 ` [019/nnn] poly_int: lra frame offsets Richard Sandiford
2017-12-06 0:16 ` 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:09 ` [022/nnn] poly_int: C++ bitfield regions Richard Sandiford
2017-12-05 23:39 ` 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 ` [023/nnn] poly_int: store_field & co Richard Sandiford
2017-12-05 23:49 ` 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 ` [027/nnn] poly_int: DWARF CFA offsets Richard Sandiford
2017-12-06 0:40 ` Jeff Law
2017-10-23 17:11 ` [026/nnn] poly_int: operand_subword Richard Sandiford
2017-11-28 17:51 ` 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:12 ` [028/nnn] poly_int: ipa_parm_adjustment Richard Sandiford
2017-11-28 17:47 ` 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:13 ` [032/nnn] poly_int: symbolic_number Richard Sandiford
2017-11-28 17:45 ` 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 ` [033/nnn] poly_int: pointer_may_wrap_p Richard Sandiford
2017-11-28 17:44 ` 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 ` [034/nnn] poly_int: get_inner_reference_aff Richard Sandiford
2017-11-28 17:56 ` 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 ` [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:17 ` [038/nnn] poly_int: fold_comparison Richard Sandiford
2017-11-28 21:47 ` Jeff Law
2017-10-23 17:18 ` [041/nnn] poly_int: reload.c Richard Sandiford
2017-12-05 17:10 ` Jeff Law
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: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: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:20 ` [046/nnn] poly_int: instantiate_virtual_regs Richard Sandiford
2017-11-28 18:00 ` 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: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:21 ` [048/nnn] poly_int: cfgexpand stack variables Richard Sandiford
2017-12-05 23:22 ` 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:22 ` [051/nnn] poly_int: emit_group_load/store Richard Sandiford
2017-12-05 23:26 ` 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 ` [061/nnn] poly_int: compute_data_ref_alignment Richard Sandiford
2017-11-28 16:49 ` 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:26 ` [062/nnn] poly_int: prune_runtime_alias_test_list Richard Sandiford
2017-12-05 17:33 ` 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: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:27 ` [066/nnn] poly_int: omp_max_vf Richard Sandiford
2017-12-05 17:40 ` 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 ` [071/nnn] poly_int: vectorizable_induction Richard Sandiford
2017-12-05 17:44 ` 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:30 ` [074/nnn] poly_int: vectorizable_call Richard Sandiford
2017-11-28 16:46 ` 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 ` [073/nnn] poly_int: vectorizable_load/store Richard Sandiford
2017-12-06 0:51 ` 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 ` [075/nnn] poly_int: vectorizable_simd_clone_call Richard Sandiford
2017-11-28 16:45 ` 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 ` [078/nnn] poly_int: two-operation SLP Richard Sandiford
2017-11-28 16:41 ` 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:33 ` [081/nnn] poly_int: brig vector elements Richard Sandiford
2017-10-24 7:10 ` Pekka Jääskeläinen
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:34 ` [085/nnn] poly_int: expand_vector_ubsan_overflow Richard Sandiford
2017-11-28 16:33 ` 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 ` [083/nnn] poly_int: fold_indirect_ref_1 Richard Sandiford
2017-11-28 16:34 ` 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: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:36 ` [090/nnn] poly_int: set_inc_state Richard Sandiford
2017-11-28 8:35 ` 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:37 ` [091/nnn] poly_int: emit_single_push_insn_1 Richard Sandiford
2017-11-28 8:33 ` 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: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: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 ` [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:40 ` [099/nnn] poly_int: struct_value_size Richard Sandiford
2017-11-21 8:14 ` 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 ` [104/nnn] poly_int: GET_MODE_PRECISION Richard Sandiford
2017-11-28 8:07 ` 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: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=86b2e46b-4cb5-57cb-63db-aacc2cb41c47@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).