On 11/24/2013 08:38 AM, N.M. Maclaren wrote:
On Nov 24 2013, Kenneth Zadeck wrote:
Thank you for your posting. That certainly clears up my understanding.
If there is a clear description of the subset
of C++ that the front-end is allowed to use, a pointer to it for the
benefit of Fortran/C
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
+=
On 11/23/2013 08:19 PM, Joern Rennecke wrote:
On 23 November 2013 19:19, Mike Stump mikest...@comcast.net 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
On 11/23/2013 04:36 PM, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 11:19 AM, Mike Stump mikest...@comcast.net 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.
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 mikest...@comcast.net 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),
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
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
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.
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
zad...@naturalbridge.com 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
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))
-return
committed as revision 204987.
thanks
kenny
On 11/18/2013 05:38 AM, Richard Biener wrote:
On Fri, 15 Nov 2013, Kenneth Zadeck wrote:
This patch fixes a number of places where the mode bitsize had been used but
the mode precision should have been used. The tree level is somewhat sloppy
about
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 zad...@naturalbridge.com 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
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/16/2013 05:49 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com 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
On 11/15/2013 04:07 AM, Eric Botcazou wrote:
this code from fold-const.c starts on line 13811.
else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi
TREE_INT_CST_LOW (arg1) == signed_max_lo
TYPE_UNSIGNED (arg1_type)
/* We will flip the
since it does the correct thing if the underlying mode is a
partial int mode.
This code has been tested on x86-64 with no regressions. Ok to commit?
2013-11-15 Kenneth Zadeck zad...@naturalbridge.com
* tree.c (int_fits_type_p): Change GET_MODE_BITSIZE to
GET_MODE_PRECISION.
* fold
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
in doing the wide int conversion, i have found the following code on the
trunk which seems somewhat suspect:
this code from fold-const.c starts on line 13811.
else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi
TREE_INT_CST_LOW (arg1) == signed_max_lo
, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:04 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013
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/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck zad...@naturalbridge.com 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
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck zad...@naturalbridge.com
wrote:
On 11/08/2013 05:30 AM, Richard Sandiford
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
zad...@naturalbridge.com wrote:
On 11/11/2013 06:49 AM, Richard Biener wrote:
On Sat, Nov 9, 2013 at 3:23 PM, Kenneth Zadeck
zad...@naturalbridge.com
On 11/11/2013 10:29 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:04 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/11/2013 09:42 AM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 3:26 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/11/2013 06:49 AM, Richard Biener
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_hwi
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
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
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
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
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 the
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 rdsandif...@googlemail.com
wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
So what is the big plan here
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
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
On 11/05/2013 09:12 AM, Jan-Benedict Glaw wrote:
On Sun, 2013-11-03 08:29:12 -0500, Kenneth Zadeck zad...@naturalbridge.com
wrote:
On Nov 3, 2013, at 5:24 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Index: gcc/config/vax/vax.c
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
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
Vax, seriously??? Are there any left?
On Nov 3, 2013, at 5:24 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Installed as obvious.
Richard
Index: gcc/config/vax/vax.c
===
--- gcc/config/vax/vax.c2013-11-03
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
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
On 11/02/2013 10:25 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch
On 11/02/2013 01:51 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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 merge point. This patch removes all the differences I saw
for alpha-linux-gnu in
On 11/01/2013 09:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
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
On 10/30/2013 02:34 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 10/30/2013 07:01 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 10/29/2013 06:37 PM, Richard Sandiford wrote:
This patch tries to update the main wide_int
On 10/30/2013 07:01 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Sun, 27 Oct 2013, Richard Sandiford wrote:
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) (X))
idiom that was
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 it's
necessarily true that all offset_ints are signed. (widest_int are
though.)
i am
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Sun, 27 Oct 2013, Richard Sandiford wrote:
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) (X))
idiom that was
On 10/23/2013 08:13 AM, Richard Biener wrote:
On Wed, 23 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The patch does that by adding:
wi::address (t)
for when we want to extend tree t to addr_wide_int precision and:
wi::extend (t)
for when we want to
On 10/20/2013 06:30 AM, Richard Sandiford wrote:
If yesterday's patch goes in, we'll only need the scratch array for
HWI inputs. We can therefore shrink it to 2 HWIs.
Tested on x86_64-linux-gnu. OK for wide-int?
Thanks,
Richard
Index: gcc/wide-int.h
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump mikest...@comcast.net writes:
+ // We optimize x y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like 0x8000, those would be encoded
+ // with
On 10/19/2013 02:41 PM, Mike Stump wrote:
On Oct 19, 2013, at 7:22 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
As discussed, this patch effectively goes back to your original idea of
having excess upper bits in a HWI being undefined on read (at least as
the default assumption).
On 10/19/2013 10:18 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump mikest...@comcast.net writes:
+ // We optimize x y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison
, Richard Sandiford wrote:
[off-list]
Kenneth Zadeck zad...@naturalbridge.com writes:
Richi,
Do you want me to back out the patch that changes the rep for unsigned
tree-csts?
kenny
Doesn't look like you're on IRC, so FWIW:
rsandifo richi: just to check, you still want the scratch array
On 10/18/2013 04:45 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Mike Stump wrote:
On Oct 17, 2013, at 1:46 AM, Richard Biener rguent...@suse.de wrote:
[This function shows another optimization issue:
case BOOLEAN_TYPE:
/* Cache false or true. */
limit = 2;
if
Richi,
Do you want me to back out the patch that changes the rep for unsigned
tree-csts?
kenny
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious if we're directly using 128-bit numbers
in addr_wide_int. The justification for the
On 10/17/2013 07:49 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation
On 10/17/2013 07:30 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way
On 10/17/2013 09:16 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not
On 10/16/2013 09:55 AM, Richard Biener wrote:
Speaking in terms of a patch:
Index: tree.h
===
--- tree.h (revision 203690)
+++ tree.h (working copy)
@@ -5184,14 +5184,11 @@ wi::int_traits const_tree::decompose (
This patch makes the PPC the first public target to use the
CONST_WIDE_INT representation rather than CONST_DOUBLES to represent
larger integers. There are two parts to this patch. The changes to
genrecog.c represent fixes that would be needed for any port that
supports CONST_WIDE_INTS
On 10/16/2013 02:45 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I note that we immediately return in the above case, so
if (precision xprecision + HOST_BITS_PER_WIDE_INT)
{
len = wi::force_to_size (scratch, val, len, xprecision
On 10/15/2013 02:30 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
if (small_prec)
;
else if (precision == xprecision)
while (len = 0 val[len - 1] == -1)
len--;
Err, len 0 obviously.
you were only close.patch
i added the assertion that richard requested and tested this on x86-64.
committed as revision 203602.
On 10/06/2013 05:13 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 10/04/2013 01:00 PM, Richard Sandiford wrote:
I was hoping Richard would weigh in here
So here is a patch with the change. As before, bootstrapped an tested on
x86-64.
On 10/03/2013 12:16 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
Changing the representation of unsigned constants is only worthwhile
if we can avoid the force_to_size for some
On 10/04/2013 01:00 PM, Richard Sandiford wrote:
I was hoping Richard would weigh in here. In case not...
Kenneth Zadeck zad...@naturalbridge.com writes:
I was thinking that we should always be able to use the constant as-is
for max_wide_int-based and addr_wide_int-based operations
Richard and others,
This patch changes the way that unsigned trees are canonicalized. As
with the last patch, I think that this patch is not that much of a step
forward. While it is still true that the signed tree-csts match the
representation of wide-ints, unsigned tree-csts do not and
On 10/03/2013 10:29 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
+ /* Got to be careful of precision 0 values. */
+ if (precision)
+len = MIN (len, max_len);
+ if (TYPE_SIGN (TREE_TYPE (x)) == UNSIGNED)
{
- if (precision HOST_BITS_PER_WIDE_INT
I was thinking that we should always be able to use the constant as-is
for max_wide_int-based and addr_wide_int-based operations. The small_prec
again, you can get edge cased to death here.i think it would work
for max because that really is bigger than anything else, but it is
possible
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types or
modes that are not a perfect multiple of HOST_BITS_PER_WIDE_INT.
I expect that most of the changes in rtl.h will go
On 09/24/2013 09:51 AM, Richard Biener wrote:
On Tue, 24 Sep 2013, Kenneth Zadeck wrote:
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types
or
modes
Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Tue, 24 Sep 2013, Kenneth Zadeck wrote:
On 09/24/2013 09:39 AM, Richard Biener wrote:
On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
Richi,
This patch canonizes the bits above the precision for wide ints with types
or
modes
Mike started a merge from trunk to the wide-int branch because the
previous merge had happened when bootstrap was broken for ppc.
This patch fixes mike's partial merge and has been bootstrapped and
tested on ppc. I will pull the patch down and test it on x86-64 tonight.
kenny
Index:
this looks fine to me.
On 09/19/2013 02:56 PM, Richard Sandiford wrote:
It turns out that gcc20's version of binutils is too old for the LTO plugin,
so the tests I'd been running hadn't exercised it. This patch fixes a
regression that Kenny pointed out.
The problem was that build_int_cst and
this is fine with me.
kenny
On 09/18/2013 03:27 AM, Richard Sandiford wrote:
Ping
Richard Sandiford rdsandif...@googlemail.com writes:
Enabling the CONST_INT assert showed that this branch-local code was
passing the wrong mode to std::make_pair. The mode of X is OLDMODE,
and we're supposed
Richi,
This patch canonizes the bits above the precision for wide ints with
types or modes that are not a perfect multiple of HOST_BITS_PER_WIDE_INT.
I expect that most of the changes in rtl.h will go away. in
particular, when we decide that we can depend on richard's patch to
clean up
On 09/09/2013 09:56 AM, Richard Sandiford wrote:
Richard Biener richard.guent...@gmail.com writes:
On Mon, Sep 9, 2013 at 3:11 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Enabling the CONST_INT assert showed that this branch-local code was
passing the wrong mode to std::make_pair.
i still have more testing to go on this but it seems to be ok.my
current problem is that the branch seems to have a fair number of
failures so i want to get that cleaned up before i do further testing
and commit this.
I left the old rtl constructor ifdefed out. We are likely to want
Richi, and the rest of the community,
Richard Sandiford has proposed a set of patches that change the wide-int
api in a significant way. We think that we really need some input from
the community as to if this is what we want using C++ in gcc is going to
look like. There are, as I see it, two
101 - 200 of 557 matches
Mail list logo
