On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote:
> On 10/08/2012 05:14 PM, Steven Bosscher wrote:
>>
>> On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov
>> wrote:
>>
>>> So I checked it on big file with > hundred functionson Intel machine and
>>> got
>>>
>>> before a part of the patch imp
On Mon, Oct 8, 2012 at 10:05 PM, Tobias Burnus wrote:
> Some more issues found by Coverity scanner.
>
> lto-cgraph.c: The code seems to be unused, besides, it's a zero-trip loop as
> parm_num is set to 0 and then checked non nonzeroness.
>
> lto-opts: The check whether first_p is non NULL is alway
On Mon, Oct 8, 2012 at 9:55 PM, Richard Sandiford
wrote:
> Robert Dewar writes:
>> On 10/8/2012 11:01 AM, Nathan Froyd wrote:
>>> - Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd
On Mon, Oct 8, 2012 at 5:01 PM, Nathan Froyd wrote:
> - Original Message -
>> Btw, as for Richards idea of conditionally placing the length field
>> in
>> rtx_def looks like overkill to me. These days we'd merely want to
>> optimize for 64bit hosts, thus unconditionally adding a 32 bit
>>
On Mon, Oct 8, 2012 at 2:39 PM, Tobias Burnus wrote:
> lto_obj_file_open allocates:
> lo = XCNEW (struct lto_simple_object);
> However, the data is never freed - neither explicitly nor in
> lto_obj_file_close.
>
> In the attached patch, I free the memory now after the call to
> lto_obj_file_clos
On Mon, Oct 8, 2012 at 2:32 PM, Richard Guenther
wrote:
> On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou wrote:
>> Hi,
>>
>> we recently noticed that, even at -O3, the compiler doesn't figure out that
>> the following loop is dumb:
>>
>> #define SIZ
On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou wrote:
> Hi,
>
> we recently noticed that, even at -O3, the compiler doesn't figure out that
> the following loop is dumb:
>
> #define SIZE 64
>
> int foo (int v[])
> {
> int r;
>
> for (i = 0; i < SIZE; i++)
> r = v[i];
>
> return r;
> }
>
On Mon, Oct 8, 2012 at 1:36 PM, Kenneth Zadeck wrote:
> yes, my bad. here it is with the patches.
Just for the record, ok!
Thanks,
Richard.
> On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
>>
>> This is the third patch in the series of patches to fix constant math.
>> this one changes some pre
This fixes PR54825, properly FRE/PRE vector BIT_FIELD_REFs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther
PR tree-optimization/54825
* tree-ssa-sccvn.c (vn_nary_length_from_stmt): Handle BIT_FIELD_REF
This replaces my_rev_post_order_compute in PRE by the already
existing inverted_post_order_compute, with the necessary adjustments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther
* tree-ssa-pre.c (postorder_num): New global
heck -k" passes with x86_64-unknown-linux-gnu.
I presume also bootstrapped.
Ok.
Thanks,
Richard.
> Regards,
> Venkat.
>
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Thursday, October 04, 2012 6:26 PM
> To: Kumar, Venkata
On Mon, Oct 8, 2012 at 12:01 PM, Jan Hubicka wrote:
>> On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka wrote:
>> >> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote:
>> >> > Attached is the updated patch. Yes, if we add a VRP pass before
>> >> > profile pass, this patch would be unnecessary. Should
On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka wrote:
> Hi,
> I benchmarked the patch moving loop header copying and it is quite noticeable
> win.
>
> Some testsuite updating is needed. In many cases it is just because the
> optimizations are now happening earlier.
> There are however few testusite
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>>> VEC_COND_EXPR is more complicated. We could for instance require that it
>>> takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
>>> thin
On Mon, Oct 8, 2012 at 11:18 AM, Jan Hubicka wrote:
>> On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka wrote:
>> >> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote:
>> >> > Hi,
>> >> > I added a santy check that after fixup all types that lost in the
>> >> > merging are
>> >> > really dead. And
On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka wrote:
>> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote:
>> > Attached is the updated patch. Yes, if we add a VRP pass before
>> > profile pass, this patch would be unnecessary. Should we add a VRP
>> > pass?
>>
>> No, we don't want VRP in early opt
On Sun, Oct 7, 2012 at 4:58 PM, Kenneth Zadeck wrote:
>
> On 10/07/2012 09:19 AM, Richard Guenther wrote:
>>>
>>> >In fact, you could argue that the tree level did it wrong (not that i am
>>> >suggesting to change this). But it makes me think what was g
On Sun, Oct 7, 2012 at 12:44 PM, Tom de Vries wrote:
> Richard,
>
> attached patch checks that unlinked uses do not contain ssa-names when
> renaming.
>
> This assert triggers when compiling (without the fix) the PR54735 example.
>
> AFAIU, it was due to chance that we caught the PR54735 bug by h
On Sat, Oct 6, 2012 at 5:55 PM, Kenneth Zadeck wrote:
> This is the third patch in the series of patches to fix constant math.
> this one changes some predicates at the rtl level to use the new predicate
> CONST_SCALAR_INT_P.
> I did not include a few that were tightly intertwined with other chang
On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
wrote:
> This patch adds machinery to genmodes.c so that largest possible sizes of
> various data structures can be determined at gcc build time. These
> functions create 3 symbols that are available in insn-modes.h:
> MAX_BITSIZE_MODE_INT - the bit
On Fri, Oct 5, 2012 at 5:01 PM, Marc Glisse wrote:
> [I am still a little confused, sorry for the long email...]
>
>
> On Tue, 2 Oct 2012, Richard Guenther wrote:
>
>>>>> + if (TREE_CODE (op0) == VECTOR_CST && TREE_CODE (op1) == VECTOR_CST)
>>>>
On Fri, 5 Oct 2012, Steven Bosscher wrote:
> On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther wrote:
> > If you can figure out a better name for the function we should
> > probably move it to cfganal.c
>
> It looks like my previous e-mail about this appears to have gone go
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote:
> Attached is the updated patch. Yes, if we add a VRP pass before
> profile pass, this patch would be unnecessary. Should we add a VRP
> pass?
No, we don't want VRP in early optimizations.
Richard.
> Thanks,
> Dehao
>
> On Sat, Oct 6, 2012 at 9:
On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher wrote:
> On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
>> The following patch speeds LRA up more on PR54146. Below times for
>> compilation of the test on gcc17.fsffrance.org (an AMD machine):
>>
>> Before:
>> real=1214.71 user=1192.05 sy
On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely wrote:
> On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
>> On 7 October 2012 22:13, Jonathan Wakely wrote:
>>>
>>> On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
wrote:
>
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka wrote:
>> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote:
>> > Hi,
>> > I added a santy check that after fixup all types that lost in the merging
>> > are
>> > really dead. And it turns out we have some zombies around.
>> >
>> > INTEGER_CST needs s
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote:
> Hi,
> I added a santy check that after fixup all types that lost in the merging are
> really dead. And it turns out we have some zombies around.
>
> INTEGER_CST needs special care because it is special cased by the streamer.
> We also
> do no
On Sun, Oct 7, 2012 at 3:11 PM, Kenneth Zadeck wrote:
>
> On 10/07/2012 08:47 AM, Richard Guenther wrote:
>>>>
>>>> len seems redundant unless you want to optimize encoding.
>>>> >>len == (precision + HOST_BITS_PER_WIDE_INT - 1) /
>>>&g
On Fri, Oct 5, 2012 at 6:34 PM, Kenneth Zadeck wrote:
> richard s,
> there are two comments that i deferred to you. that have the word richard
> in them,
>
> richi,
> thank, i will start doing this now.
>
> kenny
>
> On 10/05/2012 09:49 AM, Richard Guenther wrote:
On Fri, Oct 5, 2012 at 4:14 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Fri, Oct 5, 2012 at 3:18 PM, Richard Sandiford
>> wrote:
>>> Richard Sandiford writes:
>>>>>>> How is CONST_WIDE_INT variable size?
>>>>>>
On Fri, Oct 5, 2012 at 2:49 PM, Jakub Jelinek wrote:
> On Fri, Oct 05, 2012 at 02:20:13PM +0200, Richard Guenther wrote:
>> The following could use a comment on what you are doing ...
>
> Will add something.
>
>> > + if (args_to_skip)
>> > +for (parm = D
On Fri, Oct 5, 2012 at 3:18 PM, Richard Sandiford
wrote:
> Richard Sandiford writes:
> How is CONST_WIDE_INT variable size?
It's just the usual trailing variable-length array thing.
>>>
>>> Good. Do you get rid of CONST_DOUBLE (for integers) at the same time?
>>
>> Yeah. I initial
On Fri, Oct 5, 2012 at 2:39 PM, Richard Guenther
wrote:
>
> Ok, I see where you are going. Let me look at the patch again.
* The introduction and use of CONST_SCALAR_INT_P could be split out
(obvious and good)
* DEF_RTL_EXPR(CONST_WIDE_INT, "const_wide_int", "",
On Fri, Oct 5, 2012 at 2:26 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Fri, Oct 5, 2012 at 1:24 PM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
>>>> The issue is that unlike RTL where we "construct" double-ints fr
On Wed, 3 Oct 2012, Jakub Jelinek wrote:
> On Tue, Sep 11, 2012 at 03:59:56PM +0200, Jakub Jelinek wrote:
> > As discussed in the PR, right now we do a very bad job for debug info
> > of partially inlined functions (both when they are kept only partially
> > inlined, or when partial inlining is pe
On Thu, 4 Oct 2012, Jakub Jelinek wrote:
> On Thu, Oct 04, 2012 at 09:42:59AM +0200, Richard Guenther wrote:
> > This looks like the wrong place to fix things to me ... either we can
> > fix this at the point we create the VAR_DECLs for the optimized away
> > PARM_DECLs (or
This fixes PR54811 for me - still Ada LTO bootstrap fails for me
with cgraph verification ICEs.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-05 Richard Guenther
PR middle-end/54811
* tree-ssa-live.c (clear_unused_block_pointer_1): Look
On Fri, Oct 5, 2012 at 1:24 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Fri, Oct 5, 2012 at 11:55 AM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
>>>>> As far as the wide_ints recording a mode or precision goes: we're i
On Fri, Oct 5, 2012 at 12:50 PM, Nathan Froyd wrote:
> - Original Message -
>> I see all these patches with mixed feeling - it puts breaks on all
>> developers
>> because they need to learn the new interface which does not bring any
>> immediate benefit. So I think _your_ development time
On Fri, Oct 5, 2012 at 12:07 PM, Iain Buclaw wrote:
> On 5 October 2012 01:06, Joseph S. Myers wrote:
>> On Thu, 4 Oct 2012, Iain Buclaw wrote:
>>
>>> The only patches to gcc proper are documentation-related and adding
>>> the D frontend / libphobos to configure and make files. I would have
>>>
On Fri, Oct 5, 2012 at 11:55 AM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> As far as the wide_ints recording a mode or precision goes: we're in
>>> the "lucky" position of having tried both options. Trees record the
>>> type (an
On Fri, Oct 5, 2012 at 11:26 AM, Richard Guenther
wrote:
> Look at RTL users of the double-int routines and provide wrappers
> that take RTXen as inputs. Enforce that all CONSTs have a mode.
Which would, btw, allow to "merge" CONST_INT, CONST_DOUBLE
and CONST_WIDE by making
On Thu, Oct 4, 2012 at 9:27 PM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>> On 10/04/2012 12:58 PM, Richard Guenther wrote:
>>> On Thu, Oct 4, 2012 at 3:55 PM, Kenneth Zadeck
>>> wrote:
>>>> Let me talk about the mode here first.
>>&g
On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo wrote:
> On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl wrote:
>
>> So, Jan Hubicka requested and approved the current spelling.
>> What now?
>
> I don't think we should hold this up. The names Jan requested seem
> reasonable enough. We seem to be r
On Thu, Oct 4, 2012 at 7:38 PM, Jason Merrill wrote:
> Both C++11 and OpenMP specify that thread_local/threadprivate variables can
> have dynamic initialization and destruction semantics. This sequence of
> patches implements that.
>
> The first patch adds the C++11 thread_local keyword and imple
On Thu, 4 Oct 2012, Lawrence Crowl wrote:
> On 10/4/12, Richard Guenther wrote:
> > On Tue, 2 Oct 2012, Lawrence Crowl wrote:
> >> On 10/2/12, Richard Guenther wrote:
> >> > On Mon, 1 Oct 2012, Lawrence Crowl wrote:
> >> > > Change more
On Thu, Oct 4, 2012 at 6:31 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch handles unsigned narrowing casts the same as
> BIT_AND_EXPR with the unsigned narrow type's max value.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
Ok.
Thanks,
Richard.
> 2012-10-04 Jakub Je
On Thu, Oct 4, 2012 at 7:24 PM, Basile Starynkevitch
wrote:
> On Thu, Oct 04, 2012 at 06:51:35PM +0300, Laurynas Biveinis wrote:
>> > 2012-10-03 Basile Starynkevitch
>> >
>> > * gengtype.c (walk_type): Emit mark_hook when inside a
>> > struct of a union member.
>>
>> This is O
On Thu, Oct 4, 2012 at 7:07 PM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 5:37 PM, Vladimir Makarov wrote:
>> The only issue now is PR54146 compilation time for IRA+LRA although it
>> was improved significantly. I will continue work on PR54146. But now I
>> am going to focus on proposal
at.
> i owe you a beer (not that you need another at this time of year).
You also didn't mention the missing tree bits ... was this just a 1/n patch
or is it at all usable for you in this state? Where do the large integers
magically come from?
Richard.
> Kenny
>
>
>
> On
On Thu, 4 Oct 2012, Jan Hubicka wrote:
> > > So SOC cancels out in the runtime check.
> > > I still think we need two formulas - one determining if vectorization is
> > > profitable, other specifying the threshold for scalar path at runtime
> > > (that
> > > will generally give lower values).
> >
h is called after these statements to
> record these references.
>
> When the step is invariant we return from the function without recording the
> references.
>
> so I thought of dumping the references here.
>
> Is there a cleaner way to dump the references at on
On Wed, Oct 3, 2012 at 7:15 PM, Kenneth Zadeck wrote:
> The enclosed patch is the third of at least four patches that fix the
> problems associated with supporting integers on the target that are
> wider than two HOST_WIDE_INTs.
>
> While GCC claims to support OI mode, and we have two public ports
On Thu, Oct 4, 2012 at 11:43 AM, Steven Bosscher wrote:
> On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher wrote:
>> The "worst" result is this:
>> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128,
>> post_count 12483414
>>
>> But that's still a lot better than before the pa
On Thu, Oct 4, 2012 at 10:26 AM, Arnaud Charlet wrote:
> After changes by Sharad (Add option for dumping to stderr (issue6190057)),
> -fdump-ada-spec is broken, and is now a no-op.
>
> Admittedly, this is because -fdump-ada-spec is handled differently from
> other -fdump-* switches, so this patch
;>Subject: RE: [PATCH] Cilk Plus merging to trunk (2 of n)
>>
>>Hello Joseph,
>> In my last patch, I forgot to add the change Richard Guenther wanted me
>>to make. He wanted me to move the ARRAY_NOTATION_REF node from tree.def
>>to c-family/c-common.def. Here
On Wed, Oct 3, 2012 at 11:01 PM, Tobias Burnus wrote:
> Found using http://scan5.coverity.com/
>
> Build on x86-64-gnu-linux with C/C++/Fortran. I will now do an all-language
> build/regtest.
> OK when it passes?
>
> (Note to the save_string call: I reduced it by 2: The "+1" in the call makes
> it
On Wed, Oct 3, 2012 at 8:22 PM, Joern Rennecke
wrote:
> The ARCompact architecture has some pipelining features that result in
> the vanilla branch shortening not always converging.
>
> Moreover, there are some short, complex branch instructions with very short
> offsets; replacing them with a mul
On Wed, Oct 3, 2012 at 5:20 PM, nick clifton wrote:
> Hi Ian,
>
>
>> Can't you just keep a list of the decls for which you have issued the
>> warning?
>
>
> Yes - that would work too. In fact I agree that this would be cleaner
> solution in my particular case. I'll create a new patch...
>
>
>
>>
On Wed, 3 Oct 2012, Jakub Jelinek wrote:
> Hi!
>
> With the PR54519 patch I've just posted, I've noticed, I've noticed on the
> same testcase from yesterday's IRC:
> static inline void foo (int x, int y) { asm volatile ("nop"); }
> static inline void bar (int z) { foo (z, 0); foo (z, 1); }
> int
On Tue, 2 Oct 2012, Lawrence Crowl wrote:
> On 10/2/12, Richard Guenther wrote:
> > On Mon, 1 Oct 2012, Lawrence Crowl wrote:
> > > Change more non-GTY hash tables to use the new type-safe
> > > template hash table. Constify member function parameters that
> >
on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-10-02 Richard Guenther
PR middle-end/54735
* tree-ssa-pre.c (do_pre): Make sure to update virtual SSA form before
cleaning up the CFG.
* g++.dg/torture/pr54735.C: New testcase.
Index: gcc/tree-ssa
On Tue, Oct 2, 2012 at 3:01 PM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR and on IRC, this patch verifies that vector
> CONSTRUCTOR in GIMPLE is either empty CONSTRUCTOR, or contains scalar
> elements of type compatible with vector element type (then the verification
> is less strict,
On Mon, Oct 1, 2012 at 5:57 PM, Marc Glisse wrote:
> [merging both threads, thanks for the answers]
>
>
> On Mon, 1 Oct 2012, Richard Guenther wrote:
>
>>>> optabs should be fixed instead, an is_gimple_val condition is
>>>> implicitely
>>>> val
On Mon, 1 Oct 2012, venkataramanan.ku...@amd.com wrote:
> Hi,
>
> The below patch fixes the FFT/Scimark regression caused by useless prefetch
> generation.
>
> This fix tries to make prefetch less aggressive by prefetching arrays in the
> inner loop, when the step is invariant in the entire loo
On Mon, Oct 1, 2012 at 8:39 PM, Gabriel Dos Reis
wrote:
> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
> wrote:
>> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>>> Your change on September 30th, breaks the powerpc port because the
>>> REPORT_DETAILS value in the enumerati
On Tue, Oct 2, 2012 at 1:31 AM, Sharad Singhai wrote:
> Here is a patch to fix test breakage caused by r191883. Bootstrapped
> on x86_64 and tested with
> make -k check RUNTESTFLAGS="--target_board=unix/\{,-m32\}".
>
> Okay for trunk?
Ok.
Thanks,
Richard.
> Thanks,
> Sharad
>
> 2012-10-01 Shar
On Tue, Oct 2, 2012 at 1:11 AM, Xinliang David Li wrote:
> On Mon, Oct 1, 2012 at 4:05 PM, Sharad Singhai wrote:
>> Thanks for tracking down and fixing the powerpc port.
>>
>> The "dump_kind_p ()" check is redundant but canonical form here. I
>> think blocks of dump code guarded by "if dump_kind_
On Mon, 1 Oct 2012, Lawrence Crowl wrote:
> Change more non-GTY hash tables to use the new type-safe template hash table.
> Constify member function parameters that can be const.
> Correct a couple of expressions in formerly uninstantiated templates.
>
> The new code is 0.362% faster in bootstrap
On Mon, 1 Oct 2012, Jan Hubicka wrote:
> > >
> > > So the unvectorized cost is
> > > SIC * niters
> > >
> > > The vectorized path is
> > > SOC + VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC
> > > The scalar path of vectorizer loop is
> > > SIC * niters + SOC
> >
> >
On Mon, Oct 1, 2012 at 3:55 PM, Sharad Singhai wrote:
> On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu wrote:
>> On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai wrote:
>>> I am sorry, I didn't enable all the languages. Will fix the fortran
>>> test breakage shortly.
>>
>> It is not just Fortran. There
as follows.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2012-10-01 Richard Guenther
* builtins.def (ATTR_MATHFN_FPROUNDING): Do not use no-vops
with -frounding-math.
* builtin-attrs.def (ATTR_PURE_NOTHROW_NOVOPS_LIS
On Mon, Oct 1, 2012 at 2:06 PM, Steven Bosscher wrote:
> Hello,
>
> For most code, expand creates a lot of pseudos that are cleaned up in
> subsequent passes, if they even live long enough to make it there. On
> average, for cc1 preprocessed source, the number of "holes" in
> regno_reg_rtx is abou
On Sun, 30 Sep 2012, Jan Hubicka wrote:
> Hi,
> the point of the following patch is to make vectorizer to not vectorize the
> following testcase with profile feedback:
>
> int a[1];
> int i=5;
> int k=2;
> int val;
> __attribute__ ((noinline,noclone))
> test()
> {
> int j;
> for(j
int main ()
{
int k = 0;
int res = bar (k);
return res;
}
and debug information with/without LTO is now reasonably the same
and I can set breakpoints on the inlined instances.
Thanks,
Richard.
2012-10-01 Richard Guenther
PR lto/47788
* tree-streamer-out.c (write_ts_
On Sat, Sep 29, 2012 at 3:25 PM, Marc Glisse wrote:
> Hello,
>
> this patch does 2 things (I should have split it in 2, but the questions go
> together):
>
> 1) it handles constant folding of vector comparisons,
>
> 2) it fixes another place where vectors are not expected (I'll probably wait
> to
On Mon, Oct 1, 2012 at 11:37 AM, Jan Hubicka wrote:
> Hi,
> this patch commonizes the maximal iteration estimate logic in between SCEV and
> loop-iv. Both are now using loop->nb_iterations_upper_bound. I decided to
> keep same API for SCEV code as for RTL code, so I made
> estimated_loop_iterati
On Mon, Oct 1, 2012 at 7:48 AM, Jakub Jelinek wrote:
> On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
>> But I think that LRA cpu time problem for this test can be fixed.
>> But I don't think I can fix it for 2 weeks. So if people believe
>> that current LRA behaviour on this
On Sun, Sep 30, 2012 at 9:03 PM, Dehao Chen wrote:
> Hi,
>
> This patch fixes the bug when comparing location to UNKNOWN_LOC.
>
> Bootstrapped and passed gcc regression test.
>
> Okay for trunk?
Ok.
Thanks,
Richard.
> Thanks,
> Dehao
>
> 2012-09-30 Dehao Chen
>
> PR middle-end/54759
> * gcc/
On Sat, Sep 29, 2012 at 1:17 PM, Eric Botcazou wrote:
> Hi,
>
> for simple loops like:
>
> extern int a[];
> extern int b[];
>
> void foo (int l)
> {
> int i;
>
> for (i = 0; i < l; i++)
> a[i] = b [i];
> }
>
> you get in the .lim3 dump:
>
> Unanalyzed memory reference 0: _5 = MEM[symbol:
On Fri, Sep 28, 2012 at 6:55 PM, Marc Glisse wrote:
> On Fri, 28 Sep 2012, Richard Guenther wrote:
>
>> On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse
>> wrote:
>>>
>>> Hello,
>>>
>>> I have been experimenting with generating VEC_COND_EXPR f
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
> Hi,
>
>
> To look at it in yet another way:
>
>> integrated RA : 189.34 (16%) usr
>> LRA non-specific: 59.82 ( 5%) usr
>> LRA virtuals eliminatenon: 56.79 ( 5%) usr
>> LRA create live ranges : 175.30 (15%) usr
>> L
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
> Hi Vlad,
>
> Thanks for the testing and the logs. You must have good hardware, your
> timings are all ~3 times faster than mine :-)
>
> On Sat, Sep 29, 2012 at 3:01 AM, Vladimir Makarov wrote:
>> --32-bit--
On Fri, Sep 28, 2012 at 1:31 PM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, tree-vect-generic.c sometimes creates CONSTRUCTORs
> with vector elements to build up larger vectors from vectors supported by
> HW. This patch teaches fold-const to bail up on those. Vector CONSTRUCTOR
> ver
-linux-gnu, applied.
Richard.
2012-09-28 Richard Guenther
PR lto/47799
* lto-streamer-out.c (tree_is_indexable): Make PARM_DECLs global.
(lto_output_tree_ref): Handle references to them.
(output_function): Do not output function arguments again.
* lto
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
> Hello,
>
> I have been experimenting with generating VEC_COND_EXPR from the front-end,
> and these are just a couple things I noticed.
>
> 1) optabs.c requires that the first argument of vec_cond_expr be a
> comparison, but verify_gimple_assig
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
> Originally I was to submit LRA at the very beginning of stage1 for
> gcc4.9 as it was discussed on this summer GNU Tools Cauldron. After
> some thinking, I've decided to submit LRA now but only switched on for
> *x86/x86-64* target. T
On Thu, Sep 27, 2012 at 3:01 PM, Meador Inge wrote:
> Hi All,
>
> The gcc-[ar|nm|ranlib] LTO utils use 'pex_one' to spawn the wrapped binutils
> program. However, currently it is blindly returning the value of the 'err'
> parameter for the exit code. According the documentation [1] 'err' is only
The following patch shrinks symtab_node_base from 104 bytes to 88 bytes
(on x86_64) by re-ordering and packing fields.
Bootstrap & regtest pending.
Richard.
2012-09-27 Richard Guenther
* cgraph.h (symtab_node_base): Re-order and pack fields.
Index: gcc/cgra
On Thu, Sep 27, 2012 at 12:44 PM, Jakub Jelinek wrote:
> Hi!
>
> All INTEGER_CSTs are TREE_CONSTANT, I don't see the point
> in testing that. Ok for trunk?
Ok.
Thanks,
Richard.
> 2012-09-27 Jakub Jelinek
>
> * init.c (build_new_1): Don't test TREE_CONSTANT
> of INTEGER_CST.
On Wed, 26 Sep 2012, Richard Guenther wrote:
> On Wed, 26 Sep 2012, Richard Guenther wrote:
>
> >
> > This fixes PR54709, the location change broke DECL_IS_BUILTIN which
> > is bogously used by streamer_handle_as_builtin_p. I am reverting
> > the previous lt
On Wed, Sep 26, 2012 at 4:39 PM, Marc Glisse wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01041.html
>
> Hmm, maybe I shouldn't put "trivial" in a post, that makes it sound like I
> am not waiting for comments.
>
> Comments?
Ok.
Thanks,
Richard.
>
> On Fri, 14 Sep 2012, Marc Glisse wro
On Wed, 26 Sep 2012, Richard Guenther wrote:
>
> This fixes PR54709, the location change broke DECL_IS_BUILTIN which
> is bogously used by streamer_handle_as_builtin_p. I am reverting
> the previous lto-symtab.c change as it is not necessary for fixing
> the testcases. LTO boots
On Mon, Sep 24, 2012 at 10:10 PM, Sharad Singhai wrote:
> Ping.
Some minor issues:
* c/c-decl.c (c_write_global_declarations): Use different method to
determine if the dump has ben initialized.
* cp/decl2.c (cp_write_global_declarations): Ditto.
* testsuite/gcc.ta
On Mon, Sep 24, 2012 at 5:05 PM, Iyer, Balaji V wrote:
> Hi Richard,
> Please see my comments embedded below.
>
>>-Original Message-
>>From: Richard Guenther [mailto:richard.guent...@gmail.com]
>>Sent: Monday, September 24, 2012 5:53 AM
>>To:
of having it magically "fixed"
without being analyzed.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-09-26 Richard Guenther
PR lto/54709
* tree.h (DECL_IS_BUILTIN): Compare LOCATION_LOCUS.
* tree-streamer.h (streamer
On Wed, Sep 26, 2012 at 11:29 AM, Jakub Jelinek wrote:
> Hi!
>
> At least i?86 and rs6000 backends use V*[SD]F AND/IOR/XOR/NOT
> operations, seems most of the simplify-rtx.c code is properly guarded for
> that with INTEGRAL_MODE_P (mode), but the
> (x - (x & y)) -> (x & ~y)
> optimization was not,
On Wed, Sep 26, 2012 at 10:37 AM, Georg-Johann Lay wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01448.html
>
> Adds an addr_space_t argument to targetm.mode_dependent_address_p.
>
> Up to now the change is a no-op, but the avr backend needs this.
Ok.
Thanks,
Richard.
> Johann
On Wed, Sep 26, 2012 at 6:29 AM, Dehao Chen wrote:
> IS_UNKNOWN_LOCATION is very misleading. This patch removes this macro
> from input.h. For sites when checking LOCUS is intended, we explicit
> use LOCATION_LOCUS and compare it to UNKNOWN_LOCATION.
>
> Bootstrapped and passed all gcc regression
On Tue, Sep 25, 2012 at 7:10 PM, Joern Rennecke
wrote:
> A few arm targets were removed from config.gcc, and picochip is only
> available with --enable-obsolete. This patch brings config-list.mk
> up-to-date in these respects.
>
> 2012-09-24 Joern Rennecke
>
> * contrib-list.mk (LIST):
1 - 100 of 3817 matches
Mail list logo
