On Aug 16, 2014, at 5:28 PM, Gerald Pfeifer wrote:
> The patch below shaves 404 warnings from stage 1 when bootstrapping
> with clang 3.4.1 (i386-unknown-freebsd10.0).
>
> Regardless of whether we agree with that warning in clang, keeping
> things consistent and not using struct once and class i
Mike Stump wrote:
> On Jun 28, 2014, at 3:31 AM, Ulrich Weigand wrote:
> > Mike Stump wrote:
> >
> >>(rs6000_aggregate_candidate): Use wide-int interfaces.
> > [snip]
> >> - /* Can't handle incomplete types. */
> >> - if (!COMPLETE_TYPE_P (type))
> >> -return -1;
> >> + /* Can't handl
On Jun 28, 2014, at 3:31 AM, Ulrich Weigand wrote:
> Mike Stump wrote:
>
>> (rs6000_aggregate_candidate): Use wide-int interfaces.
> [snip]
>> -/* Can't handle incomplete types. */
>> -if (!COMPLETE_TYPE_P (type))
>> - return -1;
>> +/* Can't handle incomplete types nor siz
Mike Stump wrote:
> (rs6000_aggregate_candidate): Use wide-int interfaces.
[snip]
> - /* Can't handle incomplete types. */
> - if (!COMPLETE_TYPE_P (type))
> - return -1;
> + /* Can't handle incomplete types nor sizes that are not
> +fixed. */
> + if (!COMPLET
> This looks OK to me.
I obviously didn't look carefully enough, there are a few thinkos in the
output_constructor_bitfield hunk:
- if (shift < HOST_BITS_PER_WIDE_INT
- && shift + this_time > HOST_BITS_PER_WIDE_INT)
- {
- this_time = shift + this_time -
Richard Henderson writes:
> On 05/08/2014 01:12 PM, Richard Sandiford wrote:
>> * wide-int.cc: Only include longlong.h if W_TYPE_SIZE==32 or
>> __SIZEOF_INT128__ is defined.
>
> FWIW, this looks pretty good to me.
Thanks, belatedly applied.
Richard
> I don't think that the mechanical change in UI_From_gnu is correct, see the
> comment just above. The annotate_value change is very likely correct, but
> please double check and, upon positive outcome, remove the last sentence of
> the comment just above.
The annotate_value change was wrong, fi
On 05/08/2014 01:12 PM, Richard Sandiford wrote:
> * wide-int.cc: Only include longlong.h if W_TYPE_SIZE==32 or
> __SIZEOF_INT128__ is defined.
FWIW, this looks pretty good to me.
r~
On 08/05/14 19:31, Richard Sandiford wrote:
> "Joseph S. Myers" writes:
>> On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
>>
>>> Ramana Radhakrishnan
>>>
>>>* wide-int.cc (UTItype): Define.
>>>(UDWtype): Define for appropriate W_TYPE_SIZE.
>>
>> This breaks builds for 32-bit h
+#if GCC_VERSION >= 3000 && (W_TYPE_SIZE == 32 || defined (__SIZEOF_INT128__))
W_TYPE_SIZE == 32 is always false and on 32-bit hosts,
__SIZEOF_INT128__ won't be defined.
Right, but we won't try to use TImode if in future we do revert to using
32-bit types for 32-bit hosts.
For now, I've re
"H.J. Lu" writes:
> On Thu, May 8, 2014 at 1:12 PM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote:
On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote:
> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
> wrote:
On Thu, May 8, 2014 at 1:12 PM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote:
>>> On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote:
On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>
"H.J. Lu" writes:
> On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote:
>> On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote:
>>> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
>>> wrote:
>>> > Kenneth Zadeck writes:
>>> >> everyone who has a private port will hate you forever. no
On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote:
> On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote:
>> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
>> wrote:
>> > Kenneth Zadeck writes:
>> >> everyone who has a private port will hate you forever. note that i
>> >> have 2 of
On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote:
> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
> wrote:
> > Kenneth Zadeck writes:
> >> everyone who has a private port will hate you forever. note that i
> >> have 2 of them.
> >
> > Got any other ideas though? I suppose if we're
On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>> everyone who has a private port will hate you forever. note that i
>> have 2 of them.
>
> Got any other ideas though? I suppose if we're prepared to break
> compatibility with whatever the upstream of longlon
Kenneth Zadeck writes:
> everyone who has a private port will hate you forever. note that i
> have 2 of them.
Got any other ideas though? I suppose if we're prepared to break
compatibility with whatever the upstream of longlong.h is, we could
make more use of intN_t and uintN_t.
Having a whi
everyone who has a private port will hate you forever. note that i
have 2 of them.
On 05/08/2014 02:31 PM, Richard Sandiford wrote:
"Joseph S. Myers" writes:
On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
Ramana Radhakrishnan
* wide-int.cc (UTItype): Define.
(UDWtype)
"Joseph S. Myers" writes:
> On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
>
>> Ramana Radhakrishnan
>>
>>* wide-int.cc (UTItype): Define.
>>(UDWtype): Define for appropriate W_TYPE_SIZE.
>
> This breaks builds for 32-bit hosts, where TImode isn't supported. You
> can only
On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
> Ramana Radhakrishnan
>
>* wide-int.cc (UTItype): Define.
>(UDWtype): Define for appropriate W_TYPE_SIZE.
This breaks builds for 32-bit hosts, where TImode isn't supported. You
can only use TImode on the host if it's 64-bit.
Ramana Radhakrishnan writes:
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 354cdb9..8ef9a0f 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-05-08 Ramana Radhakrishnan
> +
> + * wide-int.cc (UTItype): Define.
> + (UDWtype): Define for appropriate W_TYP
On Wed, Dec 4, 2013 at 12:56 PM, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> This patch handles multiplications using a single HWIxHWI->2HWI
>> multiplication
>> on hosts that have one. This removes all uses of the slow (half-HWI) path
>> for insn-recog.ii. The slow path is still u
On Tue, May 6, 2014 at 10:11 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 5, 2014 at 10:58 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 5, 2
Richard Biener writes:
> On Mon, May 5, 2014 at 10:58 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
> wrote:
>> Richard Bien
On Mon, May 5, 2014 at 10:58 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, May 2, 2
Richard Biener writes:
> On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
> wrote:
>> I'd hoped the
On Mon, May 05, 2014 at 07:32:31PM +0200, Richard Biener wrote:
> > void_zero_node is used for ubsan too, and survives into gimple.
> > I did hit this in real tests, it wasn't just theoretical.
>
> Ugh - for what does it use that ... :/
It's used like this:
t = fold_build3 (COND_EXPR, void_type_n
On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
wrote:
> I'd hoped the days of zero-precision INTEGER_CST
Richard Biener writes:
> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>>> wrote:
I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
Richard's patch to remove min amd max
On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>> wrote:
>>> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
>>> Richard's patch to remove min amd max values from zero-width bitfields,
Richard Biener writes:
> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
> wrote:
>> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
>> Richard's patch to remove min amd max values from zero-width bitfields,
>> but a boostrap-ubsan showed otherwise. One source is in:
>>
On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
wrote:
> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
> Richard's patch to remove min amd max values from zero-width bitfields,
> but a boostrap-ubsan showed otherwise. One source is in:
>
> null_pointer_node = build_in
On Fri, May 2, 2014 at 5:20 PM, Richard Sandiford
wrote:
> I locally tried adding an assertion to the wide-int version of set_bit
> to make sure that the bit number was in range. It triggers for this
> code in boehm.c:mark_reference_fields (quoting trunk version):
>
> /* First word in o
Kenneth Zadeck writes:
> Then with a fixed comment, this patch is fine.
OK, here's what I committed.
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 2014-05-03 07:59:36.274750108 +0100
+++ gcc/wide-int.cc 2014-05-04
Then with a fixed comment, this patch is fine.
kenny
On 05/03/2014 02:59 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
The doc at wide-int.h:136 needs work.The doc currently says that the
precision and length are always greater than 0. This is now not
correct. It also says tha
Kenneth Zadeck writes:
> The doc at wide-int.h:136 needs work.The doc currently says that the
> precision and length are always greater than 0. This is now not
> correct. It also says that the bits above the precision are defined
> to be the sign extension if the precision does not co
The doc at wide-int.h:136 needs work.The doc currently says that the
precision and length are always greater than 0. This is now not
correct. It also says that the bits above the precision are defined
to be the sign extension if the precision does not cover that block.
I do not know
Kenneth Zadeck writes:
> These are fine.
Thanks. I'll hold off applying it until the java fix has been reviewed
(which could be after the merge -- no need to hold it up for this IMO).
Richard
>
> On 05/02/2014 03:20 PM, Richard Sandiford wrote:
>> This patch adds some assertions against sext (
this is fine.
On 05/02/2014 03:22 PM, Richard Sandiford wrote:
divmod_internal didn't handle unsigned division in which the inputs
have implicit all-one upper bits. There were two problems:
- wi_unpack should extend implicit 1s to index blocks_needed - 1
(possibly with a zext_hwi on the las
These are fine.
On 05/02/2014 03:20 PM, Richard Sandiford wrote:
This patch adds some assertions against sext (.., 0) and zext (..., 0).
The former is undefined at the sext_hwi level and the latter is disallowed
for consistency with the former.
Also, set_bit (rightly IMO) can't handle bit >= pr
Richard Sandiford writes:
> Just a minor tweak to avoid several calculations when one would do.
> Since we have a function for rounded-up division, we might as well
> use it instead of the (X + Y - 1) / Y idiom.
>
> Tested on x86_64-linux-gnu. OK to install?
I ended up reverting this. I'd assum
On Wed, Apr 30, 2014 at 1:31 PM, Mike Stump wrote:
>
> I am seeing the below on wide-int. The go teststsuite violates one of the
> principals of goo test suite hygiene, the names thought arbitrary, should be
> stable. These names are not stable across differing build locations.
> s,.*/testsu
Mike Stump writes:
> We changed the underlying type a while back, and it matters on 32-bit
> pointer machines that use long long for a HOST_WIDE_INT… Caught by
> fold-checking, thanks fold checking.
>
> This is the tree-vrp problem, I think this was seen on arm as well.
Trivial follow-up to keep
On 04/28/2014 12:25 PM, Mike Stump wrote:
On Apr 28, 2014, at 2:36 AM, Richard Sandiford
wrote:
Ping. FWIW this is the last patch I have lined up before the merge.
I repeated the asm comparison test I did a few months ago on one target
per config/ architecture and there were no unexpected cha
On Apr 28, 2014, at 2:36 AM, Richard Sandiford
wrote:
> Ping. FWIW this is the last patch I have lined up before the merge.
> I repeated the asm comparison test I did a few months ago on one target
> per config/ architecture and there were no unexpected changes.
Nice, thanks.
Ping. FWIW this is the last patch I have lined up before the merge.
I repeated the asm comparison test I did a few months ago on one target
per config/ architecture and there were no unexpected changes.
Richard Sandiford writes:
> At the moment we prohibit "widest_int = wide_int" and "offset_int
Kenneth Zadeck writes:
> I think that this patch is fine as is.but in looking at the
> surrounding code, i saw something that appears to be somewhat troubling.
>
> I am worried about the two asserts. Given that we now require that
> some users write code similar to the code in tree-vrp.c:2
this is fine.
kenny
On 04/25/2014 09:44 AM, Richard Sandiford wrote:
We should write back the sign-extended value.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 20
i am sorry, i missed the fact that the loop counts up but you were
reversing the order in the indexes.
kenny
On 04/26/2014 04:26 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
don't you think that it would be easier to understand the number if you
printed it largest index first, as in th
Kenneth Zadeck writes:
> don't you think that it would be easier to understand the number if you
> printed it largest index first, as in the routines in wide-int-print.cc?
Yeah, that's what the patch does. E.g. (for 32-bit HWI):
[...,0x3,0x8000]
is 7 << 31.
Thanks,
Richard
>
> kenny
>
approved
On 04/25/2014 09:40 AM, Richard Sandiford wrote:
Very minor, but since shifted_mask copes with out-of-range widths,
I think mask should too.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
approved.
On 04/25/2014 09:39 AM, Richard Sandiford wrote:
shifted_mask would mishandle cases where the start bit is in the middle
of a HWI and the end bit is in a different HWI. The "000111000" case
needs to check that the start and end are in the same block.
In the changed lines, "shift" is t
don't you think that it would be easier to understand the number if you
printed it largest index first, as in the routines in wide-int-print.cc?
kenny
On 04/25/2014 09:58 AM, Richard Sandiford wrote:
This patch adds a dump () method so that it's easier to read the
contents of the various wide-i
richard,
I think that this patch is fine as is.but in looking at the
surrounding code, i saw something that appears to be somewhat troubling.
I am worried about the two asserts. Given that we now require that
some users write code similar to the code in tree-vrp.c:2628, it seems
that t
i see nothing in this patch that requires a review.
On 04/25/2014 09:35 AM, Richard Sandiford wrote:
This series of patches is from a read-through of wide-int.h and wide-int.cc.
(The series from earlier in the week was from a diff of preexisting files.)
This first patch fixes some comments, typo
On Thu, Apr 24, 2014 at 11:54 PM, Richard Sandiford
wrote:
> The asm comparison showed a problem with my r204593 change, which dropped
> a "val.mask &" in the second hunk below.
>
> Seeing that the problem was in ccp made me look at the whole file again.
> I noticed that we'd changed the VARYING m
> So, given the last change, the remaining bit is:
>
> Index: gcc/ada/gcc-interface/cuintp.c
> ===
> --- gcc/ada/gcc-interface/cuintp.c(revision 209754)
> +++ gcc/ada/gcc-interface/cuintp.c(working copy)
> @@ -160,7 +160,11 @@
On Thu, Apr 24, 2014 at 9:02 PM, Mike Stump wrote:
> On Nov 25, 2013, at 2:57 AM, Richard Biener
> wrote:
>> On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump wrote:
>>> Richi has asked the we break the wide-int patch so that the individual port
>>> and front end maintainers can review their parts w
On Apr 24, 2014, at 2:45 PM, Richard Sandiford
wrote:
> I committed this patch as obvious to fix the s390 build.
Looks good, thanks.
On Nov 25, 2013, at 2:57 AM, Richard Biener wrote:
> On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patc
On Nov 25, 2013, at 12:46 AM, Eric Botcazou wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patch covers the ada front-end.
>
> I don't think that th
This is fine with me.
kenny
On 04/24/2014 10:34 AM, Richard Sandiford wrote:
For signed min / -1 we set the overflow flag (good) but also returned a
quotient of 0. It should be 0x80...0 instead. Since that's also the
value of the original dividend, we can just copy the representation over.
T
On 04/23/2014 01:45 PM, Mike Stump wrote:
> * gengtype.c: Remove include of double-int.h.
> (do_typedef): Use wide-int interfaces.
> (open_base_files): Add wide-int.h.
> (main): Add offset_int and widest_int typedefs.
> * gengtype-lex.l: Handle "^".
> (CXX_KEYWOR
On Jan 30, 2014, at 2:56 PM, Mike Stump wrote:
> On Jan 1, 2014, at 7:58 PM, Mike Stump wrote:
>> On Nov 23, 2013, at 11:21 AM, Mike Stump wrote:
>>> Richi has asked the we break the wide-int patch so that the individual port
>>> and front end maintainers can review their parts without have to
On Wed, Apr 23, 2014 at 3:29 PM, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> This code was mixing hprec and hprec*2 wide_ints. The simplest fix
>> seemed to be to introduce a function that gives the minimum precision
>> necessary to represent a function, which also means that no temp
Richard Sandiford writes:
> This code was mixing hprec and hprec*2 wide_ints. The simplest fix
> seemed to be to introduce a function that gives the minimum precision
> necessary to represent a function, which also means that no temporary
> wide_ints are needed.
>
> Other places might be able to
On Tue, Apr 22, 2014 at 10:14 PM, Richard Sandiford
wrote:
> Almost obvious, but just in case...
>
> The first mem_loc_descriptor hunk just reflows the text so that the
> line breaks are less awkward.
>
> Tested on x86_64-linux-gnu. OK to install?
Ok.
Thanks,
Richard.
> Thanks,
> Richard
>
>
>
On Tue, Apr 22, 2014 at 10:12 PM, Richard Sandiford
wrote:
> This patch undoes a few assorted differences from trunk.
>
> For fold-const.c the old code was:
>
> /* If INNER is a right shift of a constant and it plus BITNUM does
> not overflow, adjust BITNUM and INNER. */
> if
On Tue, Apr 22, 2014 at 10:04 PM, Richard Sandiford
wrote:
> register_edge_assert_for_2 operates on wide_ints of precision nprec
> so a lot of the extensions are redundant.
>
> Tested on x86_64-linux-gnu. OK to install?
Ok.
Thanks,
Richard.
> Thanks,
> Richard
>
>
> Index: gcc/tree-vrp.c
> ===
On Tue, Apr 22, 2014 at 9:55 PM, Richard Sandiford
wrote:
> This is an assorted bunch of API tweaks:
>
> - use neg_p instead of lts_p (..., 0)
> - use STATIC_ASSERT for things that are known at compile time
> - avoid unnecessary wide(st)_int temporaries and arithmetic
> - remove an unnecessary tem
On Tue, Apr 22, 2014 at 9:51 PM, Richard Sandiford
wrote:
> Just a minor tweak to avoid several calculations when one would do.
> Since we have a function for rounded-up division, we might as well
> use it instead of the (X + Y - 1) / Y idiom.
>
> Tested on x86_64-linux-gnu. OK to install?
Ok.
On Tue, Apr 22, 2014 at 9:45 PM, Richard Sandiford
wrote:
> This is the first of 8 patches from reading through the diff with mainline.
> Some places had an off-by-one error on an index and some used "<= 0"
> instead of ">= 0".
>
> I think we should use MAX_BITSIZE_MODE_ANY_MODE rather than
> MAX_
On 04/22/2014 04:02 PM, Richard Sandiford wrote:
Looks like a few uses of the old idiom:
BITS_PER_UNIT == 8 ? 3 : exact_log2 (BITS_PER_UNIT)
I do not think that these crept in as much as they were never squished out.
have crept in. This patch replaces them with LOG2_BITS_PER_UNIT.
Test
On Thu, Feb 6, 2014 at 7:56 PM, Mike Stump wrote:
> On Nov 25, 2013, at 3:09 AM, Richard Biener
> wrote:
>> please add streamer_read/write_wi () helpers to data-streamer*
>>
>> replicating the above loop N times is too ugly.
>
> Agreed. Below is the patch to collapse the code. Thanks.
Ok.
>
On Nov 25, 2013, at 3:09 AM, Richard Biener wrote:
> please add streamer_read/write_wi () helpers to data-streamer*
>
> replicating the above loop N times is too ugly.
Agreed. Below is the patch to collapse the code. Thanks.
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 08
On Jan 9, 2014, at 7:16 AM, Richard Biener wrote:
> On Sat, Nov 23, 2013 at 8:20 PM, Mike Stump wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patch
On Jan 9, 2014, at 7:20 AM, Richard Biener wrote:
> @@ -968,7 +968,7 @@ get_polymorphic_call_info (tree fndecl,
>{
> base_pointer = TREE_OPERAND (base, 0);
> context->offset
> -+= offset2 + mem_ref_offset (base).low * BITS_PER_U
On Jan 1, 2014, at 7:58 PM, Mike Stump wrote:
> On Nov 23, 2013, at 11:21 AM, Mike Stump wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patch covers
On Jan 16, 2014, at 2:55 AM, Richard Sandiford
wrote:
>>> Why did you need the ? It was supposed to work without.
>>
>> The code in question needs something that is max int + max significand
>> real in size, we made the max int smaller (smaller than this quantity on
>> x86) so, this code needs
Mike Stump writes:
> On Jan 14, 2014, at 7:25 AM, Richard Sandiford
> wrote:
>> Mike Stump writes:
>>> diff --git a/gcc/expmed.c b/gcc/expmed.c
>>> index ce063eb..720d8c1 100644
>>> --- a/gcc/expmed.c
>>> +++ b/gcc/expmed.c
>>> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>>> return
On Jan 14, 2014, at 7:25 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> diff --git a/gcc/expmed.c b/gcc/expmed.c
>> index ce063eb..720d8c1 100644
>> --- a/gcc/expmed.c
>> +++ b/gcc/expmed.c
>> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>> return t;
>>
>> case CONST_DOUBL
Mike Stump writes:
> diff --git a/gcc/expmed.c b/gcc/expmed.c
> index ce063eb..720d8c1 100644
> --- a/gcc/expmed.c
> +++ b/gcc/expmed.c
> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>return t;
>
> case CONST_DOUBLE:
> + gcc_assert (HOST_BITS_PER_WIDE_INT * 2 <= MAX_BITSI
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the new wide-int code.
>
> Ok?
I know the patch
On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the constant folding code.
>
> Ok?
Ok for stage
On Thu, Jan 2, 2014 at 5:27 AM, Mike Stump wrote:
> On Nov 26, 2013, at 1:14 AM, Richard Biener
> wrote:
@@ -2662,8 +2661,8 @@ iv_number_of_iterations (struct loop *loop, rtx
insn, rtx condition,
iv1.step = const0_rtx;
if (INTVAL (iv0.step) < 0)
{
>
On Thu, Jan 2, 2014 at 5:53 AM, Mike Stump wrote:
> On Nov 23, 2013, at 11:22 AM, Mike Stump wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patch co
On Thu, Jan 2, 2014 at 5:12 AM, Mike Stump wrote:
> On Nov 23, 2013, at 11:22 AM, Mike Stump wrote:
>> Richi has asked the we break the wide-int patch so that the individual port
>> and front end maintainers can review their parts without have to go through
>> the entire patch.This patch co
On Thu, Jan 2, 2014 at 5:10 AM, Mike Stump wrote:
> On Nov 28, 2013, at 6:20 AM, Richard Biener
> wrote:
>> On Thu, Nov 28, 2013 at 12:58 PM, Richard Sandiford
>> wrote:
>>> Jakub Jelinek writes:
On Mon, Nov 25, 2013 at 12:24:30PM +0100, Richard Biener wrote:
> On Sat, Nov 23, 2013 at
On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the documentation.
>
> Ok?
Ok.
Thanks,
Richard
On Sat, Nov 23, 2013 at 8:20 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the build system (make).
>
> Ok?
Needs updating
On Sat, Jan 4, 2014 at 9:13 PM, Steve Kargl
wrote:
> On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
>> On Nov 23, 2013, at 12:16 PM, Steve Kargl
>> wrote:
>>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the
On Sat, Jan 4, 2014 at 12:54 AM, Mike Stump wrote:
> I'm wondering if all the outstanding issues you raised with "tree" have been
> addressed. If there are any that remain, let us know.
I hope so ;)
> If they have been, is the original patch (as modified of course by approved
> later work) Ok
> the fast path is not any faster. that was why we did not do it. And by
> the time you add the tests it would be slower.The thing is that on
> the inside of the so called fast path, you are still converting the tree
> to wide-int first and that conversion still is checking the rest of
> thes
On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
> On Nov 23, 2013, at 12:16 PM, Steve Kargl
> wrote:
>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
>>> Richi has asked the we break the wide-int patch so that the
>>> individual port and front end maintainers can review
I'm wondering if all the outstanding issues you raised with "tree" have been
addressed. If there are any that remain, let us know.
If they have been, is the original patch (as modified of course by approved
later work) Ok?
On Jan 2, 2014, at 2:26 PM, Eric Botcazou wrote:
>> So, I'd like to ping the original patch and Kenny's patch to resolve the
>> issues you found. If you have any other concerns or thoughts, let us
>> know.
>
> Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
> case of
On 11/26/2013 07:34 AM, Richard Biener wrote:
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -98,6 +98,15 @@ along with GCC; see the file COPYING3. If not see
array CONST_VAL[i].VALUE. That is fed into substitute_and_fold for
final substitution and folding.
+ This algorithm u
On 01/02/2014 05:26 PM, Eric Botcazou wrote:
So, I'd like to ping the original patch and Kenny's patch to resolve the
issues you found. If you have any other concerns or thoughts, let us
know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1
> So, I'd like to ping the original patch and Kenny's patch to resolve the
> issues you found. If you have any other concerns or thoughts, let us
> know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1 (and optionally add the fast path for t
So, Kenny hopefully resolved or answered your previous email, and the only
thing outstanding was the MAX_BITS_PER_UNIT. That part of the patch is now
gone (resolved in a much nicer way in another patch).
So, I'd like to ping the original patch and Kenny's patch to resolve the issues
you found.
1 - 100 of 545 matches
Mail list logo
