2015-09-01 Kenneth Zadeck
* 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)
+++ gcc/testsuite/gcc.c-torture
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
o:gcc-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
> On Feb 18, 2015, at 3:23 AM, Joseph Myers 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
>> ex
> On Feb 17, 2015, at 6:01 PM, Joseph Myers 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
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 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
thing like 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
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
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 that this
is the opposite of
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
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
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 the
On 12/19/2014 06:26 AM, Richard Biener wrote:
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wrote:
2014-12-19 3:51 GMT+00:00 Bin.Cheng :
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
wrote:
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On 17/12/14 15:54, Richard Biener wr
2014-05-09 Kenneth Zadeck
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 (revision 210253)
+++ gcc/fold
everyone who has a private port will hate you forever. note that i
have 2 of them.
On 05/08/2014 02:31 PM, Richard Sandiford wrote:
"Joseph S. Myers" writes:
On Thu, 8 May 2014, Ramana Radhakrishnan wrote:
Ramana Radhakrishnan
* wide-int.cc (UTItype): Define.
(UDWtype)
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 some
please hold off on committing patches for the next couple of hours as we
have a very large merge to do.
thanks.
kenny
Then with a fixed comment, this patch is fine.
kenny
On 05/03/2014 02:59 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
The doc at wide-int.h:136 needs work.The doc currently says that the
precision and length are always greater than 0. This is now not
correct. It also says
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
this is fine.
On 05/02/2014 03:22 PM, Richard Sandiford wrote:
divmod_internal didn't handle unsigned division in which the inputs
have implicit all-one upper bits. There were two problems:
- wi_unpack should extend implicit 1s to index blocks_needed - 1
(possibly with a zext_hwi on the las
These are fine.
On 05/02/2014 03:20 PM, Richard Sandiford wrote:
This patch adds some assertions against sext (.., 0) and zext (..., 0).
The former is undefined at the sext_hwi level and the latter is disallowed
for consistency with the former.
Also, set_bit (rightly IMO) can't handle bit >= pr
On 04/28/2014 12:25 PM, Mike Stump wrote:
On Apr 28, 2014, at 2:36 AM, Richard Sandiford
wrote:
Ping. FWIW this is the last patch I have lined up before the merge.
I repeated the asm comparison test I did a few months ago on one target
per config/ architecture and there were no unexpected cha
ok to commit.
kenny
On 04/28/2014 11:42 AM, Richard Sandiford wrote:
Kyrill Tkachov 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 were as bogus
as claimed.
this is fine.
kenny
On 04/25/2014 09:44 AM, Richard Sandiford wrote:
We should write back the sign-extended value.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 20
i am sorry, i missed the fact that the loop counts up but you were
reversing the order in the indexes.
kenny
On 04/26/2014 04:26 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
don't you think that it would be easier to understand the number if you
printed it largest index first,
approved
On 04/25/2014 09:40 AM, Richard Sandiford wrote:
Very minor, but since shifted_mask copes with out-of-range widths,
I think mask should too.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
approved.
On 04/25/2014 09:39 AM, Richard Sandiford wrote:
shifted_mask would mishandle cases where the start bit is in the middle
of a HWI and the end bit is in a different HWI. The "000111000" case
needs to check that the start and end are in the same block.
In the changed lines, "shift" is t
don't you think that it would be easier to understand the number if you
printed it largest index first, as in the routines in wide-int-print.cc?
kenny
On 04/25/2014 09:58 AM, Richard Sandiford wrote:
This patch adds a dump () method so that it's easier to read the
contents of the various wide-i
richard,
I think that this patch is fine as is.but in looking at the
surrounding code, i saw something that appears to be somewhat troubling.
I am worried about the two asserts. Given that we now require that
some users write code similar to the code in tree-vrp.c:2628, it seems
that t
i see nothing in this patch that requires a review.
On 04/25/2014 09:35 AM, Richard Sandiford wrote:
This series of patches is from a read-through of wide-int.h and wide-int.cc.
(The series from earlier in the week was from a diff of preexisting files.)
This first patch fixes some comments, typo
This is fine with me.
kenny
On 04/24/2014 10:34 AM, Richard Sandiford wrote:
For signed min / -1 we set the overflow flag (good) but also returned a
quotient of 0. It should be 0x80...0 instead. Since that's also the
value of the original dividend, we can just copy the representation over.
T
On 04/23/2014 10:36 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
wrote:
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
wrote:
Kyrill Tkachov writes:
Ping.
http
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
wrote:
Kyrill Tkachov writes:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00769.html
Any ideas? I recall chatter on IRC that we want to mer
On 04/22/2014 04:02 PM, Richard Sandiford wrote:
Looks like a few uses of the old idiom:
BITS_PER_UNIT == 8 ? 3 : exact_log2 (BITS_PER_UNIT)
I do not think that these crept in as much as they were never squished out.
have crept in. This patch replaces them with LOG2_BITS_PER_UNIT.
Test
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 repl
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 u
On 01/02/2014 05:26 PM, Eric Botcazou wrote:
So, I'd like to ping the original patch and Kenny's patch to resolve the
issues you found. If you have any other concerns or thoughts, let us
know.
Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
case of expand_expr_real_1
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 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 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/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/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
+ 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/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
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 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
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
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
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
>>>
On 12/11/2013 08:42 PM, DJ Delorie wrote:
The m32c part is OK.
thanks for the fast reply.
kenny
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/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 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: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
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/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/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 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
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 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_
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/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 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 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
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 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
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
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
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
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
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
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
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
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 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.
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
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
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
(arg1, arg2, sign, &overflow);
- if (overflow)
+ if (arg2 == 0)
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 Biene
On 11/26/2013 09:16 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu wrote:
On Tue, Nov 26, 2013 at 6:03 AM, wrote:
On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
wrote:
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw
On 11/26/2013 09:12 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
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 below would be correct, but
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 i
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 change
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
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)
-
On 11/25/2013 06:04 AM, Richard Biener wrote:
On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual port and
front end maintainers can review their parts without have to go through the
entire patch.This patch covers the
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/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 up.
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
wrote:
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the
individual port and front end maint
On 11/24/2013 05:47 AM, Uros Bizjak wrote:
On Sun, Nov 24, 2013 at 11:23 AM, Kenneth Zadeck
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 of this
in the common code, especially in
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 hu
On 11/23/2013 04:36 PM, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 11:19 AM, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual port and
front end maintainers can review their parts without have to go through the
entire patch.This patch covers the
On 11/23/2013 08:19 PM, Joern Rennecke wrote:
On 23 November 2013 19:19, 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 arc po
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
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,
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
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
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
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
1 - 100 of 350 matches
Mail list logo
