Eric Botcazou writes:
>> This patch splits out a fairly common operation: that of narrowing a MEM
>> to a particular mode and adjusting the bit number accordingly.
>>
>> I've kept with "bit_field" rather than "bitfield" for consistency with
>> the callers, although we do have "bitfield" in "adjus
Original message at:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00013.html
Thanks in advance.
--
Eric Botcazou
> Would it be OK with a pointer, but keeping the interface the same?
> That's certainly fine by me.
Yes, a pointer would make things more legible here.
> That's one of the things I'm not sure about after the C++ conversion:
> I've noticed some references creep in, but when should we use reference
On Tue, Oct 30, 2012 at 03:56:08PM +0100, Richard Biener wrote:
> Ok, but the code could really really have some more comments - functions
> not fitting in my 80x24 terminal without seeing any comment what happens
> here are a maintainance nightmare.
Here is the updated patch I'm about to commit:
On Tue, Oct 30, 2012 at 01:14:40PM +0100, Marc Glisse wrote:
> On Tue, 30 Oct 2012, Marek Polacek wrote:
>
> >On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
> >>Hello,
> >>
> >>one more optimization that needed help for vectors, it crashed on
> >>(x >>do a x86-only one if needed).
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Jakub Jelinek
> Sent: Tuesday, October 30, 2012 1:57 AM
> To: g...@gcc.gnu.org
> Cc: gcc-patches@gcc.gnu.org
> Subject: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soo
On Mon, Oct 08, 2012 at 05:50:34PM +0200, Florian Weimer wrote:
> gcc/:
>
> 2012-10-08 Florian Weimer
>
> * init.c (build_new_1): Do not check for arithmetic overflow if
> inner array size is 1.
>
> gcc/testsuite/:
>
> 2012-10-08 Florian Weimer
>
> * g++.dg/init/new40.C
On Tue, 30 Oct 2012, Jan Hubicka wrote:
> Hi,
> this patch implements the second part of planned change - to determine loop
> bounds
> based by shortest path discovery. This allows to bound number of iterations
> on loops with bounds in statements that do not dominate the latch.
>
> I originall
On Tue, Oct 30, 2012 at 9:23 PM, Peter Bergner wrote:
> On Tue, 2012-10-30 at 20:37 +0100, Jakub Jelinek wrote:
>> On Tue, Oct 30, 2012 at 02:03:44PM -0500, Peter Bergner wrote:
>> > Ok, then I'll bootstrap and regtest your suggested change while we
>> > wait for richi to comment. I'm fine with w
On Tue, Oct 30, 2012 at 11:00 PM, Eric Botcazou wrote:
>> gcc/
>> * expmed.c (store_bit_field_1): Remove test for BLKmode values.
>
> This looks fine to me.
Btw, I consider Eric the best person to approve changes in this area.
Thus if there is any doubt all patches in this series are ok if
On Wed, Oct 31, 2012 at 12:57 AM, Xinliang David Li wrote:
> It will make the location info for the newly synthesized stmt more
> deterministic, I think.
Maybe, but it will increase the jumpiness in the debugger without actually
being accurate, no? For example if the partially redundant expressi
On Wed, Oct 31, 2012 at 9:16 AM, Eric Botcazou wrote:
>> Would it be OK with a pointer, but keeping the interface the same?
>> That's certainly fine by me.
>
> Yes, a pointer would make things more legible here.
>
>> That's one of the things I'm not sure about after the C++ conversion:
>> I've not
On Wed, Oct 31, 2012 at 9:24 AM, Jakub Jelinek wrote:
> On Tue, Oct 30, 2012 at 01:14:40PM +0100, Marc Glisse wrote:
>> On Tue, 30 Oct 2012, Marek Polacek wrote:
>>
>> >On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
>> >>Hello,
>> >>
>> >>one more optimization that needed help for ve
On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck
wrote:
> jakub,
>
> i am hoping to get the rest of my wide integer conversion posted by nov 5.
> I am under some adverse conditions here: hurricane sandy hit her pretty
> badly. my house is hooked up to a small generator, and no one has any power
>
On Tue, Oct 30, 2012 at 5:14 PM, Joern Rennecke
wrote:
> Quoting Richard Biener :
>
>> Apart from the iteration_threshold the hookization would be
>> straight-forward.
>> Now I cannot decipher from the patch what functional change it introduces
>> ;)
>
>
> The only change occurs if we reach an ite
Richard Biener writes:
> On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck
> wrote:
>> jakub,
>>
>> i am hoping to get the rest of my wide integer conversion posted by nov 5.
>> I am under some adverse conditions here: hurricane sandy hit her pretty
>> badly. my house is hooked up to a small gene
On Tue, Oct 30, 2012 at 6:27 PM, Dehao Chen wrote:
>> gcc/ChangeLog:
>> 2012-10-25 Dehao Chen
>>
>> * tree-eh.c (do_return_redirection): Set location for jump statement.
>> (do_goto_redirection): Likewise.
>> (frob_into_branch_around): Likewise.
>> (lower_try_fin
On Wed, Oct 31, 2012 at 11:00:26AM +0100, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 6:27 PM, Dehao Chen wrote:
> >> gcc/ChangeLog:
> >> 2012-10-25 Dehao Chen
> >>
> >> * tree-eh.c (do_return_redirection): Set location for jump
> >> statement.
> >> (do_goto_redirection): L
>
> visited is a poor name for a map ...
Hmm, visited_with_priority?
Thanks,
Honza
>
> Otherwise looks ok.
>
> Thanks,
> Richard.
>
> > +
> > + /* Perform shortest path discovery loop->header ... loop->latch.
> > +
> > + The "distance" is given by the smallest loop bound of basic block
>
On Wed, Oct 31, 2012 at 10:59 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck
>> wrote:
>>> jakub,
>>>
>>> i am hoping to get the rest of my wide integer conversion posted by nov 5.
>>> I am under some adverse conditions here: hurricane s
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> >
> > visited is a poor name for a map ...
> Hmm, visited_with_priority?
Just block_priority?
Richard.
> Thanks,
> Honza
> >
> > Otherwise looks ok.
> >
> > Thanks,
> > Richard.
> >
> > > +
> > > + /* Perform shortest path discovery loop->header ..
On Mon, Oct 29, 2012 at 6:56 PM, Jakub Jelinek wrote:
> Status
> ==
>
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have still patches for new features you'd
> like to see in GCC 4.8, please post them for review soon.
Reminds me of the stable
Richard Biener writes:
> On Tue, Oct 30, 2012 at 5:14 PM, Joern Rennecke
> wrote:
>> Quoting Richard Biener :
>>
>>> Apart from the iteration_threshold the hookization would be
>>> straight-forward.
>>> Now I cannot decipher from the patch what functional change it introduces
>>> ;)
>>
>>
>> The
On Fri, Jun 1, 2012 at 3:29 AM, Eric Botcazou wrote:
>> Well, it would rather be
>>
>> TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
>> && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
>>
>> but only in the !FLOAT_TYPE_P path.
>
> That works in all cases I think, see exis
On 10/30/2012 01:56, Jakub Jelinek wrote:
> Status
> ==
>
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have still patches for new features you'd
> like to see in GCC 4.8, please post them for review soon. Patches
> posted before the freeze, b
On Wed, Oct 31, 2012 at 11:22 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Oct 30, 2012 at 5:14 PM, Joern Rennecke
>> wrote:
>>> Quoting Richard Biener :
>>>
Apart from the iteration_threshold the hookization would be
straight-forward.
Now I cannot decipher fro
On Wed, Oct 31, 2012 at 06:25:45PM +0800, JonY wrote:
> On 10/30/2012 01:56, Jakub Jelinek wrote:
> > I'd like to close the stage 1 phase of GCC 4.8 development
> > on Monday, November 5th. If you have still patches for new features you'd
> > like to see in GCC 4.8, please post them for review soo
Hi,
this patch implements the logic to remove statements that are known to be
undefined and thus expected to not be executed after unrolling. It also
removes redundant exits that I originally tried to do at once, but it
does not fly, since the peeling confuse number_of_iterations_exit
and it no lo
Richard Biener writes:
> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
> wrote:
>>
>> On 10/25/2012 06:42 AM, Richard Biener wrote:
>>>
>>> On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
On Oct 24, 2012, at 2:43 AM, Richard Biener
wrote:
>
> On Tue, Oct 23, 2012 at
Hi,
I have just merged upstream gcc-4_7-branch into ARM/aarch64-4.7-branch, up
to r192902.
Thanks
Sofiane
On 31 October 2012 10:25, JonY wrote:
> On 10/30/2012 01:56, Jakub Jelinek wrote:
>> Status
>> ==
>>
>> I'd like to close the stage 1 phase of GCC 4.8 development
>> on Monday, November 5th. If you have still patches for new features you'd
>> like to see in GCC 4.8, please post them for review
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> Hi,
> this patch implements the logic to remove statements that are known to be
> undefined and thus expected to not be executed after unrolling. It also
> removes redundant exits that I originally tried to do at once, but it
> does not fly, since the pee
On 31 October 2012 11:01, Jonathan Wakely wrote:
> On 31 October 2012 10:25, JonY wrote:
>> On 10/30/2012 01:56, Jakub Jelinek wrote:
>>> Status
>>> ==
>>>
>>> I'd like to close the stage 1 phase of GCC 4.8 development
>>> on Monday, November 5th. If you have still patches for new features you
On 10/31/2012 19:12, Jonathan Wakely wrote:
> On 31 October 2012 11:01, Jonathan Wakely wrote:
>> On 31 October 2012 10:25, JonY wrote:
>>> On 10/30/2012 01:56, Jakub Jelinek wrote:
Status
==
I'd like to close the stage 1 phase of GCC 4.8 development
on Monday, November
On 10/31/2012 19:23, JonY wrote:
>
>> Why is the define commented out by the patch, not simply removed?
>> If it's not needed then it's not needed. We have subversion to track
>> change history, we don't need to leave dead code lying around with
>> comments explaining why it's dead.
>
> OK, I wil
On Wed, Oct 24, 2012 at 4:02 AM, Easwaran Raman wrote:
> On Tue, Oct 23, 2012 at 2:52 AM, Richard Biener
> wrote:
>> On Mon, Oct 22, 2012 at 8:31 PM, Easwaran Raman wrote:
>>> On Mon, Oct 22, 2012 at 12:59 AM, Richard Biener
>>> wrote:
On Fri, Oct 19, 2012 at 12:36 AM, Easwaran Raman wrot
Applied.
Thanks,
Paolo.
Quoting Richard Sandiford :
I should probably have piped up earlier, but I'm really not sure about it.
ADJUST_INSN_LENGTH as defined now is telling us a property of the target.
The patch instead ties the new hook directly into the shorten_branches
algorithm, which I think is a bad idea.
IMO, th
On Wed, Oct 31, 2012 at 8:20 AM, Sharad Singhai wrote:
> I am attaching an updated patch with comments inline.
>
> On Tue, Oct 30, 2012 at 9:04 AM, Xinliang David Li wrote:
>> On Tue, Oct 30, 2012 at 8:28 AM, Richard Biener
>> wrote:
>
>>> What I'd expect from that would be both vec.miss and vec
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 10/25/2012 06:42 AM, Richard Biener wrote:
On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
>
> On Oct 24, 2012, at 2:
Joern Rennecke writes:
> Quoting Richard Sandiford :
>> I should probably have piped up earlier, but I'm really not sure about it.
>> ADJUST_INSN_LENGTH as defined now is telling us a property of the target.
>> The patch instead ties the new hook directly into the shorten_branches
>> algorithm, wh
On 31 October 2012 11:23, JonY wrote:
> On 10/31/2012 19:12, Jonathan Wakely wrote:
>>
>> It looks like the workaround is in mingw not in GCC, so is it a
>> problem that it won't be possible to use GCC 4.8 with existing mingw
>> versions, or are users required to use a brand new mingw to use a new
> > Index: tree-ssa-loop-niter.c
> > ===
> > --- tree-ssa-loop-niter.c (revision 192989)
> > @@ -3505,15 +3737,11 @@ scev_probably_wraps_p (tree base, tree s
> >return true;
> > }
> >
> > -/* Frees the information on upper bou
Quoting Richard Sandiford :
I can't approve the whole thing of course, but I like the idea.
However...
Joern Rennecke writes:
+@deftypevr {Target Hook} bool TARGET_HAVE_CC0
+@deftypevrx {Target Hook} {bool} TARGET_AUTO_INC_DEC
+@deftypevrx {Target Hook} {bool} TARGET_STACK_REGS
+@deftypevrx {
Richard Biener writes:
> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
>>> wrote:
On 10/25/2012 06:42 AM, Richard Biener wrote:
>
> On Wed, Oct 24, 2012 at 7:23 PM, Mike Stump wrote:
Hi all,
libquadmath's math functions are based on (but not identical to) GLIBC's
sysdeps/ieee754/ldbl-128 functions. In the attached patch, I have ported
the bug fixes from GLIBC over to libquadmath. Hopefully, the port is
complete and correct.
I intent to commit the patch soon, unless there
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
>
> On 10/25/2012 06:42 AM, Richard Biener wr
Joern Rennecke writes:
> Quoting Richard Sandiford :
>
>> I can't approve the whole thing of course, but I like the idea.
>> However...
>>
>> Joern Rennecke writes:
>>> +@deftypevr {Target Hook} bool TARGET_HAVE_CC0
>>> +@deftypevrx {Target Hook} {bool} TARGET_AUTO_INC_DEC
>>> +@deftypevrx {Targe
On Wed, Oct 31, 2012 at 1:06 PM, Tobias Burnus wrote:
> Hi all,
>
> libquadmath's math functions are based on (but not identical to) GLIBC's
> sysdeps/ieee754/ldbl-128 functions.
Heh, last time I copied things from sysdeps/ieee754 into GCC rms objected
and I had to revert ... (libgccmath).
Richa
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > Index: tree-ssa-loop-niter.c
> > > ===
> > > --- tree-ssa-loop-niter.c (revision 192989)
> > > @@ -3505,15 +3737,11 @@ scev_probably_wraps_p (tree base, tree s
> > >return true;
> > >
Richard Biener writes:
> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
> wrote:
>>
>> On 10
>
> unroll you mean. Because unrolling mutates the CFG too much.
> Well - it was just a starting point, populating -Og with as little
> as possible and 100% profitable transforms (in both debug and speed
> metric). In late opts we only do (early opt queue is shared):
Well, and what about early
Hi,
this patch changes finite_loop_p to use max_loop_iterations. Long time ago I
made
finite_loop_p as rip-off from the max_loop_iterations skipping parts that are
not
exactly related to the number of iteration estimates. It went out of date
since then
completelly missing the bounds derived fr
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> >
> > unroll you mean. Because unrolling mutates the CFG too much.
> > Well - it was just a starting point, populating -Og with as little
> > as possible and 100% profitable transforms (in both debug and speed
> > metric). In late opts we only do (early
Quoting Richard Sandiford :
It's about describing complex interactions of length adjustments that
derive from branch shortening and length added for (un)alignment for
scheduling purposes. Expressed naively, these can lead to cycles.
But shorten_branches should be written to avoid cycles, and
On Wed, Oct 31, 2012 at 01:30:02PM +0100, Richard Biener wrote:
> On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > unroll you mean. Because unrolling mutates the CFG too much.
> > > Well - it was just a starting point, populating -Og with as little
> > > as possible and 100% profitable transforms (in
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> Hi,
> this patch changes finite_loop_p to use max_loop_iterations. Long time ago I
> made
> finite_loop_p as rip-off from the max_loop_iterations skipping parts that are
> not
> exactly related to the number of iteration estimates. It went out of date
On Wed, 31 Oct 2012, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 01:30:02PM +0100, Richard Biener wrote:
> > On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > > unroll you mean. Because unrolling mutates the CFG too much.
> > > > Well - it was just a starting point, populating -Og with as little
>
> Your change caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
Please check whether it worked before Richard's fix (r188009).
--
Eric Botcazou
On Wed, Oct 31, 2012 at 1:22 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Oct 25
On Wed, Oct 31, 2012 at 1:33 PM, Joern Rennecke
wrote:
> Quoting Richard Sandiford :
>
>>> It's about describing complex interactions of length adjustments that
>>> derive from branch shortening and length added for (un)alignment for
>>> scheduling purposes. Expressed naively, these can lead to c
On Fri, 2012-10-26 at 17:05 +0200, Jan Hubicka wrote:
> > Hi,
> >
> > On Tue, Oct 23, 2012 at 3:03 AM, Jan Hubicka wrote:
> > >> Ping.
> > >>
> > >>
> > >> On Wed, Oct 17, 2012 at 1:48 PM, Easwaran Raman
> > >> wrote:
> > >> > Hi,
> > >> > This patch fixes bugs introduced by my previous patch
On Wed, Oct 31, 2012 at 5:42 AM, Eric Botcazou wrote:
>> Your change caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
>
> Please check whether it worked before Richard's fix (r188009).
>
It failed with revision 188008.
--
H.J.
On 10/31/2012 20:01, Jonathan Wakely wrote:
> On 31 October 2012 11:23, JonY wrote:
>> On 10/31/2012 19:12, Jonathan Wakely wrote:
>>>
>>> It looks like the workaround is in mingw not in GCC, so is it a
>>> problem that it won't be possible to use GCC 4.8 with existing mingw
>>> versions, or are us
On Wed, 31 Oct 2012, Jakub Jelinek wrote:
On Tue, Oct 30, 2012 at 01:14:40PM +0100, Marc Glisse wrote:
On Tue, 30 Oct 2012, Marek Polacek wrote:
On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
Hello,
one more optimization that needed help for vectors, it crashed on
(x
Quoting Richard Biener :
Maybe we should split the thing then into a adjust_insn_length attribute
without the iteration parameter
Attributes don't get any parameter but the instruction, and don't apply
to delay slot SEQUENCEs.
On Wed, Oct 31, 2012 at 2:06 PM, Joern Rennecke
wrote:
> Quoting Richard Biener :
>
>> Maybe we should split the thing then into a adjust_insn_length attribute
>> without the iteration parameter
>
>
> Attributes don't get any parameter but the instruction, and don't apply
> to delay slot SEQUENCEs
On Tue, Oct 30, 2012 at 6:50 PM, Eric Botcazou wrote:
> This will hopefully fix the build failure reported by Diego. Apart from
> adding missing dependencies, this also removes redundant command lines.
>
> Tested on x86_64-suse-linux, applied on the mainline and 4.7 branch.
>
>
> 2012-10-30 Eric
Richard Biener writes:
>> But that means that wide_int has to model a P-bit operation as a
>> "normal" len*HOST_WIDE_INT operation and then fix up the result
>> after the fact, which seems unnecessarily convoluted.
>
> It does that right now. The operations are carried out in a loop
> over len HO
Richi,
Let me explain to you what a broken api is. I have spent the last week
screwing around with tree-vpn and as of last night i finally got it to
work. In tree-vpn, it is clear that double-int is the precise
definition of a broken api.
The tree-vpn uses an infinite-precision view of a
On 10/30/2012 07:44 PM, Paolo Carlini wrote:
straightforward fix. The below, which regtests fine, simply acts on any
MULT_EXPR as TYPE_SIZE, which I think should be fine, but, in case the
idea is basically Ok, we could also consider the more complex but more
sophisticated variably_modified_type_p
On Wed, 2012-10-31 at 10:12 +0100, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 9:23 PM, Peter Bergner wrote:
> > On Tue, 2012-10-30 at 20:37 +0100, Jakub Jelinek wrote:
> >> On Tue, Oct 30, 2012 at 02:03:44PM -0500, Peter Bergner wrote:
> >> > Ok, then I'll bootstrap and regtest your suggested
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
Richard Biener writes:
On Thu, Oct 25, 2012 at 12:55 PM, Kenneth Zadeck
wrote:
On 10/25/2012 06:42 A
On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>>> But that means that wide_int has to model a P-bit operation as a
>>> "normal" len*HOST_WIDE_INT operation and then fix up the result
>>> after the fact, which seems unnecessarily convoluted.
>>
>> It does that
Quoting Richard Biener :
On Wed, Oct 31, 2012 at 2:06 PM, Joern Rennecke
wrote:
Quoting Richard Biener :
Maybe we should split the thing then into a adjust_insn_length attribute
without the iteration parameter
Attributes don't get any parameter but the instruction, and don't apply
to dela
On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote:
> The tree-vpn uses an infinite-precision view of arithmetic. However,
> that infinite precision is implemented on top of a finite, CARVED IN
> STONE, base that is and will always be without a patch like this,
> 128 bits on an x86-64.
On Wed, Oct 31, 2012 at 08:53:31AM -0500, Peter Bergner wrote:
> Great. Jakub, were you going to commit your change or did you want me
> to do that?
I haven't tested it, you did, so please do that yourself. Thanks.
Jakub
Hello Alan,
maybe it is better to use a require effective target instead of the
{ target powerpc*-*-eabi* powerpc*-*-elf* powerpc*-*-linux* }
patterns scattered around in the testsuite? One problem with this is that test
cases for one of these will likely also work with powerpc*-*-rtems*. I
> > - FOR_EACH_VEC_ELT (edge, exits, i, ex)
> > + if (loop->any_upper_bound)
> > {
> > - if (!just_once_each_iteration_p (loop, ex->src))
> > - continue;
> > + if (dump_file && (dump_flags & TDF_DETAILS))
> > + fprintf (dump_file, "Found loop %i to be finite: upper bound is
>
jakub
my port has 256 bit integers. They are done by strapping together all
of the elements of a vector unit.
if one looks at where intel is going, they are doing exactly the same
thing.The difference is that they like to add the operations one at
a time rather than just do a clean imple
> On Wed, Oct 31, 2012 at 01:30:02PM +0100, Richard Biener wrote:
> > On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > > unroll you mean. Because unrolling mutates the CFG too much.
> > > > Well - it was just a starting point, populating -Og with as little
> > > > as possible and 100% profitable tran
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
>
> On 10/31/2012 08:11 AM, Richard Biener wrote:
>>
>> On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
>
> Richar
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > - FOR_EACH_VEC_ELT (edge, exits, i, ex)
> > > + if (loop->any_upper_bound)
> > > {
> > > - if (!just_once_each_iteration_p (loop, ex->src))
> > > - continue;
> > > + if (dump_file && (dump_flags & TDF_DETAILS))
> > > + fprintf (dump_fi
On Wed, 2012-10-31 at 14:55 +0100, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 08:53:31AM -0500, Peter Bergner wrote:
> > Great. Jakub, were you going to commit your change or did you want me
> > to do that?
>
> I haven't tested it, you did, so please do that yourself. Thanks.
I tested it on
On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > On Wed, Oct 31, 2012 at 01:30:02PM +0100, Richard Biener wrote:
> > > On Wed, 31 Oct 2012, Jan Hubicka wrote:
> > > > > unroll you mean. Because unrolling mutates the CFG too much.
> > > > > Well - it was just a starting point, populating -Og with as li
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
On Wed, Oct 31, 2012 at 3:18 PM, Kenneth Zadeck
wrote:
>
> On 10/31/2012 10:05 AM, Richard Biener wrote:
>>
>> On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
On 10/31/2012 09:54 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:30 PM, Richard Sandiford
wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecess
On 10/30/2012 05:49 PM, Sriraman Tallam wrote:
AFAIU, this should not be a problem. For duplicate declarations,
duplicate_decls should merge them and they should never be seen here.
Did I miss something?
With extern "C" functions you can have multiple declarations of the same
function in diffe
On 10/31/2012 10:24 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 3:18 PM, Kenneth Zadeck
wrote:
On 10/31/2012 10:05 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 2:54 PM, Kenneth Zadeck
wrote:
On 10/31/2012 08:11 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:05 PM, Richard S
On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote:
> if one looks at where intel is going, they are doing exactly the
> same thing.The difference is that they like to add the
> operations one at a time rather than just do a clean implementation
> like we did. Soon they will get t
Hi,
On 10/31/2012 02:50 PM, Jason Merrill wrote:
On 10/30/2012 07:44 PM, Paolo Carlini wrote:
straightforward fix. The below, which regtests fine, simply acts on any
MULT_EXPR as TYPE_SIZE, which I think should be fine, but, in case the
idea is basically Ok, we could also consider the more comp
On 10/31/2012 08:44 AM, Richard Biener wrote:
On Wed, Oct 31, 2012 at 1:22 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 1:05 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Oct 31, 2012 at 11:43 AM, Richard Sandiford
wrote:
Richard Biener wri
> It failed with revision 188008.
OK, thanks. So the testcase never compiled on the trunk (except for about 24
hours between 188009 & 188118) or did it compile before 188008 at some point?
--
Eric Botcazou
Committed as obvious.
2012-10-31 Joern Rennecke
* expr.c (can_move_by_pieces): Apply ATTRIBUTE_UNUSED to len.
Index: expr.c
===
--- expr.c (revision 193034)
+++ expr.c (working copy)
@@ -841,7 +841,7 @@ widest_i
On Wed, Oct 31, 2012 at 2:34 AM, Richard Biener
wrote:
> On Wed, Oct 31, 2012 at 12:57 AM, Xinliang David Li
> wrote:
>> It will make the location info for the newly synthesized stmt more
>> deterministic, I think.
>
> Maybe, but it will increase the jumpiness in the debugger without actually
>
> Yeah. But please also check gdb testsuite for this kind of patches.
This patch also passed gdb testsuite.
Thanks,
Dehao
>
> Jakub
I was not planning to do that mangling for 4.8.My primary
justification for getting it in publicly now is that there are a large
number of places where the current compiler (both at the tree and rtl
levels) do not do optimization of the value is larger than a single
hwi.My code generali
Joern Rennecke writes:
> Quoting Richard Sandiford :
>>> The length variation for the ARC are not alike: there are branches that
>>> are subject to branch shortening in the usual way, but they might
>>> shrink when other things shrink. When we are iterating starting at
>>> minimal length and incr
On 10/31/2012 09:30 AM, Richard Sandiford wrote:
Richard Biener writes:
But that means that wide_int has to model a P-bit operation as a
"normal" len*HOST_WIDE_INT operation and then fix up the result
after the fact, which seems unnecessarily convoluted.
It does that right now. The operation
1 - 100 of 160 matches
Mail list logo
