Gerald Pfeifer wrote:
I went ahead and made some smaller changes, patch below.
Thanks.
I noticed you are using ..., as in e,
which we usually don't. Why that?
My impression was that a one-letter didn't stand out enough and
looked rather odd; if you think it improves consistency or readab
Hi,
this patch adds a hint that if inlining makes bounds on loop iterations known,
it is probably good idea. This is primarely targetting Fortran's array
descriptors, but should be generally useful.
Fortran will still need a bit more work. Often we disregard inlining because we
think the call is
On Tue, Aug 21, 2012 at 3:31 AM, Lawrence Crowl wrote:
> On 8/20/12, H.J. Lu wrote:
>> The C++ merge caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>>
>> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
>> Is this a known issue?
>
> The two memory stat reports show n
>
> This is useful for large applications with a long tail. The
> instruction working set for those applications are very large, and
> inliner and unroller need to be aware of that and good heuristics can
> be developed to throttle aggressive code bloat transformations. For
> inliner, it is kind o
On Mon, Aug 20, 2012 at 10:29 PM, Jan Hubicka wrote:
>> On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka wrote:
>> >> Xinliang David Li writes:
>> >> >
>> >> > Process level synchronization problems can happen when two processes
>> >> > (running the instrumented binary) exit at the same time. The
>>
On Mon, Aug 20, 2012 at 7:03 PM, Dimitrios Apostolou wrote:
> Hello,
>
> my last attempt on improving something serious was about three weeks ago,
> trying to keep all lengths of all strings parsed in the frontend for the
> whole compilation phase until the assembly output. I was hoping that would
On i386 GNU/Linux, when compiling with -D_FILE_OFFSET_BITS=64,
winds up doing this:
# define F_GETLK F_GETLK64 /* Get record locking info. */
...
# define F_GETLK64 12 /* Get record locking info. */
Because of the ordering, -fdump-go-spec does not write F_GETLK into the
file
> On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka wrote:
> >> Xinliang David Li writes:
> >> >
> >> > Process level synchronization problems can happen when two processes
> >> > (running the instrumented binary) exit at the same time. The
> >> > updated/merged counters from one process may be overwr
On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka wrote:
>> Xinliang David Li writes:
>> >
>> > Process level synchronization problems can happen when two processes
>> > (running the instrumented binary) exit at the same time. The
>> > updated/merged counters from one process may be overwritten by ano
On Mon, Aug 20, 2012 at 6:31 PM, Lawrence Crowl wrote:
> On 8/20/12, H.J. Lu wrote:
>> The C++ merge caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>>
>> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
>> Is this a known issue?
>
> The two memory stat reports show n
Hi Gerald / Diego,
I have made all the mentioned changes. I also shortened the
description like Diego mentioned by removing all the strings but kept
the caveats. I have not added a reference to the documentation because
i do not know what link to reference. The builtins are completely
documen
I ran the testsuite for you; no regressions. Looks OK to me, please
apply. Thanks!
In config/mips/mips.h, there is presently this comment:
/* ??? 16-bit offsets can overflow in large functions. */
#define TARGET_MIPS16_SHORT_JUMP_TABLES TARGET_MIPS16_TEXT_LOADS
A while ago we had a bug report where a big switch statement did, in
fact, overflow the range of 16-bit offsets, ca
On 8/20/12, H.J. Lu wrote:
> The C++ merge caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
> Is this a known issue?
The two memory stat reports show no differences. Are you sure you
didn't splice in the wrong report?
> Xinliang David Li writes:
> >
> > Process level synchronization problems can happen when two processes
> > (running the instrumented binary) exit at the same time. The
> > updated/merged counters from one process may be overwritten by another
> > process -- this is true for both counter data and
>> 2012-08-20 Cary Coutant
>>
>> gcc/
>> * dwarf2out.c (remove_loc_list_addr_table_entries): Change
>> parameter; update all calls.
>> (output_pubname): Don't assert on unknown TAGs.
>> (resolve_addr): Call remove_loc_list_addr_table_entries for all
>> lo
My last change to google 4.7 that included gdb/gdb-index.h as it
exists in binutils, but it included a trailing comma in an enumerator.
I have checked in as obvious the patch below which eliminates the
trailing comma.
Sterling
2012-08-20 Sterling Augustine
* gdb/gdb-index.h: Remove
On Mon, Aug 20, 2012 at 5:30 PM, Cary Coutant wrote:
> This patch is for the google/gcc-4_7 branch.
>
> When a location list or location expression is removed from a DIE, we
> need to remove entries in the .debug_addr table that were referenced
> by those location expressions. Except for one case
This patch is for the google/gcc-4_7 branch.
When a location list or location expression is removed from a DIE, we
need to remove entries in the .debug_addr table that were referenced
by those location expressions. Except for one case, the existing code
checked only the first descriptor in each l
On Sat, 2012-08-18 at 10:23 +0200, Uros Bizjak wrote:
> On Sat, Aug 18, 2012 at 10:14 AM, Uros Bizjak wrote:
>
> > After discussion with Oleg, it looks that it is enough to prevent
> > wrong registers in the output of the (multi-output) insn pattern. As
> > far as inputs are concerned, combine al
On Mon, 2012-08-20 at 14:09 -0700, Gary Funck wrote:
> >
> > ChangeLog:
> >
> > PR target/50489
>
> Above: that should be: PR target/54089.
>
> > * config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and
> > splits.
> > (ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split.
> >
On 08/20/12 01:02:39, Oleg Endo wrote:
> Hello,
>
> This adds support for SH's rotcr insn.
> Tested on rev 190459 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new failures.
> OK?
>
> Cheers,
> Oleg
>
> Chang
On Tue, Aug 14, 2012 at 11:59 AM, Diego Novillo wrote:
> On 12-08-14 09:48 , Diego Novillo wrote:
>
>> This merge touches several files, so I'm thinking that the best time is
>> going to be on Thu 16/Aug around 2:00 GMT.
>
>
> So, the fixes I needed from Lawrence are already in so we can proceed w
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00398.html
-cary
On Mon, Aug 13, 2012 at 1:13 PM, Cary Coutant wrote:
>> 2012-08-07 Cary Coutant
>>
>> gcc/
>> * dwarf2out.c (clone_as_declaration): Copy DW_AT_abstract_origin
>> attribute.
>> (generate_skeleton_bott
Hi Sriraman,
On Fri, 10 Aug 2012, Sriraman Tallam wrote:
> I have added a release note for x86 builtins __builtin_cpu_is and
> __builtin_cpu_supports. They were checked in to trunk in rev. 186789.
I had hoped one of the x86 maintainers would review this from his
perspective given that they have m
OK. Sorry for the delay.
Jason
On Mon, Aug 20, 2012 at 09:59:26PM +0200, Mark Wielaard wrote:
> Ping. There are stable releases of GDB 7.5, valgrind 3.8.0 and
> elfutils 0.154 out now that support it.
>
> I rebased the patch and tested against GDB 7.5.
>
> 2012-08-20 Mark Wielaard
>
> * dwarf2out.h (enum dw_val_class):
On Fri, Apr 27, 2012 at 08:16:04PM +0200, Mark Wielaard wrote:
> On Fri, 2012-04-27 at 15:43 +0200, Jakub Jelinek wrote:
> > On Fri, Apr 27, 2012 at 03:36:56PM +0200, Mark Wielaard wrote:
> > > But even without this, I think the patch is worth it just to get rid of
> > > all the relocations necessa
I was mistaken here -- gcov_open actually uses locking via fcntl
interface -- so we do need to find a way to solve the summary update
synchronization problem when it is separate out of the per-file update
loop.
David
On Mon, Aug 20, 2012 at 12:03 PM, Andi Kleen wrote:
> Xinliang David Li writes
Committed as Rev. 190542
Tobias
Index: gcc/testsuite/gfortran.dg/warn_target_lifetime_2.f90
===
--- gcc/testsuite/gfortran.dg/warn_target_lifetime_2.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/warn_target_lifetime_2.f90 (Arbeitsko
Hi!
On the testcase from this PR on AVR (from libgcc, thus not including
it into testsuite/) we ICE, because dead_debug_insert_temp is called
several times on the same insn, for multi-register hard register for each
regno in it (except the first which doesn't seem to be dead).
In the first call de
Xinliang David Li writes:
>
> Process level synchronization problems can happen when two processes
> (running the instrumented binary) exit at the same time. The
> updated/merged counters from one process may be overwritten by another
> process -- this is true for both counter data and summary dat
SPARC is now one of the last mainstream 64-bit platforms that do not define
MAX_FIXED_MODE_SIZE to TImode. Doing so helps the Ada compiler in particular
because it is a heavy user of structures made up of a pair of pointers.
Bootstrapped/regtested/compat-regtested on SPARC64/Solaris, applied on
Hi Thomas,
Thomas Koenig wrote:
do you think that -Wtarget-lifetime should be included with -Wall?
I think so, because the code flagged is certainly invalid, and likely
to cause random errors.
I concur. However, that's what the current version in the trunk does:
-Wall implies -Wtarget-lifetim
Jakub Jelinek writes:
> 2012-08-17 Jakub Jelinek
>
> PR rtl-optimization/54294
> * fwprop.c (all_uses_available_at): Ignore debug insns in between
> def_insn and target_insn when checking whether the shortcut is
> possible.
OK, thanks.
Richard
On Thu, Aug 16, 2012 at 5:32 PM, Cary Coutant wrote:
>> +/* Output a single entry in the pubnames table. */
>> +
>> +static void
>> +output_pubname (dw_offset die_offset, pubname_entry *entry)
>
> For this function, I'd suggest a comment to the effect that the logic
> is lifted from GDB.
>
>> @@
On Fri, Aug 10, 2012 at 10:20 PM, Sriraman Tallam wrote:
> Hi,
>
>I have added a release note for x86 builtins __builtin_cpu_is and
> __builtin_cpu_supports. They were checked in to trunk in rev. 186789.
> Is this ok to submit?
I would not include such detailed documentation in changes.html.
Ping.
On Tue, Aug 14, 2012 at 11:02 AM, Sriraman Tallam wrote:
> +ger...@pfiefer.com
>
> On Tue, Aug 14, 2012 at 10:51 AM, Sriraman Tallam wrote:
>> Hi Gerald,
>>
>>Is this release note alright?
>>
>> Thanks,
>> -Sri.
>>
>> On Fri, Aug 10, 2012 at 7:20 PM, Sriraman Tallam wrote:
>>> Hi,
>
Hi Tobias,
do you think that -Wtarget-lifetime should be included with -Wall?
I think so, because the code flagged is certainly invalid, and likely
to cause random errors.
Thomas
On Mon, Aug 20, 2012 at 7:44 PM, Teresa Johnson wrote:
> But
> the code in coverage.c is dealing with a single gcda file containing
> multiple program summaries. Is there code somewhere that will cause
> this to happen?
Not that I know of, no.
(There are enhancement requests for this, see e.g. PR
On Mon, Aug 20, 2012 at 8:35 AM, Steven Bosscher wrote:
> On Mon, Aug 20, 2012 at 11:48 AM, Jan Hubicka wrote:
>>> The summary merging in coverage.c confuses me a bit as it seems to be
>>> handling the case when there are multiple program summaries in a
>>> single gcda file. When would this happe
OK.
Jason
The GCC -fpic/-fPIC option has evolved to mean code generation for a
shared library and changes the optimization behavior of the compiler.
Code for AIX PowerPC always is PIC, but the optimization behavior is
affecting AIX.
libtool exports all global symbols on AIX while GCC binds_local_p()
determi
> If this approach seems like it is feasible, then we could stick with
> the current approach of emitting the working set array in the summary,
> mitigating it somewhat by doing the sum_all based scaling of the
> counter values, then in a follow on patch restructure the merging code
> to delay the
Hello,
my last attempt on improving something serious was about three weeks ago,
trying to keep all lengths of all strings parsed in the frontend for the
whole compilation phase until the assembly output. I was hoping that would
help on using faster hashes (knowing the length allows us to hash
>
> So I definitely preffer 2 or 3 over 1. David has experience with 3. How well
> does
> it work for LIPO?
>
This (lack of locking, races) is not a new problem. There is no
synchronization in libgcov for profile update/merge at both thread and
process level. Thread level data races leads to inco
Kenneth Zadeck writes:
> The omission of CONST_FIXED from the cselib_expand_value_rtx_1,
> attr_copy_rtx, clear_struct_flag and combine switches looks
> unintentional (though only as a missed compiler-speed optimisation).
> Same goes for the omission of CONST_VECTOR from check_maybe_invariant.
>
>
On Mon, Aug 20, 2012 at 11:48 AM, Jan Hubicka wrote:
>> The summary merging in coverage.c confuses me a bit as it seems to be
>> handling the case when there are multiple program summaries in a
>> single gcda file. When would this happen? It looks like the merge
>> handling in libgcov should alway
On Mon, Aug 20, 2012 at 4:54 PM, Dimitrios Apostolou wrote:
> In the process I realised that obstacks weren't exactly suitable (thanks
> matz for helping on IRC),
Right, alloc-pool would be a better choice here.
Ciao!
Steven
On Thu, Aug 16, 2012 at 2:13 PM, Gabriel Dos Reis
wrote:
>
> On Wed, Aug 15, 2012 at 9:52 AM, Ollie Wild wrote:
> > (Adding other C++ maintainers in case someone else wants to have a
> > stab.)
> >
> > Ping?
>
> I consider Jason to be the expert on this; so let see what he says.
>
> -- Gaby
Jaso
Hi,
while I was happy using obstacks in other parts of the compiler I thought
they would provide a handy solution for the XNEWVECs/XRESIZEVECs in
df-scan.c, especially df_install_refs() which is the heaviest malloc()
user after the rest of my patches.
In the process I realised that obstacks
On Mon, Aug 20, 2012 at 2:48 AM, Jan Hubicka wrote:
>> Well, it should store the largest working set in BBs, or one that came
>> from a much longer run. But I see the issue you are pointing out. The
>> num_counters (the number of hot bbs) should be reasonable, as the
>> total number of BBs is the
On Mon, 20 Aug 2012, Simon Baldwin wrote:
> > OPT_* for Fortran options only exist when the Fortran front-end is in the
> > source tree (whether or not enabled). I think we try to avoid knowingly
> > breaking use cases where people remove some front ends from the source
> > tree, although we don'
On Mon, Aug 20, 2012 at 10:20:33AM -0400, Patrick Marlier wrote:
> Ok for trunk? Ok to backport to 4.7 branch if no regression?
Ok for both, with the following nits resolved:
> gcc/
> 2012-08-17 Patrick Marlier
>
> PR libgomp/53992
Use PR middle-end/53992 instead, libgomp is for librar
On 08/20/2012 07:20 AM, Patrick Marlier wrote:
> 2012-08-17 Patrick Marlier
>
> PR libgomp/53992
> * omp-low.c (lower_omp_1): Handle GIMPLE_TRANSACTION.
Ok everywhere.
The Bugzilla must not change to libgomp, as that is
reserved for the runtime library.
r~
On 17 August 2012 16:55, Joseph S. Myers wrote:
>
> On Fri, 17 Aug 2012, Simon Baldwin wrote:
>
> > > You could have just added
> > > case OPT_cpp_:
> > > to the switch in gen_producer_string, instead of all this.
> >
> > Thanks. I was under the impression, apparently mistaken, that
> > OPT_cpp
Found this while running -ftime-report on a largish C++ source file.
We need to start TV_NAME_LOOKUP conditionally inside poplevel()
because it may be called from another lookup routine that already has
TV_NAME_LOOKUP going.
Tested on x86_64. Committed to trunk.
2012-08-20 Diego Novillo
In this PR, OMP lowering is not going into the transaction code.
So if GIMPLE_TRANSACTION is found, we lower its body.
(Patch also fixes a format issue.)
Note that PR53992 component in Bugzilla must be change from c to libgomp
(I don't have bugzilla account with admin rights, who should I ask fo
Hi,
in this old issue submitter points out that we emit too easily
Wunused_variable warnings even when the destructor has side effects
(otoh, the constructor is handled Ok). This is particularly annoying
together with eg, RAII.
Turns out that lately we are already careful when we handle the
On 20/08/12 15:01, Tobias Burnus wrote:
> Hi Richard,
>
> your patch fails here; I get the build failure:
>
> /projects/tob/gcc-git/gcc/gcc/tree-ssa-math-opts.c: In function ‘bool
> is_widening_mult_rhs_p(tree, tree, tree_node**, tree_node**)’:
> /projects/tob/gcc-git/gcc/gcc/tree-ssa-math-opts.
On Fri, Aug 17, 2012 at 2:42 AM, Chupin, Pavel V
wrote:
> Submitted patch here: https://android-review.googlesource.com/#/c/41705
>
> -- Pavel
>
link.h has been added to AOSP. I am closing PR 54209.
Thanks.
--
H.J.
Hi Richard,
your patch fails here; I get the build failure:
/projects/tob/gcc-git/gcc/gcc/tree-ssa-math-opts.c: In function ‘bool
is_widening_mult_rhs_p(tree, tree, tree_node**, tree_node**)’:
/projects/tob/gcc-git/gcc/gcc/tree-ssa-math-opts.c:2014:18: error:
variable ‘rhs_code’ set but not us
I of course meant the machine "independent" not "dependent"
On 08/20/2012 09:50 AM, Kenneth Zadeck wrote:
This patch started out to be a purely mechanical change to the switch
statements so that the ones that are used to take apart constants can
be logically grouped.This is important for the
This patch started out to be a purely mechanical change to the switch
statements so that the ones that are used to take apart constants can be
logically grouped.This is important for the next patch that I will
submit this week that frees the rtl level from only being able to
represent large
On 11/07/12 12:30, Tom de Vries wrote:
> On 13/11/10 10:50, Eric Botcazou wrote:
>>> I profiled the pass on spec2000:
>>>
>>> -mabi=32 -mabi=64
>>> ee-pass (usr time): 0.70 1.16
>>> total (usr time): 919.30 879.26
>>> ee-pass(%): 0.08
On 2012-08-19 07:18 , Arnaud Charlet wrote:
The conditionals cannot be removed for the time being because the
foreign language interface of the Ada part of the compiler is
hardcoded for C.
Barring a massive switch to the Ada language for the GNU project,
we would need to switch the foreign lan
Hi Paolo,
On Mon, 20 Aug 2012, Paolo Bonzini wrote:
Il 19/08/2012 18:55, Richard Guenther ha scritto:
Initially I had one obstack per struct graph, which was better than using
XNEW for every edge, but still obstack_init() called from new_graph() was
too frequent.
So in this iteration of the pa
On Mon, Aug 20, 2012 at 1:37 AM, Oleg Endo wrote:
> On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote:
>> On Sun, 19 Aug 2012, Oleg Endo wrote:
>> > Thanks. Let's hope that I can squeeze in some more stuff while
>> > stage 1 lasts. :T
>>
>> You know that for backend-specific changes (especi
On Mon, 20 Aug 2012, Oleg Endo wrote:
> You mean, since SH is neither a primary nor a secondary platform,
> there are no particular release criteria for it? What does that
> actually mean?
>From what I recall, you can make stage 1 type changes even after
stage 1. However, if your port is broken,
This shrinks TREE_VEC from 40 bytes to 32 bytes and SSA_NAME from
80 bytes to 72 bytes on a 64bit host. Both structures suffer
from the fact they need storage for an integer (length and version)
which leaves unused padding. Both data structures do not require
as many flag bits as we keep in tree
On Mon, Aug 20, 2012 at 2:03 PM, Paolo Bonzini wrote:
> Il 19/08/2012 18:55, Richard Guenther ha scritto:
>>> > Initially I had one obstack per struct graph, which was better than using
>>> > XNEW for every edge, but still obstack_init() called from new_graph() was
>>> > too frequent.
>>> >
>>> >
Il 19/08/2012 18:55, Richard Guenther ha scritto:
>> > Initially I had one obstack per struct graph, which was better than using
>> > XNEW for every edge, but still obstack_init() called from new_graph() was
>> > too frequent.
>> >
>> > So in this iteration of the patch the obstack is static global
This performs timevar push/pop at the single remaining entry to
incremental SSA rewrite setup. The other entry,
register_new_name_mapping, is removed by making its only other
user use create_new_def_for. Which needs to handle a NULL DEF
for this case, as we have no access to a DEF op for an SS
On Fri, Aug 17, 2012 at 7:05 PM, Richard Earnshaw wrote:
> On 17/08/12 16:20, Richard Earnshaw wrote:
>> Ok, in which case we have to give is_widening_mult_rhs_p enough smarts
>> to not strip
>>
>> (s32)u32
>>
>> and return u32.
>>
>> I'll have another think about it.
>
> Take two.
>
> This
On Sat, Aug 18, 2012 at 11:59 AM, Marc Glisse wrote:
> Hello,
>
> here is a new patch (passes bootstrap+regtest), which only combines
> permutations if the result is the identity. I'll file a PR about more
> general
> combinations to link to this conversation and the cost hook proposition.
>
> Ok?
On Mon, Aug 20, 2012 at 1:28 PM, Joseph S. Myers
wrote:
> Building a cross compiler from i686-mingw32 to arm-none-eabi fails
> after the move to build as C++ because config/arm/neon.md uses ffs but
> no MinGW header declares ffs (and unlike in C, an implicit declaration
> of this built-in function
Building a cross compiler from i686-mingw32 to arm-none-eabi fails
after the move to build as C++ because config/arm/neon.md uses ffs but
no MinGW header declares ffs (and unlike in C, an implicit declaration
of this built-in function can't be used). This patch fixes this issue
by making the gcc d
Oleg Endo wrote:
> This adds two new patterns to undo an optimization that is done by ifcvt
> and is not beneficial if zero displacement branches are available on SH.
> Tested on rev 190459 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-
Oleg Endo wrote:
> This adds support for SH's rotcr insn.
> Tested on rev 190459 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new failures.
> OK?
OK.
Regards,
kaz
On Tue, 14 Aug 2012, Tobias Burnus wrote:
> I have committed the patch as obvious, however, I am happy for any
> comments.
I went ahead and made some smaller changes, patch below.
I noticed you are using ..., as in e,
which we usually don't. Why that?
Gerald
Index: changes.html
==
On Fri, 17 Aug 2012, Richard Guenther wrote:
>
> This gets rid of this field, pushing it into a short int in tree_base
> (hopefully 2^16 non-defaulted template args are enough ...). The
> existing code is a bit confusing because of the differences with
> respect to ENABLE_CHECKING, it has very l
This is an issue of folding looking at SSA def stmts when SSA form
is not up-to-date. That's not safe unless the SSA name we are
looking at is not marked for update (see GIMPLE_COND folding in
cfgcleaup for another example).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
Tejas Belagod wrote:
Ulrich Weigand wrote:
The following patch implements this idea; it passes a basic regression
test on arm-linux-gnueabi. (Obviously this would need a lot more
testing on various platforms before getting into mainline ...)
Can you have a look whether this fixes the problem y
> Well, it should store the largest working set in BBs, or one that came
> from a much longer run. But I see the issue you are pointing out. The
> num_counters (the number of hot bbs) should be reasonable, as the
> total number of BBs is the same between all runs, and I want to show
> the largest o
On Mon, 20 Aug 2012, Jakub Jelinek wrote:
I'd note for all the recently posted patches from Dimitrios, the gcc/
prefix doesn't belong to the ChangeLog entry pathnames, the filenames are
relative to the corresponding ChangeLog location.
Ah sorry, it's what the mklog utility generates, it seems
On Mon, Aug 20, 2012 at 09:37:39AM +0200, Richard Guenther wrote:
> On Sun, Aug 19, 2012 at 8:30 PM, Dimitrios Apostolou wrote:
> >
> >
> > 2012-08-19 Dimitrios Apostolou
> >
> > * gcc/tree-ssa-pre.c (phi_translate_pool): New static global
> > alloc_pool, used for allocating str
Dimitrios Apostolou a écrit:
[...]
> * include/libiberty.h (XOBDELETE, XOBGROW, XOBGROWVEC, XOBSHRINK)
> (XOBSHRINKVEC, XOBFINISH): New type-safe macros for obstack
> operations.
> (XOBFINISH): Changed to return (T *) instead of T. All callers
> updated.
> * l
This creates better marking code (even though we probably tail-recurse
for the exising one).
Bootstrapped and tested on x86-64-unknown-linux-gnu, applied.
Richard.
2012-08-20 Richard Guenther
* gimple.h (gimple_statement_base): Annotate with GTY chain_next.
Index: gcc/gimple.h
On Mon, Aug 20, 2012 at 8:27 AM, Jakub Jelinek wrote:
> Hi!
>
> The middle-end argument of memset is signed (int), so simplify_builtin_call
> correctly checks host_integerp (val2, 0), but later on used tree_low_cst
> (val2, 1), so for negative values it would ICE. Fixed thusly, the memset
> is su
On Mon, Aug 20, 2012 at 6:49 AM, Andrew Pinski
wrote:
> On Wed, Jul 25, 2012 at 4:39 AM, Richard Guenther
> wrote:
>> On Tue, Jul 24, 2012 at 5:50 PM, Andrew Pinski
>> wrote:
>>> Hi,
>>> Before tuples was introduced, VN used to lookup the simplified
>>> expression to see if it was available al
On Sun, Aug 19, 2012 at 8:44 PM, Gary Funck wrote:
> I filed two bug reports:
>
> "GCC install document does not list minimum required g++ version"
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324
>
> "GCC does not build with G++ version 3.4.0"
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5432
On Sun, Aug 19, 2012 at 8:30 PM, Dimitrios Apostolou wrote:
>
>
> 2012-08-19 Dimitrios Apostolou
>
> * gcc/tree-ssa-pre.c (phi_translate_pool): New static global
> alloc_pool, used for allocating struct expr_pred_trans_d for
> phi_translate_table.
> (phi_trans_ad
The following should fix PR54326 (3.4.6 at least compiles genoutput.c
without warnings after this).
Bootstrap running on x86_64-unknown-linux-gnu.
Richard.
2012-08-20 Richard Guenther
PR bootstrap/54326
* genoutput.c (note_constraint): Properly use CONST_CAST.
Index: gcc/ge
On Sat, 18 Aug 2012, Dimitrios Apostolou wrote:
> Hi,
>
> On Fri, 17 Aug 2012, Jakub Jelinek wrote:
> > On Fri, Aug 17, 2012 at 06:41:37AM -0500, Gabriel Dos Reis wrote:
> > > I am however concerned with:
> > >
> > > > static void
> > > > store_bindings (tree names, VEC(cxx_saved_binding,gc)
94 matches
Mail list logo
