Hello,
For this volatile-related issue (no volatile bits on volatile fields of a
non-volatile struct) AFAIU there is an agreement of fixing the front-ends
if needed, but anyways the patch to the selective scheduler is required
that properly merges expressions so that the may_trap_p bit is
On Tue, 26 Feb 2013, Jakub Jelinek wrote:
Hi!
On larger testcases, we leak megabytes of memory since the vec.h changes,
where edge_var_map_vector has been changed from a VEC(edge_var_map, heap) *
into the space efficient vector, but is missing freeing of the pointed
memory (i.e. release
On Tue, Feb 26, 2013 at 11:17:22PM +, Joseph S. Myers wrote:
On Tue, 26 Feb 2013, Marek Polacek wrote:
+ /* We don't allow passing huge ( 2^30 B) arguments
+by value. It would cause an overflow later on. */
+ if (adjusted_args_size.constant = (1 30))
+
On 27/02/13 05:15, Hurugalawadi, Naveen wrote:
The trailing white spaces are observed only in the patch. When the
patch is applied on sources, there are no trailing white spaces.
When I applied the patch to my dev tree it resulted in source with
trailing white space.
Please re-spin the
Andreas Schwab sch...@suse.de writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
diff --git a/libstdc++-v3/scripts/extract_symvers.in
b/libstdc++-v3/scripts/extract_symvers.in
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -49,9
Hi Marcus,
I had a TAB inserted as the pattern was starting at the 9th column.
Hence, it showed trailing whites paces in the patch.
It has been modified according to the earlier patterns in the same file.
Please find attached the modified patch as per your suggestions.
Thanks,
Naveen
On 27/02/13 10:42, Hurugalawadi, Naveen wrote:
Hi Marcus,
I had a TAB inserted as the pattern was starting at the 9th column.
Hence, it showed trailing whites paces in the patch.
The use of TAB there is fine. The issue is that you have trail white
space at the end of the line, which is
Hi Marcus,
The use of TAB there is fine. The issue is that you have trail white
space at the end of the line, which is still present in the latest patch.
Sorry. I confused it with spaces at the start of pattern instead of
trailing space. I have modified it as per your suggestion.
Please
On 27/02/13 11:16, Hurugalawadi, Naveen wrote:
Hi Marcus,
The use of TAB there is fine. The issue is that you have trail white
space at the end of the line, which is still present in the latest patch.
Sorry. I confused it with spaces at the start of pattern instead of
trailing space. I have
On Wed, Feb 27, 2013 at 10:56 AM, Marek Polacek pola...@redhat.com wrote:
On Tue, Feb 26, 2013 at 11:17:22PM +, Joseph S. Myers wrote:
On Tue, 26 Feb 2013, Marek Polacek wrote:
+ /* We don't allow passing huge ( 2^30 B) arguments
+by value. It would cause an
cpplib-4.8-b20130224.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
coordina...@translationproject.org
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file,
Hello,
so now we have the approval of the Windows specific part. David Edelsohn said
that the rs6000 specific part is all right:
http://gcc.gnu.org/ml/gcc/2013-02/msg00186.html
This patch is available for review since October 2012.
What is missing to get this finally committed to GCC 4.8?
Hi Michael,
Thanks for the review, please find comments inline below.
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Wednesday, 27 February 2013 3:50 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Michael Eager (ea...@eagercon.com); John
Williams; Edgar
This patch does two things: it fixes PR56466 by calling fix_loop_structure
in case we're changing a loop, and secondly, it makes verifiyng
loops in the unroller cheaper: there's no need to verify each loop,
we can do it once after all transformations (verify_loop_structure is
being called via
Hi,
this patch makes SRA create all scheduled replacements declarations
before starting the modification pass over the function. Because we
now create more replacements when generating debug info than when we
do not, this is the only way we can be sure the declarations (even
those that
On Wed, Feb 27, 2013 at 03:52:20PM +0100, Martin Jambor wrote:
Bootstrapped and tested on x86_64-linux, fixes an -fdebug-compare
regression. OK for trunk?
Ok, thanks.
2013-02-25 Martin Jambor mjam...@suse.cz
PR tree-optimization/56294
* tree-sra.c (analyze_access_subtree):
Hi,
looking at dumps of PR 56294 I have noticed that on one occasion, SRA
total scalarization mechanism replaced an uninitialized structure with
scalar replacements and these then happened to end up in DEBUG bind
statements describing another structure. Such replacements then did
not end up in
On Wed, Feb 27, 2013 at 04:08:09PM +0100, Martin Jambor wrote:
2013-02-26 Martin Jambor mjam...@suse.cz
* tree-sra.c (load_assign_lhs_subreplacements): Do not put replacements
with no initialization to the RHS of debug statements.
Okay.
--- src.orig/gcc/tree-sra.c
+++
On Wed, 27 Feb 2013, Marek Polacek wrote:
This patch does two things: it fixes PR56466 by calling fix_loop_structure
in case we're changing a loop, and secondly, it makes verifiyng
loops in the unroller cheaper: there's no need to verify each loop,
we can do it once after all transformations
This splits data reference group analysis away from data dependence
checking and splits the latter into loop and a BB vectorization
functions. This allows us to perform the now no longer quadratic
but O(n * log (n)) data reference group analysis right after
data reference gathering, pushing the
Hi!
As discussed in the PR, sometimes we call lra_create_live_ranges multiple
times without intervening lra_clear_live_ranges, which results in memory
leaks.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
Hi!
Apparently even node-alias nodes can have reference vars info created,
so we need to free it too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* ipa-reference.c (propagate): Free
Hi!
We can leak mw_hardregs memory in some cases.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* df-scan.c (df_insn_delete): Use df_scan_free_mws_vec before
pool_free.
Hi!
The release_node hook is only called when a cgraph node is removed, not
when it merely gets -analyzed field cleared. If that happens on
some node that has_function_state, we leak the memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27
Il 27/02/2013 17:01, Jakub Jelinek ha scritto:
Hi!
We can leak mw_hardregs memory in some cases.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* df-scan.c
looks ok, not my call as to the as to the appropriate for stage 4.
On 02/27/2013 11:01 AM, Jakub Jelinek wrote:
Hi!
We can leak mw_hardregs memory in some cases.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
Hi!
I've noticed that libcpp/ uses --enable-checking in configure in incompatible
way from gcc/, as the configure options are passed to both, we'd better make
them compatible. In particular, libcpp would be built with checking even
e.g. when configured with --enable-checking=release, on the
Hi!
known_aggs is freed/released in another function, but not in
decide_whether_version_node, where it leaks memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* ipa-cp.c
Hi all,
I notice the function simplify_compare_const() in gcc/combine.c presents
different behavior between 32-bit host machine and 64-bit host machine,
causing it to perform different RTL transformation for a 32-bit target.
In the function: simplify_compare_const (enum rtx_code code, rtx op0,
We were trying to keep the USING_DECL for an inheriting constructor from
interfering with name lookup, but it still did. It occurred to me that
the obvious way to avoid it interfering with the name of the base is to
give the USING_DECL the constructor name, and then we can remove some of
the
On 02/26/13 12:24, Richard Henderson wrote:
On 02/25/2013 02:52 PM, Aldy Hernandez wrote:
I think it's best to do this here at tmmark time, instead of at IPA-tm.
Don't we have problems when ipa inlining runs after ipa_tm, thus
creating more instrumented code later on?
No, I shouldn't think
This aarch64 FAIL is known to be an issue on targets that define
TARGET_PTRMEMFUNC_VBIT_LOCATION to ptrmemfunc_vbit_in_delta
The issue was silenced early 2012 on arm and mips with an xfail, this
patch adds aarch64 to the list.
The relevant upstream thread around the xfail for arm and mips is
On 02/27/2013 06:42 AM, David Holsgrove wrote:
Hi Michael,
Thanks for the review, please find comments inline below.
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Wednesday, 27 February 2013 3:50 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Michael
cpplib-4.8-b20130224.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
coordina...@translationproject.org
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Russian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/ru.po
(This file,
From: Maciej W. Rozycki [ma...@codesourcery.com]
Steve, would you therefore please do us a favour and check what the AVP
for MIPS32r2 requires for support of the floating-point MADD instruction
subset, or preferably, the whole COP1X instruction set? Are these
instructions only mandatory
On 26/02/2013 22:07, Ludovic Courtès wrote:
* Makefile.in (LDFLAGS): New variable.
Import from automake might be more informative.
cheers,
DaveK
On 02/10/2013 10:40 PM, David Holsgrove wrote:
Adjustments to pcmp instruction generation
avoid pcmpe insns when not valuable
For pure in and equality comparisions, xor is better,
Xor is a one cycle insn as pcmp.
Pattern insns will still be used when you need to
conditionally set something to
Hi,
Several new (ish?) autovectorizer features have apparently caused NEON
support for same to regress quite heavily in big-endian mode. This
patch is an attempt to fix things up, but is not without problems --
maybe someone will have a suggestion as to how we should proceed.
The problem (as
On Mon, 25 Feb 2013, Richard Earnshaw wrote:
Attached is my proposed additions to the GCC-4.8 changes page.
These look good to me, thanks!
Comments on an electronic postcard, please.
I'll also be happy to send you a real one next time. :-)
Gerald
On Fri, 22 Feb 2013, Jack Howarth wrote:
Current gcc-4_6-branch still fails to bootstrap when texinfo 5.0 is
installed. The attached patch fixes the remaining instances where @itemx
need to be replaced with @item. An additional instance of misplaced
brackets was fixed to match current
On Wed, 27 Feb 2013, Richard Biener wrote:
Wouldn't it be better to simply pass this using the variable size handling
code? Thus, initialize args_size.var for too large constant size instead?
Would that be compatible with the ABI definition of how a large (constant
size) argument should be
On Tue, Feb 26, 2013 at 2:59 AM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Feb 26, 2013 at 2:12 AM, Wei Mi wrote:
But it is not a good transformation unless we know insn split will
change a (b 63) to a b; Here we want to see what the rtl looks
like after insn splitting in fwprop
On Wed, Feb 27, 2013 at 06:35:40PM +0100, Gerald Pfeifer wrote:
On Fri, 22 Feb 2013, Jack Howarth wrote:
Current gcc-4_6-branch still fails to bootstrap when texinfo 5.0 is
installed. The attached patch fixes the remaining instances where @itemx
need to be replaced with @item. An
Hi,
in this PR submitter notices that in -Wctor-dtor-privacy we also handle
the case of private member functions which are neither constructors nor
destructors. Eg, we warn for:
class A { // warning: all member functions in class 'A' are private
void f();
};
Thus, minimally, I think we
On 02/27/2013 09:29 AM, Julian Brown wrote:
Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
===
--- gcc/testsuite/gcc.dg/vect/slp-cond-3.c(revision 196170)
+++ gcc/testsuite/gcc.dg/vect/slp-cond-3.c(working copy)
@@ -79,6
On 02/27/2013 08:47 AM, Marcus Shawcroft wrote:
This aarch64 FAIL is known to be an issue on targets that define
TARGET_PTRMEMFUNC_VBIT_LOCATION to ptrmemfunc_vbit_in_delta
The issue was silenced early 2012 on arm and mips with an xfail, this
patch adds aarch64 to the list.
The relevant
Steve Ellcey steve.ell...@imgtec.com writes:
From: Maciej W. Rozycki [ma...@codesourcery.com]
Steve, would you therefore please do us a favour and check what the AVP
for MIPS32r2 requires for support of the floating-point MADD instruction
subset, or preferably, the whole COP1X instruction
On 2/27/13 4:58 PM, Jakub Jelinek wrote:
Hi!
Apparently even node-alias nodes can have reference vars info created,
so we need to free it too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2013-02-27 Jakub Jelinek ja...@redhat.com
On 2/27/13 4:59 PM, Jakub Jelinek wrote:
Hi!
known_aggs is freed/released in another function, but not in
decide_whether_version_node, where it leaks memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
Ok.
Thanks,
Richard.
2013-02-27 Jakub
On 2/27/13 5:03 PM, Jakub Jelinek wrote:
Hi!
The release_node hook is only called when a cgraph node is removed, not
when it merely gets -analyzed field cleared. If that happens on
some node that has_function_state, we leak the memory.
Fixed thusly, bootstrapped/regtested on x86_64-linux
On Wed, 27 Feb 2013, Richard Sandiford wrote:
I checked with one of the AVP engineers and he said:
madd/msub/nmadd/nmsub.fmt instructions are required for all release 2
implementations,
whether or not that implementation has a 64 bit fpu. They are also
required for mips64
release 1
Greetings,
Google ref b/8187733
Build libstdc++-v3/src/c++11/debug.cc with -fno-omit-frame-pointer, so
frame-based unwinder can step through it.
Tested: bootstrap build and verified debug.cc is built with
-fno-omit-frame-pointer.
Ok for google/gcc-4_7 and google/integration?
Thanks,
--
Paul
On Wed, Feb 27, 2013 at 3:13 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:
Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
On Wed, Feb 27, 2013 at 12:13 PM, Paul Pluzhnikov
ppluzhni...@google.com wrote:
Greetings,
Google ref b/8187733
Build libstdc++-v3/src/c++11/debug.cc with -fno-omit-frame-pointer, so
frame-based unwinder can step through it.
Just an aside which program does not understand dwarf2 unwinding?
Hi!
As discussed on IRC, this function calls htab_find_slot_with_hash with
INSERT early, but sometimes decides to return without actually making
sure *hash_slot is non-NULL. That can result in broken hash table,
because NULL is empty entry and could break lookup for some other hash
value. Fixed
Hi!
This function leaks the not_executed_last_iteration pointer set.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Call
Hi!
This function used vec copy () method, but unfortunately that allocates
a fresh new vector and overwrites the target vectortree variable with it
(making it leak memory).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-02-27 Jakub Jelinek
Hi!
Another leak, this time in vectorizable_reduction.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-vect-loop.c (vectorizable_reduction): Release vect_defs
vector.
---
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link in a frame-based unwinder.
This allows us to report crashes and record runtime statistics from the
executable itself,
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link in a frame-based unwinder.
This allows us to report crashes and
On Wed, Feb 27, 2013 at 7:37 PM, Wei Mi wrote:
What do you think?
I think you'll not be able to teach fold_rtx to perform the
transformation you want it to do without having SHIFT_COUNT_TRUNCATED
set for i386. I already tried it the other day, but GCC won't do the
truncation without knowing the
On 02/27/2013 01:22 PM, Jakub Jelinek wrote:
Hi!
Another leak, this time in vectorizable_reduction.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
* tree-vect-loop.c
On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law l...@redhat.com wrote:
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link
On 02/27/2013 02:46 PM, Andrew Pinski wrote:
Perf handles this by saving off some of the stack space instead and
then post-process it. This is why I said perf handles this case
already. Now oprofile does not but oprofile is really going away.
I'm well aware of how perf handles this, having had
I've been working a bit on improving exception-related features in gdb.
I had two goals which led to this particular patch.
First, I wanted to be able to implement type-name-based filtering for
catch catch and friends. (This feature was documented in the past,
but never implemented, and
OK. I suppose we could add a different name as an alias, but it
probably isn't worth the bother.
Jason
Yes, I agree with you. fold_rtx also needs to be extended because now
it only handles the case similar as follows for shift insn:
a = b op const1
c = a const2
for our motivational case, the second operand of the first insn is a
reg instead of a const. We also need to add the truncation
On 02/27/2013 01:21 PM, Jakub Jelinek wrote:
Hi!
This function used vec copy () method, but unfortunately that allocates
a fresh new vector and overwrites the target vectortree variable with it
(making it leak memory).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
On 02/27/2013 01:19 PM, Jakub Jelinek wrote:
Hi!
This function leaks the not_executed_last_iteration pointer set.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-02-27 Jakub Jelinek ja...@redhat.com
PR middle-end/56461
*
On Wed, Feb 27, 2013 at 1:46 PM, Andrew Pinski pins...@gmail.com wrote:
libunwind is not needed since there is already a dwarf2 based unwinder
that is accessible in libgcc already.
Last I checked, libgcc dwarf handling code called malloc, and thus wasn't
suitable when you want to instrument
On 02/27/2013 09:08 AM, Jakub Jelinek wrote:
Hi!
I've noticed that libcpp/ uses --enable-checking in configure in incompatible
way from gcc/, as the configure options are passed to both, we'd better make
them compatible. In particular, libcpp would be built with checking even
e.g. when
On Wed, Feb 27, 2013 at 03:06:03PM -0700, Jeff Law wrote:
Presumably there's a good reason why we don't put __cpp_buff at the
start of the structure all the time? From a purely maintenance
standpoint that seems better
I think there are two reasons, one is mentioned in the function comment
On 27/02/2013 19:53, Ludovic Courtès wrote:
Dave Korn skribis:
On 26/02/2013 22:07, Ludovic Courtès wrote:
* Makefile.in (LDFLAGS): New variable.
Import from automake might be more informative.
Automake has nothing to do with that.
Thinko on my part. It's autoconf (via the
-Original Message-
From: Michael Eager [mailto:ea...@eagercon.com]
Sent: Thursday, 28 February 2013 3:06 am
To: David Holsgrove
Cc: Michael Eager; gcc-patches@gcc.gnu.org; John Williams; Edgar E. Iglesias
(edgar.igles...@gmail.com); Vinod Kathail; Vidhumouli Hunsigida; Nagaraju
Fix race with writing module infos in a parallel make exposed
by change that added primary module info to all gcda files. Instead
of saving eof_pos from the initial write, seek to the zero byte
written at the end of the file when reopening and writing the module
infos.
Tested with regression
https://codereview.appspot.com/7426043/diff/1/gcc/gcov-io.h
File gcc/gcov-io.h (right):
https://codereview.appspot.com/7426043/diff/1/gcc/gcov-io.h#newcode1013
gcc/gcov-io.h:1013: GCOV_LINKAGE void gcov_seek (gcov_position_t
/*position*/, int /* from_end */)
I think it is better to create a new
On Wed, Feb 27, 2013 at 2:01 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:
Last I checked, libgcc dwarf handling code called malloc, and thus wasn't
suitable when you want to instrument malloc *itself* to collect stack
traces, nor for SIGPROF profiling.
Is libgcc dwarf code async-signal
On Wed, Feb 27, 2013 at 10:37 AM, Jason Merrill ja...@redhat.com wrote:
We were trying to keep the USING_DECL for an inheriting constructor from
interfering with name lookup, but it still did. It occurred to me that the
obvious way to avoid it interfering with the name of the base is to give
Marek Polacek pola...@redhat.com writes:
+ bool changed = false;
+ changed |= true;
+ changed |= true;
+ changed |= true;
+ changed |= true;
+if (changed)
Why do you use |= ...? Isn't it equivalent to just = (which is
more clear) for a boolean?
Thanks,
-miles
Patch updated based on comments. Added new gcov_seek_from_end method.
Passes regression tests and internal benchmark test.
Ok for google branches?
Thanks,
Teresa
2013-02-27 Teresa Johnson tejohn...@google.com
* gcc/coverage.c (build_info_type): Remove eof_pos from gcov_info.
Looks good to me.
https://codereview.appspot.com/7426043/
83 matches
Mail list logo
