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 05:52:00 -0000 [thread overview]
Message-ID: <b2d2a36a-00a8-aaa9-b0d7-3b7e6fa8dd39@gmail.com> (raw)
In-Reply-To: <877evi3oeh.fsf@linaro.org>
On 10/25/2017 03:31 PM, Richard Sandiford wrote:
> Martin Sebor <msebor@gmail.com> 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 below. Am I correct in assuming that
>> the combination is a holdover from the days when GCC was compiled
>> using a C compiler, and that the way to write the same definition
>> in C++ 98 is simply:
>>
>> inline poly_int64
>> tree_to_poly_int64 (const_tree t)
>>
>>> +{
>>> + gcc_assert (tree_fits_poly_int64_p (t));
>>> + return TREE_INT_CST_LOW (t);
>>> +}
>>
>> If yes, I would suggest to use the C++ form (and at some point,
>> changing the existing uses of the GCC/C idiom to the C++ form
>> as well).
>>
>> Otherwise, if something requires the use of the C form I would
>> suggest to add a brief comment explaining it.
>
> You probably saw that this is based on tree_to_[su]hwi. AIUI the
> differences from plain C++ inline are that:
>
> a) with __gnu_inline__, an out-of-line definition must still exist.
> That fits this use case well, because the inline is conditional on
> the #ifdef and tree.c has an out-of-line definition either way.
> If we used normal inline, we'd need to add extra #ifs to tree.c
> as well, to avoid multiple definitions.
>
> b) __gnu_inline__ has the strength of __always_inline__, but without the
> correctness implications if inlining is impossible for any reason.
> I did try normal inline first, but it wasn't strong enough. The
> compiler ended up measurably faster if I copied the tree_to_[su]hwi
> approach.
Thanks for the clarification. I'm not sure I fully understand
it but I'm happy to take your word for it that's necessary. I
would just recommend adding a brief comment to this effect since
it isn't obvious.
>>> +
>>> +inline bool
>>> +poly_int_tree_p (const_tree t, poly_int64_pod *value)
>>> +{
>> ...
>
> [This one is unconditionally inline.]
>
>>> /* 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 () { }
};
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).
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.)
> 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. :-)
Efficiency is certainly important, but it doesn't have to come
at the expense of usability or correctness. I think it's possible
(and important) to design interfaces that are usable safely and
intuitively, and difficult to misuse, while also accommodating
advanced efficient use cases.
> 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).
>>> template <int N>
>>> class extended_tree
>>> {
>>> @@ -5139,11 +5225,13 @@ extern bool anon_aggrname_p (const_tree)
>>> const_tree m_t;
>>>
>>> public:
>>> + extended_tree () {}
>>> extended_tree (const_tree);
>> ...
>>> Index: gcc/tree.c
>>> ===================================================================
>> ...
>>> +
>>> +/* 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 is
>>> + somewhat arbitrary, since if B lives near the end of a 64-bit address
>>> + range and A lives near the beginning, B - A is a large positive value
>>> + outside the range of int64_t. A - B is likewise a large negative value
>>> + outside the range of int64_t. All the pointer difference really
>>> + gives is a raw pointer-sized bitstring that can be added to the first
>>> + pointer value to get the second. */
>>
>> I'm not sure I understand the comment about the sign correctly, but
>> if I do, I don't think it's correct.
>>
>> Because their difference wouldn't representable in any basic integer
>> type (i.,e., in ptrdiff_t) the pointers described above could never
>> point to the same object (or array), and so their difference is not
>> meaningful. C/C++ only define the semantics of a difference between
>> pointers to the same object. That restricts the size of the largest
>> possible object typically to SIZE_MAX / 2, or at most SIZE_MAX on
>> the handful of targets where ptrdiff_t has greater precision than
>> size_t. But even on those targets, the difference between any two
>> pointers to the same object must be representable in ptrdiff_t,
>> including the sign.
>
> But does that apply even when no pointer difference of that size
> occurs in the original source? I.e., is:
>
> char *x = malloc (0x80000001)
>
> undefined in itself on 32-bit targets?
No, the call itself isn't undefined, but it shouldn't succeed
on a conforming implementation where ptrdiff_t is a 32-bit type
(which is why GCC diagnoses it). If the call were to succeed
then pointers to the allocated object would fail to meet the
C requirements on additive operators.
> Does it become undefined after:
>
> for (unsigned int i = 0; i < 0x80000001; ++i)
> x[i++] = 0;
>
> where no large pointer difference is calculated? But I realise
> gcc's support for this kind of thing is limited, and that we do
> try to emit a diagnostic for obvious instances...
Yes, this is undefined, both in C (unless ptrdiff_t is wider
than 32 bits) and in GCC, because x[0x80000000] doesn't refer
to the 2147483648-th element of x.
> In the (two) places that need this -- both conversions from
> cst_and_fits_in_hwi -- the immediate problem is that the sign
> of the type doesn't necessarily match the logical sign of the
> difference. E.g. a negative offset can be represented as a large
> unsigned value of sizetype.
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.
Martin
next prev parent reply other threads:[~2017-10-26 3:30 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 ` [003/nnn] poly_int: MACRO_MODE Richard Sandiford
2017-11-17 3:36 ` 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: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 [this message]
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
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 ` [011/nnn] poly_int: DWARF locations Richard Sandiford
2017-11-17 17: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 ` [013/nnn] poly_int: same_addr_size_stores_p Richard Sandiford
2017-11-17 4:11 ` 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: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:07 ` [016/nnn] poly_int: dse.c Richard Sandiford
2017-11-18 4:30 ` 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: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:08 ` [018/nnn] poly_int: MEM_OFFSET and MEM_SIZE Richard Sandiford
2017-12-06 18:27 ` 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 ` [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:10 ` [025/nnn] poly_int: SUBREG_BYTE Richard Sandiford
2017-12-06 18:50 ` 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: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 ` [033/nnn] poly_int: pointer_may_wrap_p Richard Sandiford
2017-11-28 17:44 ` 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:14 ` [035/nnn] poly_int: expand_debug_expr Richard Sandiford
2017-12-05 17:08 ` 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: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 ` [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 ` [042/nnn] poly_int: reload1.c Richard Sandiford
2017-12-05 17:23 ` 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 ` [044/nnn] poly_int: push_block/emit_push_insn Richard Sandiford
2017-11-28 22:18 ` 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 ` [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:21 ` [049/nnn] poly_int: emit_inc Richard Sandiford
2017-11-28 17:30 ` 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 ` [053/nnn] poly_int: decode_addr_const Richard Sandiford
2017-11-28 16:53 ` 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 ` [055/nnn] poly_int: find_bswap_or_nop_load Richard Sandiford
2017-11-28 16:52 ` 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:24 ` [058/nnn] poly_int: get_binfo_at_offset Richard Sandiford
2017-11-28 16:50 ` 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 ` [057/nnn] poly_int: build_ref_for_offset Richard Sandiford
2017-11-28 16:51 ` 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:25 ` [060/nnn] poly_int: loop versioning threshold Richard Sandiford
2017-12-05 17:31 ` 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 ` [065/nnn] poly_int: vect_nunits_for_cost Richard Sandiford
2017-12-05 17:35 ` 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 ` [066/nnn] poly_int: omp_max_vf Richard Sandiford
2017-12-05 17:40 ` 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: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: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:29 ` [069/nnn] poly_int: vector_alignment_reachable_p Richard Sandiford
2017-11-28 16:48 ` 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: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: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: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: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:32 ` [079/nnn] poly_int: vect_no_alias_p Richard Sandiford
2017-12-05 17:46 ` 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 ` [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:37 ` [091/nnn] poly_int: emit_single_push_insn_1 Richard Sandiford
2017-11-28 8:33 ` 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 ` [095/nnn] poly_int: process_alt_operands Richard Sandiford
2017-11-28 8:14 ` 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: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 ` [100/nnn] poly_int: memrefs_conflict_p Richard Sandiford
2017-12-05 23:29 ` 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: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:42 ` [102/nnn] poly_int: vect_permute_load/store_chain Richard Sandiford
2017-11-21 8:01 ` 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 ` [105/nnn] poly_int: expand_assignment Richard Sandiford
2017-11-21 7:50 ` 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: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=b2d2a36a-00a8-aaa9-b0d7-3b7e6fa8dd39@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).