On 09/02/2013 05:35 AM, Richard Biener wrote:
On Mon, 2 Sep 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
There is no place for exactly two HWIs in the machine independent parts
of the compiler,
I totally agree. In fact I was taking that so much for granted
My main discomfort is the double-int part. At this point in time the
only usage of double-int left on the branch is because the fixed ints
use it as their underlying representation. I think that rather than
doing a lot of work to accommodate this, it would be better to just
change the fixed
richi,
on further thought, this is going to be a huge task. The problem is at
the edges. right now we share the rep of the array with the tree-csts
and rtl (though the rtl sharing may go away to support canonization).
So if the hwi rep inside of wide int changes then we will have to
On 08/29/2013 04:42 AM, Richard Biener wrote:
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have
On 08/28/2013 05:08 AM, Richard Biener wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
Fixed
FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
on
mips64-unknown-linux-gnu
Index: gcc/tree.c
===
--- gcc/tree.c (revision 202088)
+++ gcc/tree.c (working copy)
@@ -8531,11 +8531,11 @@ bool
On 08/28/2013 03:45 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
inline bool
On 08/28/2013 03:50 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that
On 08/28/2013 12:45 PM, Mike Stump wrote:
On Aug 28, 2013, at 5:48 AM, Richard Biener rguent...@suse.de wrote:
Only if the precision is HOST_BITS_PER_WIDE_INT. If the precision
is HOST_BITS_PER_WIDE_INT then both are { -1U }.
That wasn't my understanding on how things work.
You are thinking
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
kenny
Index: gcc/fold-const.c
===
---
you are about an hour behind in reading your email. I had just
committed a patch that is very close to this.
On 08/27/2013 02:31 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
Removed the redundant implementations of several comparison function by
just forwarding the oo version to the static version. Added static
versions of cmp, cmpu and cmps.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 201985)
+++ gcc/wide-int.h (working copy)
@@ -1650,7 +1650,7 @@ wide_int_ro::fits_shwi_p () const
inline bool
On 08/25/2013 02:42 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision
cleaned up code to get around tree-vrp issue. added some code that
richard is going to play with to see how hard it would be to clean up
rtl constants.
kenny
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 201968)
+++
On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision) to those where primitive types like int are
used as template arguments to operators, and require a
On 08/24/2013 02:16 PM, Florian Weimer wrote:
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor
fixed with the enclosed patch.
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
/* Return true if THIS is negative based on the interpretation of SGN.
For UNSIGNED, this is always false. This is correct even if
precision is 0. */
inline bool
wide_int::neg_p (signop sgn) const
It
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap
cleaned up version of convert_modes that handles all constants in a
uniform manner.
This is clean on x86-64. Will test on other platforms tomorrow.
kenny
Index: gcc/expr.c
===
--- gcc/expr.c(revision 201884)
+++ gcc/expr.c
Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 201884)
+++ gcc/optabs.c(working copy)
@@ -867,7 +867,8 @@ expand_subword_shift (enum machine_mode
outof_input, const1_rtx, 0, unsignedp, methods);
Richi and everyone else who may be interested,
Congrats on your first child. They are a lot of fun, but are very
high maintenence.
Today we put up the wide-int branch for all to see and play with. See
svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int
At this point, we have completed testing it
if (TREE_CODE (inner) == RSHIFT_EXPR
TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST
TREE_INT_CST_HIGH (TREE_OPERAND (inner, 1)) == 0
bitnum TYPE_PRECISION (type)
0 compare_tree_int (TREE_OPERAND (inner, 1),
bitnum - TYPE_PRECISION (type)))
Assuming the patch has been tested on a public port, it is ok for commit.
kenny
On 05/10/2013 06:52 PM, Mike Stump wrote:
On May 10, 2013, at 3:29 PM, Steven Bosscher stevenb@gmail.com wrote:
Your web.c patch looks correct to me, but I can't approve it.
Thanks. Now that you point out the
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Bienerrichard.guent
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/24/2013 11:13 AM, Richard Biener
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/24/2013 09:36 AM, Richard
On 05/03/2013 08:40 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:31 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck zad...@naturalbridge.com
wrote:
On 05/03/2013 07:34 AM, Richard Biener
On 05/03/2013 08:53 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:37 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
See e.g. the hoops that cselib has to jump through:
/* We need to pass down the mode of constants through the
On 05/03/2013 09:02 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent
Richi,
I also think that it is a digression to have this discussion about
rtl.The root problem is really that Mike, Richard, and myself do not
believe that infinite precision math is the proper way to do math for
the majority of the compiler. Most of the compiler, at both the rtl
and
The only changes here were account for the changes to the wide-int api.
On 04/16/2013 04:24 PM, Kenneth Zadeck wrote:
Richard, this is the first of the tree level patches so that you can
see how the wide-int changes will effect the tree level. This patch
converts builtins.c so that it does
On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONST_DOUBLE paths to do an explicit
On 04/24/2013 10:42 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
I suppose the above should use immed_double_int_const (v, mode), too,
In practice it doesn't matter, because...
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Bienerrichard.guent...@gmail.com writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
In other words, one of
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT the precision, the value has been
+ compressed. The values of the elements of the vector greater than
+ LEN - 1. are all equal to the highest order bit
richard,
i pushed send rather than save, just ignore the last email i sent
sorry.
On 04/22/2013 01:59 PM, Kenneth Zadeck wrote:
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT the precision
On 04/22/2013 08:20 AM, Richard Biener wrote:
That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.
yeh, now sandiford is back from vacation so there are two of us to beat
on
Richard,
i pulled these two frags out of your comments because i wanted to get
some input from you on it while i addressed the other issues you raised.
+ enum SignOp {
+/* Many of the math functions produce different results depending
+ on if they are SIGNED or UNSIGNED. In
to support this.
The idea is that each pass will be converted, 1 pass per patch in this
way.Once everything does not depend on the internals of tree-cst as
they do now, then tree-cst will be converted to have an array inside of
it rather than just two hwis.
Kenny
2012-04-16 Kenneth Zadeck zad
On 04/10/2013 12:02 PM, Mike Stump wrote:
On Apr 10, 2013, at 12:38 AM, Richard Biener richard.guent...@gmail.com wrote:
Yeah, I think we want to test ~(T)0(T)0 here.
Thanks Lawrence, in the next version of the patch, you will discover this at
the bottom if you look hard. :-)
actually
On 04/08/2013 06:46 AM, Richard Biener wrote:
On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from
On 04/08/2013 04:56 AM, Florian Weimer wrote:
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is
division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
What do you mean when you say constant
On 04/08/2013 09:03 AM, Robert Dewar wrote:
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an
On 04/08/2013 09:52 AM, Robert Dewar wrote:
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always
On 04/08/2013 10:12 AM, Robert Dewar wrote:
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
In some sense you have to think in terms of three worlds:
1) what you call compile-time static expressions is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time static expressions because that is what the
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar de...@adacore.com wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from the context. I would like to make the
case for my position here, in a separate thread, because the other
thread is just getting
these templates is simpler than not
having the templates.
Kenny
On 04/02/2013 11:04 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number of the changes requested by Richi. It
does not contain any of the changes
yes, i had caught that when i merged it in with the patches that used
it, is it ok aside from that?
kenny
On 04/03/2013 05:32 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
this time for sure.
Almost ...
diff --git a/gcc/hwint.c b/gcc
necessarily
be { 0, (unsigned HOST_WIDE_INT)-1 }, representation of -1 in any
precision would be { -1 }.
That was my proposal. Now, can you please properly specify yours?
Thanks,
Richard.
On 04/02/2013 11:04 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad
On 04/03/2013 09:53 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over
committed as revision 197456
kenny
On 04/03/2013 08:05 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
yes, i had caught that when i merged it in with the patches that used it, is
it ok aside from that?
Yes.
Thanks,
Richard.
kenny
Richard,
did everything that you asked here. bootstrapped and regtested on
x86-64. ok to commit?
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except
CONST_INT
sharing the rep for several different types and that just did not work
unless you are willing to do substantial cleanups.
On 04/02/2013 11:04 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number
this time for sure.
kenny
On 04/02/2013 10:54 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
that i move them.
ok to commit, or do you have a suggested resolution to the assert issue?
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments
committed as revision 197198
kenny
On 03/27/2013 10:19 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:37 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
the original patch 3 was accepted and committed. These were subsequent
comments. This could likely be just checked in the next
committed as revision 197200.
kenny
On 03/27/2013 11:07 AM, Richard Biener wrote:
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote
, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
(HOST_BITS_PER_WIDE_INT - 1));
I think this should
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth
looks ok, not my call as to the as to the appropriate for stage 4.
On 02/27/2013 11:01 AM, Jakub Jelinek wrote:
Hi!
We can leak mw_hardregs memory in some cases.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth Zadeck wrote:
This patch adds machinery to genmodes.c so that largest possible sizes
of various data structures can be determined
, x);
2013-2-26 Kenneth Zadeck zad...@naturalbridge.com
* combine.c (try_combine): Removed useless assert.
* cselib.c (rtx_equal_for_cselib_1): Removed unnecessary parens.
this looks good to me. does your patch also address the vec_concat
issue that marc raised?
On 01/26/2013 09:59 PM, Hans-Peter Nilsson wrote:
From: Kenneth Zadeck zad...@naturalbridge.com
Date: Sat, 26 Jan 2013 16:19:40 +0100
the definition of vec_duplicate in section 10.12 seems to restrictive
the definition of vec_duplicate in section 10.12 seems to restrictive.
i have seen examples where the small vector is really a scalar. Should
the doc be small vector or scalar?
kenny
if i had to guess what was going on here, and since i do not have the
example or even know the platform, i am just guessing, i would say that
at some earlier pass, the sub expression in the regnote and the second
set in the parallel were the same expression and that someone changed
the second
you need to talk to someone with a higher rtl rating than myself. sorry.
On 12/20/2012 08:41 AM, Paulo Matos wrote:
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Kenneth Zadeck
Sent: 20 December 2012 12:46
To: David Edelsohn; GCC Development
On 12/01/2012 04:28 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
2) The patch does not work for rtxes at all. Rtxes have to copied.
Trees could be pointer copied.
The problem is that CONST_INTs are not canonized in a way that wide-ints
are or that trees could
i think that this is really a mistake. you are one of the best at this
part of the compiler.
kenny
Richi
this patch is our attempt to implement the storage classes for wide int
as you suggested. The patch currently does not work for reasons that
will be mentioned below, but we stopped work on it because it is clear
that this is a terrible idea.
1) Having more than one storage class is
in time.
kenny
On 11/27/2012 05:03 AM, Richard Biener wrote:
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
I spent a good part of the afternoon talking to Mike about this. He is on
the c++ standards committee and is a much more seasoned c++ programmer
in time.
kenny
On 11/27/2012 05:03 AM, Richard Biener wrote:
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
I spent a good part of the afternoon talking to Mike about this. He is on
the c++ standards committee and is a much more seasoned c++ programmer
On 11/26/2012 10:03 AM, Richard Biener wrote:
On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 11/04/2012 11:54 AM, Richard Biener wrote:
On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad
of these patches is to solve problems that
exist in the current compiler that we have papered over for years. If
someone needs wide-ints in some way that is not foreseen then they can
change it.
kenny
On 11/26/2012 11:30 AM, Richard Biener wrote:
On Mon, Nov 26, 2012 at 5:03 PM, Kenneth Zadeck
zad
On 11/26/2012 10:03 AM, Richard Biener wrote:
On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 11/04/2012 11:54 AM, Richard Biener wrote:
On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad
of these patches is to solve problems that
exist in the current compiler that we have papered over for years. If
someone needs wide-ints in some way that is not foreseen then they can
change it.
kenny
On 11/26/2012 11:30 AM, Richard Biener wrote:
On Mon, Nov 26, 2012 at 5:03 PM, Kenneth Zadeck
zad
This patch is an updated version of my patch 3 with all of richard
sandiford's comments resolved.
Richi had approved it before he went on vacation.
Committed as revision 193360.
Kenny
On 10/08/2012 03:42 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
diff
Joseph,
Here is a revised patch with the change you asked for. There have been
no other comments. May I commit it?
Kenny
On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
+# define HOST_HALF_WIDE_INT_PRINT h
This may cause problems on hosts
I have added the proper doc. OK to commit?
Kenny
On 10/08/2012 05:06 AM, Richard Guenther wrote:
On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch adds machinery to genmodes.c so that largest possible sizes of
various data structures can
On 11/04/2012 11:54 AM, Richard Biener wrote:
On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level
Jakub and Richi,
At this point I have decided to that i am not going to get the rest of
the wide-int patches into a stable enough form for this round. The
combination of still living without power at my house and some issues
that i hit with the front ends has made it impossible to get this
i have been trying to change the representation of INT_CSTs so that they
do not carry around the limitation that they can only represent numbers
as large as 2 host_wide_ints (HWI). I have chosen a variable length
implementation that uses an array of HWIs that is just large enough to
hold the
On 11/05/2012 01:08 PM, Ian Lance Taylor wrote:
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
The question is why is having a case label of 256 on a unsigned char switch
legal?
Are you asking why it is valid in the C language? Or are you asking
why
On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
This switch to doing math within the precision causes many test cases to
behave differently. However, I want to know if differently means
incorrectly or I have fixed problems that we have just decided
On 11/04/2012 11:54 AM, Richard Biener wrote:
On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level
Jakub and Richi,
At this point I have decided to that i am not going to get the rest of
the wide-int patches into a stable enough form for this round. The
combination of still living without power at my house and some issues
that i hit with the front ends has made it impossible to get this
us to write the same code over and over again.
kenny
On 10/31/2012 02:19 PM, Kenneth Zadeck wrote:
Jakub,
it is hard from all of the threads to actually distill what the real
issues are here. So let me start from a clean slate and state them
simply.
Richi has three primary objections
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI
us to write the same code over and over again.
kenny
On 10/31/2012 02:19 PM, Kenneth Zadeck wrote:
Jakub,
it is hard from all of the threads to actually distill what the real
issues are here. So let me start from a clean slate and state them
simply.
Richi has three primary objections
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI
201 - 300 of 557 matches
Mail list logo
