2015-09-01 Kenneth Zadeck <zad...@naturalbridge.com>
* gcc.c-torture/execute/ieee/2320-1.c Fixed misplaced test
case.
This was approved offline by Mike Stump.
committed as revision 227389.
Kenny
--- gcc/testsuite/gcc.c-torture/execute/ieee/2320-1.c (revision 227385)
+
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
-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Tuesday, March 03, 2015 12:02 PM
To: 'Bernhard Reutner-Fischer'; gcc-patches@gcc.gnu.org; 'Paolo Bonzini';
'Seongbae Park'; 'Kenneth Zadeck'
Subject: RE: [PATCH] Fix removing of df problem in df_finish_pass
From: Bernhard Reutner-Fischer
/25/2015 01:54 PM, Georg-Johann Lay wrote:
Am 02/24/2015 um 07:33 PM schrieb Kenneth Zadeck:
when i suggested that you do a build with all of the checking turned
on, i
wanted you to this without you new code in it.there is a good
possibility
that the problem is that your port is generating bad
It is generally as easy as just adding the problem and calling
df_analyze. You tend to get into trouble if the rtl is not good, i.e.
there is improper sharing or other violations of the canonical rtl
rules. DF does not like improperly shared rtl and it has not been
uncommon for port specific
when i suggested that you do a build with all of the checking turned on,
i wanted you to this without you new code in it.there is a good
possibility that the problem is that your port is generating bad rtl.
Also, you should generate a debuggable compiler so that the line numbers
have some
On Feb 18, 2015, at 3:23 AM, Joseph Myers jos...@codesourcery.com wrote:
On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
The fp exceptions raise some very tricky issues with respect to gcc and
optimization. On many machines, noisy does not mean to throw an
exception, it means that you
On 02/17/2015 07:05 AM, Joseph Myers wrote:
On Tue, 17 Feb 2015, Richard Earnshaw wrote:
So the problem we have today is the compiler has no way to distinguish
between, say, and __builtin_isless. According to Annex F (c99) the
former should be signalling while the latter quiet.
We do have
On Feb 17, 2015, at 6:01 PM, Joseph Myers jos...@codesourcery.com wrote:
On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
On 02/17/2015 07:05 AM, Joseph Myers wrote:
On Tue, 17 Feb 2015, Richard Earnshaw wrote:
So the problem we have today is the compiler has no way to distinguish
On 02/14/2015 03:26 PM, Paolo Bonzini wrote:
On 10/02/2015 22:46, Joseph Myers wrote:
It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
choice of definition is a matter of what's convenient for the
implementation (and which choice you make determines which existing code
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of the defs that reach it. I believe
a signaling
2) it matches iso n1778 which is primarily written to satisfy the needs
to (b).
3) Whenever you leave something like this undefined, you are basically
saying do not optimize
On 02/10/2015 04:46 PM, Joseph Myers wrote:
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
I don't think it's useful
On 02/09/2015 06:24 PM, Joseph Myers wrote:
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu
Before I commit this, or do the corresponding tree level patch, I would
like this to be looked at by the FP people. I am guessing at some of
this, other parts i gleaned from various standards docs and an irc
conversation with Joseph. This should have been documented when it was
put into
On 02/09/2015 06:26 PM, Richard Henderson wrote:
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater
On 12/19/2014 06:26 AM, Richard Biener wrote:
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wong.kwongyuan.to...@gmail.com wrote:
2014-12-19 3:51 GMT+00:00 Bin.Cheng amker.ch...@gmail.com:
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Thu, Dec 18,
2014-05-09 Kenneth Zadeck zad...@naturalbridge.com
PR middle-end/6
* fold-const.c (fold_binary_loc): Changed width of mask.
committed as revision 210274.
kenny
Index: gcc/fold-const.c
===
--- gcc/fold-const.c
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 jos...@codesourcery.com writes:
On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
DATE Ramana Radhakrishnan ramana.radhakrish...@arm.com
please hold off on committing patches for the next couple of hours as we
have a very large merge to do.
thanks.
kenny
please hold off on committing patches for the next couple of hours as we
have a very large merge to do.
thanks.
kenny
here is a comparison. The two areas were built using configure with no
options at all on x86-64. The comparison is between revision 210112 and
210113.Tsan is very unhappy but everything else looks ok.I know
that this worked a couple of days before the merge. I know that there
was
We are now ready to merge the wide-int branch.The branch was broken
into small pieces and each of the area maintainers has approved their
pieces.
The branch has been tested and runs regression free on three 64 bit
platforms: x86, ppc, and s390 and on three 32 bit platforms: x86, arm
and
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
Then with a fixed comment, this patch is fine.
kenny
On 05/03/2014 02:59 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
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 =
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
At this point we have believe that we have addressed all of the concerns
that the community has made about the wide-int branch. We have also
had each of the sections of the branch approved by the area maintainers.
We are awaiting a clean build on the arm and are currently retesting
x86-64,
ok to commit.
kenny
On 04/28/2014 11:42 AM, Richard Sandiford wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
With that patch bootstrap now still fails at dwarf2out.c with the same
message. I'm attaching a gzipped dwarf2out.ii
Thanks. This is a nice proof of why clz_zero and ctz_zero
On 04/28/2014 12:25 PM, Mike Stump wrote:
On Apr 28, 2014, at 2:36 AM, Richard Sandiford rsand...@linux.vnet.ibm.com
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
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 zad...@naturalbridge.com writes:
don't you think that it would be easier to understand the number if you
printed
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
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,
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
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
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 the
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.
On 04/23/2014 04:04 AM, Richard Biener wrote:
On Tue, 22 Apr 2014, Mike Stump wrote:
On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
While of course one hopes that there will be no issues with wide-int, a
change of this size will have some pain no matter how well
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
Ping.
On 04/23/2014 10:36 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
Richi,
David Edelsohn said that I should talk to you about appointing reviewers
for wide-int.While I think that it may not be necessary to have any
reviewers for wide-int in the long term, I think that it would be useful
to make Richard Sandiford, Mike Stump and myself reviewers at least
On 04/22/2014 03:37 PM, Richard Biener wrote:
On April 22, 2014 9:28:15 PM CEST, Kenneth Zadeck zad...@naturalbridge.com
wrote:
Richi,
David Edelsohn said that I should talk to you about appointing
reviewers
for wide-int.While I think that it may not be necessary to have any
reviewers
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.
several test cases started failing as a result of making the size of the
wide-int buffer smaller.
this patch fixes them. This failure was unrelated to the wide-int
buffer size directly, but a hard constant in the truck code was replaced
by MAX_BITSIZE_MODE_ANY_INT when it should have been
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
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
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
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 zad...@naturalbridge.com writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com 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 zad...@naturalbridge.com writes
On 12/16/2013 01:37 PM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/16/2013 09:37 AM, Richard Biener wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 12/15/2013 03:54 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 12/14/2013 06:40 AM, Richard Sandiford wrote:
Hi Kenny,
Sorry for the slow response.
Kenneth Zadeck zad...@naturalbridge.com writes:
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 205765)
+++ gcc/wide-int.cc
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
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 =
+ 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 *
On Dec 13, 2013, at 5:11 AM, Richard Biener rguent...@suse.de 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 zad...@naturalbridge.com
* 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
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)
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
#define
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 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
- / HOST_BITS_PER_WIDE_INT
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
#define
On 12/09/2013 10:12 AM, Richard Sandiford wrote:
Richard Biener richard.guent...@gmail.com writes:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford rdsandif...@googlemail.com wrote:
Kenneth Zadeck
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/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working copy)
@@ -2611,22 +2611,28
-bubble] Error 2
make[1]: Leaving directory `/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 zad...@naturalbridge.com writes
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
+++
On 12/06/2013 01:32 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
Index: tree-vrp.c
===
--- tree
On 12/04/2013 07:56 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com 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
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 l...@redhat.com wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from
df
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
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
zad...@naturalbridge.com 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
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law l...@redhat.com 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
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
zad...@naturalbridge.com wrote:
Richi,
this is the first of either 2 or 3 patches to fix this.There are two
places that need be fixed
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 zad...@naturalbridge.com 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
On Nov 29, 2013, at 4:24 AM, Richard Biener richard.guent...@gmail.com wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
zad...@naturalbridge.com 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
could be.
On 11/29/2013 06:57 AM, Richard Sandiford wrote:
Looks good to me FWIW, except:
Kenneth Zadeck zad...@naturalbridge.com 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
the
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
zad...@naturalbridge.com 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
MAX_BITSIZE_MODE_ANY_INT to 2x +1. This should improve large muls and
divs as well as perhaps help with some cache
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
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
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
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
zad...@naturalbridge.com wrote:
Richi,
patch ping
Ok.
Thanks,
Richard.
also two more pieces of information
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
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but it is impossible to test it because (i
believe) that gcc no longer works if the host_bits_per_wide_int
On 11/26/2013 09:12 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch
On 11/26/2013 09:16 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 26, 2013 at 6:03 AM, pins...@gmail.com wrote:
On Nov 26, 2013, at 6:00 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
)
return NULL_TREE;
+ res = wi::mod_round (arg1, arg2, sign, overflow);
break;
case MIN_EXPR:
On 11/20/2013 06:31 PM, Kenneth Zadeck wrote:
On 11/13/2013 04:59 AM, Richard Biener wrote:
On Tue, Nov 12, 2013 at 5:43 PM, Kenneth Zadeck
zad...@naturalbridge.com
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 dje@gmail.com wrote:
On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump mikest...@comcast.net wrote:
Ok?
On 11/25/2013 06:04 AM, Richard Biener wrote:
On Sat, Nov 23, 2013 at 8:22 PM, 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.
fixed on the wide-int branch 205363.
On 11/23/2013 09:00 PM, Jason Merrill wrote:
On 11/23/2013 02:20 PM, Mike Stump wrote:
@@ -2605,8 +2606,7 @@ cp_tree_equal (tree t1, tree t2)
switch (code1)
{
case INTEGER_CST:
- return TREE_INT_CST_LOW (t1) == TREE_INT_CST_LOW (t2)
-
I replied to the wrong email when i sent the first version of this
emal. sorry.This was the comment that was addressed by this fix.
fixed on the wide-int branch 205363.
On 11/24/2013 08:43 AM, Jason Merrill wrote:
On 11/23/2013 09:55 PM, Kenneth Zadeck wrote:
On 11/23/2013 08:47 PM
On 11/25/2013 03: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 the mechanical
We did not do this kind of transformation for any port beyond the minimum of
having the port use wide-int rather than double-int. we did do a lot of this
in the common code, especially in the code that was just not correct for types
beyond 64 bits.
Our motivation was that this is already a
On 11/24/2013 05:47 AM, Uros Bizjak wrote:
On Sun, Nov 24, 2013 at 11:23 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
We did not do this kind of transformation for any port beyond the minimum of
having the port use wide-int rather than double-int. we did do a lot
On 11/24/2013 05:16 AM, N.M. Maclaren wrote:
On Nov 23 2013, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
s...@troutmask.apl.washington.edu 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 11/24/2013 05:50 AM, Tobias Burnus wrote:
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
fortran front end.
Nice clean
1 - 100 of 557 matches
Mail list logo
