On 10/30/2013 07:01 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int comment to reflect the current
implementation.
- bitsizetype is TImode on x86_64 and others, so I don't think
On 10/31/2013 05:01 AM, Richard Sandiford wrote:
There are several Ada failures on the branch, all related to division
and modulus:
- div_floor adjusted truncated negative quotients in the wrong direction
(up instead of down). E.g. -5 /[fl] 2 gave -1 rather than -3.
- {div,mod}_round used t
On 10/30/2013 02:34 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/30/2013 07:01 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int comment to reflect the current
implementation
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all the differences I saw
for alpha-linux-gnu in g
On 11/01/2013 09:31 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/01/2013 04:46 AM, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the
I always like patches that change host dependencies into more general code.
ok from my perspective.
kenny
On 11/02/2013 06:13 AM, Richard Sandiford wrote:
I decided to lump these together since the problems were the same.
There were some typos in the real_to_integer invocation, while changing:
On 11/02/2013 06:19 AM, Richard Sandiford wrote:
...which I'd fluffed when doing the wi:: conversion.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. It fixed a spurious
gcc.dg difference on alpha-linux-gnu. Applied as obvious.
Thanks,
Richard
Index: gcc/wide-int.cc
On 11/02/2013 06:30 AM, Richard Sandiford wrote:
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-extended.
Nonzero/true BImode integers are stored as STORE_FLAG_VALUE,
which can be 1 rather than -1. So (const_int 1) can be a
On 11/02/2013 06:48 AM, Richard Sandiford wrote:
It turns out that when doing a vector shift by 2, the optab routine
passes (const_int 2) to convert_modes with oldmode set to the mode
of the shift (e.g. something like V8HI). When the target mode is a
real integer mode like SImode, mainline just
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have installed it as
obvious. The second part isn't as obvious though. The old code stored
the maximum iterations as:
this is fine with me.
kenny
On 11/02/2013 07:52 AM, Richard Sandiford wrote:
r201806 added some extra checks to the handling of CONCAT when expanding
assignments. This was to fix an ICE on gcc.dg/pr48335-2.c for ppc.
I tripped over this because it also causes the assembly output for
the test
On 11/02/2013 07:14 AM, Richard Sandiford wrote:
The wide-int conversion for the fold_ternary VEC_PERM_EXPR case
converted a mask of valid element numbers to an element count,
which is one greater. The old code set need_mask_canon if an index
was greater than the mask, but the new code sets it i
On 11/02/2013 10:25 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 06:30 AM, Richard Sandiford wrote:
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-extended.
Nonzero/true BImode integers are stored as
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have installed it as
obvious. The second
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int
On 11/02/2013 01:51 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this
Vax, seriously??? Are there any left?
On Nov 3, 2013, at 5:24 AM, Richard Sandiford
wrote:
> Installed as obvious.
>
> Richard
>
>
> Index: gcc/config/vax/vax.c
> ===
> --- gcc/config/vax/vax.c2013-11-03 10:24:01.013238719
On 11/04/2013 04:12 AM, Richard Biener wrote:
On Fri, 1 Nov 2013, Richard Sandiford wrote:
I'm building one target for each supported CPU and comparing the wide-int
assembly output of gcc.c-torture, gcc.dg and g++.dg with the corresponding
output from the merge point. This patch removes all th
We will of course measure it but the only thing that is different because of
the conversion is that timode integers are packaged differently
> On Nov 26, 2013, at 6:17 PM, David Edelsohn wrote:
>
>> On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump wrote:
>>
>> Ok?
>
> The revised version of the
committed as revision 205448 to trunk.
committed as revision 205455 to wide-int branch.
On 11/27/2013 05:50 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 5:33 PM, Kenneth Zadeck
wrote:
Richi,
patch ping
Ok.
Thanks,
Richard.
also two more pieces of information.With further testing
Eric,
Let me make one high level comment here and the low level comments will
be responded to when i fix the patch.
CONST_DOUBLE has two hwis in it. So in practice, you get 128 bits and
that is it.a CONST_WIDE_INT has an array of HWIs that has as many
elements as it needs to represent
This patch does three things in wide-int:
1) it cleans up some comments.
2) removes a small amount of trash.
3) it changes the max size of the wide int from being 4x of
MAX_BITSIZE_MODE_ANY_INT to 2x +1. This should improve large muls and
divs as well as perhaps help with some cache behavior.
I would like to see some comment to the effect that this to allow
inlining for the common case for widest int and offset int without
inlining the uncommon case for regular wide-int.
On 11/28/2013 12:38 PM, Richard Sandiford wrote:
Currently add and sub have no fast path for offset_int and w
this is fine.
kenny
On 11/28/2013 12:29 PM, Richard Sandiford wrote:
The existing ltu_p fast path can handle any pairs of single-HWI inputs,
even for precision > HOST_BITS_PER_WIDE_INT. In that case both xl and
yl are implicitly sign-extended to the larger precision, but with the
extended value
like the add/sub patch, enhance the comment so that it says that it is
designed to hit the widestint and offset int common cases.
kenny
On 11/28/2013 12:34 PM, Richard Sandiford wrote:
As Richi asked, this patch makes cmps use the same shortcuts as lts_p.
It also makes cmpu use the shortcut tha
On Nov 29, 2013, at 4:24 AM, Richard Biener wrote:
> On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
> wrote:
>> This patch does three things in wide-int:
>>
>> 1) it cleans up some comments.
>> 2) removes a small amount of trash.
>> 3) it changes the ma
could be.
On 11/29/2013 06:57 AM, Richard Sandiford wrote:
Looks good to me FWIW, except:
Kenneth Zadeck writes:
@@ -112,11 +114,11 @@ along with GCC; see the file COPYING3.
two, the default is the prefered representation.
All three flavors of wide_int are represented as a vector
function itself.
The other place is the tree-vpn that is discussed here and will be dealt
with in the other patches.
tested on x86-64.
Ok to commit?
Kenny
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
wrote:
This patch does three things in
committed as revision 205599 to wide-int branch.
kenny
On 12/02/2013 05:50 AM, Richard Biener wrote:
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck
wrote:
Richi,
this is the first of either 2 or 3 patches to fix this.There are two
places that need be fixed for us to do 1X + 1 and this
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
kenny
On 12/02/2013 03:34 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
Tha
if i did not already say so, this is fine.
kenny
On 12/02/2013 03:20 PM, Richard Sandiford wrote:
I noticed that there were still a couple of tests for zero precision.
This patch replaces them with asserts when handling separately-supplied
precisions and simply drops them when handling existing
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
wrote:
This patch does three things in wide-int:
1) it cleans up some comments.
2) removes a small amount of trash.
3) it changes the max size of the wide int from being 4x of
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from df*.[ch]
in combine but there are a couple of problems. First of all, combine
does its own DF analysi
On 12/04/2013 07:56 AM, 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 used 58 times for cp/pa
On 12/03/2013 02:38 PM, Jeff Law wrote:
On 12/03/13 12:25, Kenneth Zadeck wrote:
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from
df*.[ch]
in
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working copy)
@@ -2611,22 +2611,28 @@ extract_range_from_binary_expr_1 (value_
ectory `/home/zadeck/gcc/gbbBadMulVrp'
make: *** [all] Error 2
heracles:~/gcc/gbbBadMulVrp(9) cd ../gccBadMulVrp/
On 12/06/2013 11:45 AM, Kenneth Zadeck wrote:
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
On 11/27/2013 11:24 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 first half of the rtl code.
--- a/gcc/cse.c
+++ b/gcc/cs
On 12/06/2013 01:32 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
- / HOST_BITS_PER_WIDE_INT)
+ (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1
On 12/09/2013 10:12 AM, Richard Sandiford wrote:
Richard Biener writes:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT
This patch is the last performance patch that i have for wide-int.
This patch changes large multiply from taking precision/hbpwi *
precision/hbpwi multiplies to taking
#significant_bits1/hbpwi * #significant_bits2/hbpwi multiplications.
That was a significant number of multiplies on machines
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1
This patch is for the trunk, but it solves a problem that comes up for
wide-int. For wide-int we need to have the BITS_PER_UNIT available
earlier.So this patch sets the default value (8) in genmodes.c so
that it is available by anyone who includes insn-modes.h. The generator
for tm.h
On 12/11/2013 08:42 PM, DJ Delorie wrote:
The m32c part is OK.
thanks for the fast reply.
kenny
On Dec 13, 2013, at 5:11 AM, Richard Biener wrote:
> On Fri, 13 Dec 2013, Uros Bizjak wrote:
>
>> Hello!
>>
>>> In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT
>>> is calculated.
>>> The value is heavily used on the wide-int branch to allocate buffers that
>>>
committed as revision 205964 with updated comment.
kenny
2013-12-13 Kenneth Zadeck
* config/arc/arc.h (BITS_PER_UNIT): Removed.
* config/bfin/bfin.h (BITS_PER_UNIT): Removed.
* config/lm32/lm32.h (BITS_PER_UNIT): Removed.
* config/m32c/m32c.h (BITS_PER_UNIT): Removed
committed as revision 205970 as obvious.
kenny
Index: gcc/genmodes.c
===
--- gcc/genmodes.c (revision 205967)
+++ gcc/genmodes.c (working copy)
@@ -891,7 +891,7 @@ emit_max_int (void)
max = i->bytesize;
if (max > mmax)
m
On 12/14/2013 06:40 AM, Richard Sandiford wrote:
Hi Kenny,
Sorry for the slow response.
Kenneth Zadeck writes:
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 205765)
+++ gcc/wide-int.cc (working copy
The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask about
overflow, then it really does not matter because we are not going to
On 12/14/2013 09:30 AM, Richard Sandiford wrote:
+ /* True if the result needs to be negated. */
+ bool is_neg = false;
/* If the top level routine did not really pass in an overflow, then
just make sure that we never attempt to set it. */
bool needs_overflow = (overfl
+ vallen = canonize (val, (uvlen + 1) >> 1, prec);
+
+ /* Shift is not always safe to write over one of the
+operands, so we must copy. */
+ HOST_WIDE_INT tval[2 * WIDE_INT_MAX_ELTS];
+ memcpy (tval, val, vallen * CHAR_BIT / HOST_BITS_PER_WIDE_INT);
vallen * size
On 12/15/2013 03:54 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggestion that we
should remove the checking from the infinite precision would not support
this
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of
On 12/16/2013 01:37 PM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck wrote:
On 12/16/2013 06:19 AM, Richard Biener wrote:
On 12/15/13 7:48 PM, Kenneth Zadeck wrote:
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck
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
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
This patch fixes what appears to have been a long standing failure in
the conversion of tree-vect-generic.c:build_replicated_const. This
failure caused several regressions on the branch.
Committed as revision 206616
Index: gcc/tree-vect-generic.c
I had the following conversation with richi about this patch.
Sorry to reply off thread, but i do net read this group in my mailer.
[09:00]zadeckrichi: i am reviewing a patch and i have a couple
of questions, do you have a second to look at something?
[09:00]richizadeck: sure
On 11/05/2013 09:12 AM, Jan-Benedict Glaw wrote:
On Sun, 2013-11-03 08:29:12 -0500, Kenneth Zadeck
wrote:
On Nov 3, 2013, at 5:24 AM, Richard Sandiford
wrote:
Index: gcc/config/vax/vax.c
===
--- gcc/config/vax/vax.c2013-11
This is the right way to fix this. thanks.
kenny
On 11/05/2013 03:00 PM, Richard Sandiford wrote:
I've committed the patch below, which is a trivial wide-intification of:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00335.html
I won't commit the mainline patch for a couple of days to give
So what is the big plan here? if you remove it here and then do not
do it in wide int, then it is not going to be truncated.
kenny
On 11/06/2013 05:10 PM, Richard Sandiford wrote:
Following the removal of SHIFT_COUNT_TRUNCATED from double-int, this patch
reverts the changed I'd made to mi
retty rare for math. We should always tread carefully
when doing that, and the excuse that it is "cleaner" does not, in my mind, fit
the bill.
On Nov 7, 2013, at 2:08 AM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>> So what is the big plan here? if you r
I doubt that this list is comprehensive.
When i many of these things a long time ago, I was not that interested
in bit for bit compatibly as long as was never introducing any
problems.in some cases it would have been hard to replicate some of
the end cases with the wide-int code.
On 11/0
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
Some comments from looking through the diff with the merge point,
ignoring wide-int.h and wide-int.cc. A few more to follow in the
form of patchses.
dwarf2out.c has:
+case CONST_WIDE_INT:
+ if (mode == VOIDmode)
+
On 11/09/2013 05:13 AM, Richard Sandiford wrote:
There are two instances of:
if (TREE_CODE (x) != INTEGER_CST)
GCC_BAD ("invalid constant in %<#pragma pack%> - ignored");
/* Cannot use tree_to_uhwi here or it will ice if above message printed.
*/
align = tree_to_hw
On 11/09/2013 05:16 AM, Richard Sandiford wrote:
wide_int_type_size_in_bits returns an offset_int (previously an addr_int)
rather than a wide_int, so this patch renames it accordingly.
Tested on powerpc64-linux-gnu and by rerunning the assembly comparison.
OK to install?
Thanks,
Richard
Index
looks good to me.
On 11/09/2013 05:17 AM, Richard Sandiford wrote:
Some cases where we could use const references instead of passing by value.
Tested on powerpc64-linux-gnu and by rerunning the assembly comparison.
OK to install?
Thanks,
Richard
Index: gcc/fold-const.c
==
On 11/09/2013 05:28 AM, Richard Sandiford wrote:
Avoid some unnecessary "wide_int (x)"s and make more use of wi::.
(In the cp/decl.c case the wi:: avoids using HWIs rather than avoiding
a wide_int temporary.)
As far as the first hunk goes, the trunk code is:
unsigned HOST_WIDE_INT bytes;
On 11/09/2013 05:51 AM, Richard Sandiford wrote:
Trunk expand_mult uses the following code to handle CONST_DOUBLEs:
/* If we are multiplying in DImode, it may still be a win
to try to work with shifts and adds. */
if (CONST_DOUBLE_HIGH (scalar_op1) == 0
On 11/09/2013 05:55 AM, Richard Sandiford wrote:
wide-int adds some code to div_if_zero_remainder to handle mismatched signs.
I think it's trying to make sure that we do the division to "infinite"
precision, extending each operand according to its own sign. We can do
that more easily using wi::t
On 11/09/2013 05:57 AM, Richard Sandiford wrote:
"mode_for_size (MAX_BITSIZE_MODE_ANY_INT, MODE_INT, 0)" isn't safe
because the widest mode might not have an integer counterpart.
We can get the widest integer mode directly using MAX_MODE_INT.
Tested on powerpc64-linux-gnu and by rerunning the as
On 11/09/2013 05:58 AM, Richard Sandiford wrote:
LOAD_EXTEND_OP is about extending a subword value to a word. The final
wide_int should therefore be word_mode rather than GET_MODE (src).
Tested on powerpc64-linux-gnu and by rerunning the assembly comparison.
OK to install?
Thanks,
Richard
In
On 11/09/2013 06:09 AM, Richard Sandiford wrote:
Some minor tweaks to the documentation and commentary. The hyphenation
and "non zero"->"nonzero" changes are supposed to be per guidelines:
http://gcc.gnu.org/codingconventions.html#Spelling
Hope I got them right.
OK to install?
This is th
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck wrote:
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
From tree-vrp.c:
@@ -1893,6 +1884,10 @@ vrp_int_const_binop (enum tree_code code
/* If the singed operation wraps then int_const_binop
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck
wrote:
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
From tree-vrp.c:
@@ -1893,6 +1884,10
On 11/11/2013 10:04 AM, Kenneth Zadeck wrote:
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck
wrote:
On 11/08/2013 05:30 AM, Richard Sandiford
On 11/11/2013 10:29 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:04 PM, Kenneth Zadeck
wrote:
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth
3 10:29 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:04 PM, Kenneth Zadeck
wrote:
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck
wrote:
On 11/12/2013 11:27 AM, Joseph S. Myers wrote:
On Tue, 12 Nov 2013, Kenneth Zadeck wrote:
Richi,
i am having a little trouble putting this back the way that you want. The
issue is rem.
what is supposed to happen for INT_MIN % -1?
I would assume because i am failing the last case of gcc.dg
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
Some comments from looking through the diff with the merge point,
ignoring wide-int.h and wide-int.cc. A few more to follow in the
form of patchses.
dwarf2out.c has:
+case CONST_WIDE_INT:
+ if (mode == VOIDmode)
+
Please ignore the email i just sent that looks like this.I
accidentally pushed the send button. it is not ready yet.
kenny
On 11/15/2013 12:49 PM, Kenneth Zadeck wrote:
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
Some comments from looking through the diff with the merge point
On 11/16/2013 05:49 AM, Richard Sandiford wrote:
Richard Sandiford writes:
Some minor tweaks to the documentation and commentary. The hyphenation
and "non zero"->"nonzero" changes are supposed to be per guidelines:
http://gcc.gnu.org/codingconventions.html#Spelling
Hope I got them right.
On 11/17/2013 05:29 AM, Richard Sandiford wrote:
AIUI the two-argument tree_fits_hwi_p and tree_to_hwi were replacements
for host_integerp and tree_low_cst with variable "pos" arguments.
I removed those uses from trunk this week, and Mike's merge has
brought that into branch.
i think that i am a
On 11/17/2013 10:58 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/17/2013 05:29 AM, Richard Sandiford wrote:
AIUI the two-argument tree_fits_hwi_p and tree_to_hwi were replacements
for host_integerp and tree_low_cst with variable "pos" arguments.
I removed those uses
On 11/08/2013 05:30 AM, Richard Sandiford wrote:
Some comments from looking through the diff with the merge point,
ignoring wide-int.h and wide-int.cc. A few more to follow in the
form of patchses.
dwarf2out.c has:
+case CONST_WIDE_INT:
+ if (mode == VOIDmode)
+
Committed with all your changes as revision 205049.
the only interesting change is the response to your last comment.
I changed the frag to:
/* Third, unsigned integers with top bit set never fit signed types. */
- if (!TYPE_UNSIGNED (type) && sgn_c == UNSIGNED && wi::neg_p (c))
-retur
I would leave out the last frag of tree.c. It actually gets rid of what
i consider, a latent bug. it does not show up with the current
implementation of wide-int, but if that implementation changed, it
would. The problem is that you really should not expect that you can
set the min or max va
looks fine to me.
kenny
On 11/20/2013 09:00 AM, Richard Sandiford wrote:
This test changes from TREE_INT_CST_LOW to TREE_INT_CST_ELT. I was going
to change it back as part of the previous patch, but using wi:: seemed
more robust.
Only compile-tested so far because of problems with gcc110. OK
Richi,
We noticed three problems with the place_field on the wide-int
branch.They come from problems on the trunk. So i assume you want
me to fix the trunk and push back into the branch. The question is how
do you want them fixed?
1) at line 1198, rli->offset is tested as an unsigned
On 11/13/2013 04:59 AM, Richard Biener wrote:
On Tue, Nov 12, 2013 at 5:43 PM, Kenneth Zadeck
wrote:
On 11/12/2013 11:27 AM, Joseph S. Myers wrote:
On Tue, 12 Nov 2013, Kenneth Zadeck wrote:
Richi,
i am having a little trouble putting this back the way that you want.
The
issue is rem.
what
Richi,
Here is the patch. As you can see, i chose the unsigned option.
It was bootstrapped and tested on x86 with all languages including ada.
Ok to commit?
kenny
2013-11-21 zad...@naturalbridge.com
* store-layout.c
(place-field): Fix hwi test and accessor mismatch.
On 11/21/2013
committed as revision 205260.
thanks
kenny
On 11/22/2013 03:58 AM, Richard Biener wrote:
On Thu, 21 Nov 2013, Kenneth Zadeck wrote:
Richi,
Here is the patch. As you can see, i chose the unsigned option.
It was bootstrapped and tested on x86 with all languages including ada.
Ok to commit
I am sorry that in the haste of battle that mike did not have an
opportunity to write a proper introduction to the is patch. The patch
was submitted last night so that it could be formally submitted by the
end of stage 1.
This patch is the same as the top of the wide-int branch that has been
On 11/22/2013 03:03 PM, Richard Biener wrote:
On Thu, Nov 21, 2013 at 11:08 PM, Mike Stump wrote:
This patch adds support for ints wider than double_int.
Ok?
Please split the patch into pieces. I suggest to separate changes to
the various frontends
(CC maintainers), the new wide-int files,
On 11/23/2013 08:47 PM, Jason Merrill wrote:
On 11/23/2013 02:21 PM, Mike Stump wrote:
- if (SCALAR_FLOAT_MODE_P (mode))
+#if TARGET_SUPPORTS_WIDE_INT == 0
+ if (!SCALAR_FLOAT_MODE_P (mode))
+{
+ mem_loc_result->dw_loc_oprnd2.val_class
+= dw_val_class_const_do
101 - 200 of 350 matches
Mail list logo
