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 pres
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. relea
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
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 patch
Andreas Schwab writes:
> Rainer Orth 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 +49,12 @@ SunOS)
>>if readelf --h
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 sti
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 r
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 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 overflow later
cpplib-4.8-b20130224.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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, 'cpplib-4.8-b201302
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;
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 fix_l
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 eventually
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
>
> PR tree-optimization/56294
> * tree-sra.c (analyze_access_subtree): Create rep
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 th
On Wed, Feb 27, 2013 at 04:08:09PM +0100, Martin Jambor wrote:
> 2013-02-26 Martin Jambor
>
> * 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
> +++ src/gcc/tree-sra
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 transformatio
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 q
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
PR middle-end/5646
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
PR middle-end/56461
* ipa-reference.c (propagate): Free node_info even for alia
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
PR middle-end/56461
* df-scan.c (df_insn_delete): Use df_scan_free_mws_vec before
pool_free.
(df_insn_
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 Jaku
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
>
> PR middle-end/56461
> * df-scan.c (df_insn_delete): Use
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
PR middle-en
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 other
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
PR middle-end/56461
* ipa-cp.c (decide_whether_vers
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,
rt
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 s
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 her
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 Eager
cpplib-4.8-b20130224.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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, 'cpplib-4.8-b20130224
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 ever
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 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 cost estim
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 co
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
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 rele
Steve Ellcey 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 set? Are these
>>
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
>
> PR midd
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 Jaku
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_6
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.
Ludo’.
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
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 P
On Wed, Feb 27, 2013 at 3:13 PM, Paul Pluzhnikov wrote:
> Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
On Wed, Feb 27, 2013 at 12:13 PM, Paul Pluzhnikov
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?
Perf is setup to
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
PR middle-end/56461
* tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Call
pointer_set
Hi!
This function used vec copy () method, but unfortunately that allocates
a fresh new vector and overwrites the target vector 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
PR mid
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
PR middle-end/56461
* tree-vect-loop.c (vectorizable_reduction): Release vect_defs
vector.
--- gcc/tree-vect-loop.c.jj
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski 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, in ways that are
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski 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 statis
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
PR middle-end/56461
* tree-vect-loop.c (vectorizable_reduction): Release vect_de
On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law wrote:
> On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
>>
>> On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski wrote:
>>
>>> Just an aside which program does not understand dwarf2 unwinding?
>>
>>
>> All Google executables currently link in a frame-based
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 occasi
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 suppo
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 vector variable with it
(making it leak memory).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trun
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
PR middle-end/56461
* tree-ssa-loop-niter.c (maybe_l
On Wed, Feb 27, 2013 at 1:46 PM, Andrew Pinski 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 malloc *itself* to
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 configur
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
> -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; Nagaraj
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 tests
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 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 safe now?
> If no
On Wed, Feb 27, 2013 at 10:37 AM, Jason Merrill 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 the
> USING_DEC
Marek Polacek 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
* gcc/coverage.c (build_info_type): Remove eof_pos from gcov_info.
(build_info): Ditto.
Looks good to me.
https://codereview.appspot.com/7426043/
84 matches
Mail list logo
