On Fri, Aug 30, 2013 at 9:58 PM, Teresa Johnson wrote:
> Besides, we might also want to
> use the same machinery (dump_printf_loc etc) for dump file dumping.
> The current behavior of using '-details' to turn on opt-info-all
> messages for dump files are not desirable.
In
On Aug 21, 2013, at 11:47 PM, Jan Hubicka wrote:
>> The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv) is
>> used during thunk code-generation, and thunk code-generation happens during
>> the output of D::foo.
> I see, I will try to modify i386 backend to not output thunks
Besides, we might also want to
use the same machinery (dump_printf_loc etc) for dump file dumping.
The current behavior of using '-details' to turn on opt-info-all
messages for dump files are not desirable.
>>>
>>> Interestingly, this doesn't even work. When I do
>>> -fdump-ipa-
On Fri, Aug 30, 2013 at 9:26 AM, Paolo Carlini wrote:
> Hi,
>
> On 08/30/2013 02:05 PM, Tim Shen wrote:
>>
>> + const _TraitsT&_M_traits;
>> + _FlagT _M_flags;
>> + bool _M_is_non_matching;
>> + std::
This patch / merge broke bootstrap on AIX:
In file included from ./tm.h:18:0,
from /home/dje/src/src/gcc/function.h:26,
from /home/dje/src/src/gcc/basic-block.h:25,
from /home/dje/src/src/gcc/cgraph.h:28,
from /home/dje/src/src/g
[ sorry for the dup, if you see two. ]
On Aug 30, 2013, at 2:55 PM, Caroline Tice wrote:
> The attached patch fixes most of the libvtv testsuite tests to run in
> the dejagnu test harness.
> Since I am supposedly the libvtv maintainer, I am not sure how this
> patch is supposed to be reviewed...
On Aug 30, 2013, at 2:55 PM, Caroline Tice wrote:
> The attached patch fixes most of the libvtv testsuite tests to run in
> the dejagnu test harness.
> Since I am supposedly the libvtv maintainer, I am not sure how this
> patch is supposed to be reviewed...Guidance would be appreciated…
We prefe
On Fri, Aug 30, 2013 at 7:50 AM, Teresa Johnson wrote:
> Can someone review and ok the attached patch for trunk? It has been
> bootstrapped and tested on x86-64-unknown-linux-gnu, and tested by
> enabling -freorder-blocks-and-partition enabled for a
> profiledbootstrap as well.
>
> (Honza, see mor
On Fri, 30 Aug 2013, Cong Hou wrote:
> I have done a simple experiment and found that it may only be safe to do
> this conversion for fabs() and sqrt(). For fabs() it is easy to see the
> safety. For sqrt(), I tried many random floating point values on two
> versions and did not see a difference.
On Thu, 2013-08-29 at 12:20 -0400, David Malcolm wrote:
[...]
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I messed up the testing for this by accidentally configuring the builds
with --ena
On Fri, Aug 30, 2013 at 1:23 AM, Richard Biener
wrote:
> On Fri, Aug 30, 2013 at 1:28 AM, Xinliang David Li wrote:
>> I was debugging a runtime failure of SPEC06 xalancbmk built with LIPO.
>> Using -fdisable- option pinpoints the problem in slp vectorize
>> pass on a particular function. dbgcnt s
On Fri, Aug 30, 2013 at 09:38:01PM +0200, Dominique Dhumieres wrote:
> > I've just merged ubsan into trunk. Please send complaints my way.
>
> Bootstrap is broken on x86_64-apple-darwin10:
>
> Making all in ubsan
> make[4]: *** No rule to make target `../interception/libinterception.la',
> need
Hi,
this patch fixes gcc.dg/tree-ssa/attr-alias.c on x86-64 target.
The problem here is that we attempt to create local alias since we consider
weakref
of test() to be overwritable and at the same time available.
The change in cgraph_function_body_availability makes weakref to properly
inherit
av
On Fri, 30 Aug 2013, Christian Bruel wrote:
> So to cross build a target library |
> --with-build-sysroot=|dir looks appropriate to specify the alternative
> host root path.
> but
> --with-sysroot looks not appropriate because it changes the search paths
> (that should still be /usr/include on the
Index: ChangeLog
===
--- ChangeLog (revision 202117)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-08-30 Bernd Edlinger
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
2013-08-27 David Malcolm
* MA
Yes, this was cleaner, tested and committed this way.
2013-08-30 François Dumont
PR libstdc++/58148
* include/debug/functions.h (__foreign_iterator_aux4): Use
sequence const_pointer as common type to compare pointers. Add a
fallback overload in case pointers cannot be cast to
On Fri, Aug 30, 2013 at 1:30 PM, Xinliang David Li wrote:
> On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson wrote:
>> On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li
>> wrote:
>>> Except that in this form, the dump will be extremely large and not
>>> suitable for very large applications.
>>
On Fri, Aug 30, 2013 at 8:26 AM, Jan Hubicka wrote:
>> >
>> > The frequency condition needs to be done only when you walk predecestors -
>> > when
>> > you walk down the edge probabilities are just fine.
>>
>> True. For simplicity I think it should be fine to leave as-is so there
>> isn't more sp
> Jan Hubicka writes:
> >
> > Now for longer term, we want to make function CFGs independent of gimple
> > body
> > and we want to decide on instrumentation at linktime, so we won't require
> > user
> > to rebuild with -fprofile-use, just relink. I plan to work on this, but
> > not for 4.9.
>
On Fri, 30 Aug 2013, Dominique Dhumieres wrote:
>> Committed as r202101.
> This cause a bootstrap failure:
> on x86_64-apple-darwin10.
And FreeBSD. Your fix also restored bootstrap there. Thanks
for the quick reaction, and to Dominique and Rainer for their
reports.
Gerald
> I've just merged ubsan into trunk. Please send complaints my way.
Bootstrap is broken on x86_64-apple-darwin10:
Making all in ubsan
make[4]: *** No rule to make target `../interception/libinterception.la',
needed by `libubsan.la'. Stop.
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-
On Fri, Aug 30, 2013 at 12:51 PM, Teresa Johnson wrote:
> On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li wrote:
>> Except that in this form, the dump will be extremely large and not
>> suitable for very large applications.
>
> Yes. I did some measurements for both a fairly large source file t
Hi
I finally generalized this method to other debug functions, it is
more consistent and clean the implementation of the debug checks. For
4.8 branch I will limit it to just what need to be really fixed.
2013-08-30 François Dumont
PR libstdc++/58191
* include/debug/macros.h (
Most of declaration pretty printing functions.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-08-30 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::declaration): Now a virtual
member function.
(c_pretty_printer::declaration_specifiers)
On Fri, Aug 30, 2013 at 9:27 AM, Xinliang David Li wrote:
> Except that in this form, the dump will be extremely large and not
> suitable for very large applications.
Yes. I did some measurements for both a fairly large source file that
is heavily optimized with LIPO and for a simple toy example
On Fri, 2013-08-30 15:36:03 +0200, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 03:26:59PM +0200, Paolo Carlini wrote:
> > On 08/30/2013 02:05 PM, Tim Shen wrote:
> > >+ const _TraitsT&_M_traits;
> > >+ _FlagT _M_flags;
> > >+ bool
On Fri, 2013-08-30 at 10:40 +0200, Richard Biener wrote:
> On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm wrote:
> > * gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
> > (gt_pch_nx (gimple)): Likewise.
> > (gt_pch_nx (gimple, gt_pointer_operator, void *)):
On Fri, 2013-08-30 at 15:44 +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 29 Aug 2013, David Malcolm wrote:
>
> > Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> > testcases show the same results as an unpatched build (relative to
> > r202029).
>
> I'd like to see some sta
On Aug 30, 2013, at 2:02 AM, Uros Bizjak wrote:
> I was looking at annoying
>
> ERROR: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final:
> couldn't compile regular expression pattern: out of memory
Wow… They are amazingly clueless. What part of the mandate, though shall not
claim ou
In all the real-world cases I've seen, the vendor/programmer was
careful to lay out the structs properly. I think if the struct does
not reflect a reasonable (or physically possible) layout, oh well ;-)
On 08/30/2013 06:14 PM, Marek Polacek wrote:
I've just merged ubsan into trunk. Please send complaints my way.
Thanks,
Marek
Just watch the equivalent of this one:
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02869.html
tomorrow morning (substitute "java" for "go" and "ubsan" f
On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
> > Well, it was a wrong decision then. For some smaller types writing manual
> > marker might be a sensible thing, or for some extra complicated
> > constructs. But here we're talking about the most simple struct hierarchy
> > imagin
On Fri, 2013-08-30 at 16:49 +0200, Rainer Orth wrote:
> Torvald Riegel writes:
>
> > On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
> >> On 08/22/2013 02:57 PM, Torvald Riegel wrote:
> >> > On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> >> >> On 08/22/2013 11:39 AM, To
On Fri, Aug 30, 2013 at 9:26 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 09:13:34AM -0700, Easwaran Raman wrote:
>> >> There are more similar failures reported in
>> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 and I have attached
>> >> the updated patch there. Shall I send that for
Hello world,
the attached patch documents the format for unformatted sequential
files and what is, and is not, supported with special files.
Tested with "make dvi" and "make info". OK for trunk?
Thomas
2013-08-30 Thomas Koenig
PR fortran/30162
* gfortran.texi: Docu
On Thu, 29 Aug 2013 11:54:22, Richard Biener wrote:
> On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger
> wrote:
>> The lim pass (aka loop invariant motion) can move conditional expressions
>> with
>> possible undefined behavior out of the if statement inside a loop which may
>> cause the
>> loop
On Fri, Aug 30, 2013 at 09:49:59AM -0700, Easwaran Raman wrote:
> Yes, this is pretty much what I was proposing. The current
> implementation doesn't rely on UIDs being unique - they only have to
> be monotonically non-decreasing. So, when a UID of 0 is encountered,
> go up till a non-zero UID is f
On Fri, Aug 30, 2013 at 09:13:34AM -0700, Easwaran Raman wrote:
> >> There are more similar failures reported in
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 and I have attached
> >> the updated patch there. Shall I send that for review? Apart from the
> >> debug statement issue, almost a
Except that in this form, the dump will be extremely large and not
suitable for very large applications. Besides, we might also want to
use the same machinery (dump_printf_loc etc) for dump file dumping.
The current behavior of using '-details' to turn on opt-info-all
messages for dump files are no
On Fri, Aug 30, 2013 at 10:37 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we
I've just merged ubsan into trunk. Please send complaints my way.
Thanks,
Marek
On Fri, Aug 30, 2013 at 2:31 AM, Jan Hubicka wrote:
>> > The esitmated profile is already there before reading the profile in, so we
>> > only do not want to overwrite it. Does the following work for you?
>>
>> It does get the estimated frequencies on the bbs.
>
> Good.
I ended up making some sl
On Fri, Aug 30, 2013 at 1:25 AM, Richard Biener
wrote:
> On Fri, Aug 30, 2013 at 2:30 AM, Easwaran Raman wrote:
>> Richard,
>> Do you want me to commit everything but the insert_stmt_after hunk
>> now?
>
> Yes.
>
>> There are more similar failures reported in
>> http://gcc.gnu.org/bugzilla/show_
On 08/30/2013 09:13 AM, Meador Inge wrote:
Hi All,
This patch fixes a minor issue that can occur when issuing array bounds
warnings. In GNU C mode we allow empty lists and their upper bound is
initialized to -1. This confuses the array bound analysis in VRP and
in some cases we end up issuing
> Committed as r202101.
This cause a bootstrap failure:
...
libtool: compile: /opt/gcc/build_w/./gcc/xg++ -B/opt/gcc/build_w/./gcc/
-nostdinc++ -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/
On Aug 30, 2013, at 2:38 AM, Marc Glisse wrote:
> There is no undoing here, it is just a recursion that gets very slow for
> nested conditions:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
Gosh, such simple and small code. :-)
On Fri, Aug 30, 2013 at 11:37 AM, Jakub Jelinek wrote:
> Teaching the gengtype parser about
> {struct,class} name : public {struct,class} someothername { ... }
> as opposed to current
> {struct,class} name { ... }
> shouldn't be that hard. And, if the complaint is that we'd need to write
> whole
Torvald Riegel writes:
> On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
>> On 08/22/2013 02:57 PM, Torvald Riegel wrote:
>> > On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
>> >> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
>> >>> +/* Store edi for future HTM fa
On Fri, Aug 30, 2013 at 11:21 AM, Michael Matz wrote:
>
> Hi,
>
> On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
>
> > On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> >
> > >> I thought the principle that was acquired was that gengtype shouldn't
> > >> be improved to support more than what
> >
> > The frequency condition needs to be done only when you walk predecestors -
> > when
> > you walk down the edge probabilities are just fine.
>
> True. For simplicity I think it should be fine to leave as-is so there
> isn't more special casing as the current approach works in both
> direct
Hi,
Following our discussions about changing the frame direction on
aarch64, I have written a small test case using a large frame which
shows similar code generation with and without my patch. There
are small differences in register allocation which lead to larger
prologue/epilogue with my patch,
On Fri, Aug 30, 2013 at 10:21 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
>
>> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>>
>> >> I thought the principle that was acquired was that gengtype shouldn't
>> >> be improved to support more than what it doe
richi,
on further thought, this is going to be a huge task. The problem is at
the edges. right now we share the rep of the array with the tree-csts
and rtl (though the rtl sharing may go away to support canonization).
So if the hwi rep inside of wide int changes then we will have to
impl
Hi,
On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>
> >> I thought the principle that was acquired was that gengtype shouldn't
> >> be improved to support more than what it does now….
> >
> > If it means that we'll need to write and maintai
Can someone review and ok the attached patch for trunk? It has been
bootstrapped and tested on x86-64-unknown-linux-gnu, and tested by
enabling -freorder-blocks-and-partition enabled for a
profiledbootstrap as well.
(Honza, see more responses inlined below. Rong, please see note below as well).
T
On Fri, 2013-08-30 at 09:12 -0500, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> > On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
> >> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
> >>
> >> > And the manual GTY markers are so not main
Hi All,
This patch fixes a minor issue that can occur when issuing array bounds
warnings. In GNU C mode we allow empty lists and their upper bound is
initialized to -1. This confuses the array bound analysis in VRP and
in some cases we end up issuing false positives. This patch fixes
the issue
On 30/08/13 15:03, Tejas Belagod wrote:
> Hi,
>
> The attached patch removes dependency on stdint's macros used in arm_neon.h
> viz.
> UINT64_C() and INT64_C() making arm_neon.h more C++-friendly.
>
> Tested on aarch64-none-elf.
>
> OK for trunk?
>
> Thanks,
> Tejas Belagod.
> ARM.
>
> Chang
Jan Hubicka writes:
>
> Now for longer term, we want to make function CFGs independent of gimple body
> and we want to decide on instrumentation at linktime, so we won't require user
> to rebuild with -fprofile-use, just relink. I plan to work on this, but
> not for 4.9.
It may be already obso
On 08/30/2013 05:06 AM, Paolo Carlini wrote:
I should have explained some of that in better detail. The main issue I
had yesterday, is that the pattern matching can easily become very
difficult if not impossible: if you look at the second half of
expand_default_init, in some cases we wrap the ret
I got nine ICEs in verify_changes for compile/20110401-1.c on ARC.
Fixed by checking changes[i].old before dereferencing it.
Bootstrapped on i686-pc-linux.gnu.
Committed as obvious.
2013-05-20 Joern Rennecke
* recog.c (verify_changes): Verify that changes[i].old is non-zero
On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
>> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
>>
>> > And the manual GTY markers are so not maintainable in the long run,
>> > gengtype or something else really need
On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
>
> > And the manual GTY markers are so not maintainable in the long run,
> > gengtype or something else really needs to be taught to create them
> > automatically.
>
> I thou
On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
> And the manual GTY markers are so not maintainable in the long run,
> gengtype or something else really needs to be taught to create them
> automatically.
I thought the principle that was acquired was that gengtype shouldn't
be improved to s
Hi,
On Thu, 29 Aug 2013, David Malcolm wrote:
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I'd like to see some statistics for cc1{,plus} codesize and for compile
time of something reason
On Fri, Aug 30, 2013 at 03:26:59PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 08/30/2013 02:05 PM, Tim Shen wrote:
> >+ const _TraitsT&_M_traits;
> >+ _FlagT _M_flags;
> >+ bool _M_is_non_matching;
> >+
Sorry for the previous off-the-list-html-format answer :(
On 30 August 2013 15:18, Richard Earnshaw wrote:
> On 30/08/13 14:09, Yvan Roux wrote:
>> Hi,
>>
>> here is a request for comments on the 2 attached patches which enable
>> the build of GCC on ARM with LRA. The patches introduce a new
>>
Hi,
On 08/30/2013 02:05 PM, Tim Shen wrote:
+ const _TraitsT&_M_traits;
+ _FlagT _M_flags;
+ bool _M_is_non_matching;
+ std::set<_CharT> _M_char_set;
+ std::set> _M_range_set;
(resent plain text, sorry)
A documentation comment on the proposed patch.
The issue occurred while building the target libgcc using the cross-gcc,
while cross-building a target-gcc
../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
file or directory
indeed, auto-host.h had
On 30/08/13 14:09, Yvan Roux wrote:
> Hi,
>
> here is a request for comments on the 2 attached patches which enable
> the build of GCC on ARM with LRA. The patches introduce a new
> undocumented option -mlra to use LRA instead of reload, as what was
> done on previous LRA support, which is here t
Sorry, I should not have committed that new test along with this
portion of the patch. Removed as of r202106.
Teresa
On Fri, Aug 30, 2013 at 12:17 AM, Andreas Schwab wrote:
> Teresa Johnson writes:
>
>> Index: testsuite/gcc.dg/inline-dump.c
>>
Hi,
here is a request for comments on the 2 attached patches which enable
the build of GCC on ARM with LRA. The patches introduce a new
undocumented option -mlra to use LRA instead of reload, as what was
done on previous LRA support, which is here to ease the test and
comparison with reload and n
On Fri, Aug 30, 2013 at 02:23:44PM +0200, Marek Polacek wrote:
> I see. For the record, here are the new ChangeLog entries I'm going
> to use when doing the merge.
Ok for trunk, thanks.
> config/ChangeLog
> 2013-08-30 Marek Polacek
>
> * bootstrap-ubsan.mk: New.
>
> gcc/c-family/Chang
On Fri, 30 Aug 2013, Jakub Jelinek wrote:
> Hi!
>
> Apparently I forgot to add code for complete invalidation of everything, if
> more than 100 stmts with vdefs are seen in between immediate dominator and
> current basic block. That cutoff is there so that we don't spend too much
> time on inval
During an LTO/PGO Firefox build one gets countless warnings:
warning: -fprefetch-loop-arrays is not supported with -Os
This happens because flag_prefetch_loop_arrays is always set during the
profile-use phase.
Fix by following the suggestion of Jakub and disable prefetching of
loop_arrays when o
On Fri, Aug 30, 2013 at 10:42:57AM +0200, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 10:38:51AM +0200, Marek Polacek wrote:
> > On Fri, Aug 30, 2013 at 10:15:44AM +0200, Jakub Jelinek wrote:
> > > So, can you please post a new final patch for the merge (with the new
> > > directories
> > > or
Hi!
Apparently I forgot to add code for complete invalidation of everything, if
more than 100 stmts with vdefs are seen in between immediate dominator and
current basic block. That cutoff is there so that we don't spend too much
time on invalidation, but without this patch it actually ignored all
.. the testcase is not Ok. We want separate tests for char and wchar_t,
in separate subdirs with the names 'char' and 'wchar_t'. In this way,
the framework automatically helps us and doesn't try to run the latter
for targets which don't have wchar_t.
Eg, testsuite/21_strings is completely stru
Rewrite matchers using structs instead of closures. It's more clear
and easy to maintain now.
Tested under -m32, -m64 and debug mode.
Thanks!
--
Tim Shen
matchers.patch
Description: Binary data
Hello Sebastian,
That seems like a good idea.
Thanks,
Daniel
On 08/29/2013 01:04 PM, Sebastian Huber wrote:
Recently support for LEON3 specific instructions were added to GCC.
Make this support available for RTEMS.
This patch should be committed to GCC 4.9.
gcc/ChangeLog
2013-08-29 Sebasti
As noted by Kenny and Joern.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-30 Richard Biener
* fold-const.c (fold_single_bit_test): Fix overflow test.
Index: gcc/fold-const.c
===
--- gc
Hi again,
On 08/30/2013 11:06 AM, Paolo Carlini wrote:
I could, for example pass down a separate bit, instead of playing
again with the LOOKUP_* bits. At some point yesterday I even had that
version tested ;)
In practice, something like the attached.
By the way, as regards this comment in cp-
> As you say, some other check might be more appropriate to determine
> whether a call to gen_reg_rtx might be needed in
> emit_move_complex_parts.
> For the PA, it would be something like "GET_MODE_BITSIZE (mode) >
> BITS_PER_WORD".
> But, we still need to check can_create_pseudo_p as we probably
On Tue, Aug 20, 2013 at 1:01 PM, Bernd Edlinger
wrote:
> This patch fixes a bug in the vectorized pointer arithmetic in the forwprop
> optimization pass.
>
> Although it seems to be impossible to create a vector of pointers with the
> __attribute__((vector_size(x))) syntax, the vector loop optimiz
On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
> On 08/22/2013 02:57 PM, Torvald Riegel wrote:
> > On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
> >> On 08/22/2013 11:39 AM, Torvald Riegel wrote:
> >>> + /* Store edi for future HTM fast path retries. We use a stack slot
>
> Please instead remove this assert and put the checking into
> tree-cfg.c:verify_gimple_label where it should need no special-casing
> on cgraph_state.
>
> Otherwise the non-profile bits look ok.
OK, will do.
Thank you!
Honza
Gabriel Dos Reis writes:
> My earlier patch that formally desclared pretty_printer as polymorphic
> uncovered a latent bug in the existing build machinery of the Ada
> component. It had been using xgcc to link against C++ source files. It
> should use xg++ instead.
>
> This patch fixes that by
On Wed, Jun 12, 2013 at 6:04 PM, Jeff Law wrote:
>
> On 06/07/13 03:14, Richard Biener wrote:
>
>>> +/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates
>>> for
>>> + coalescing together, false otherwise.
>>> +
>>> + This must stay consistent with the code in tree-ssa-live.c
On Tue, Jul 2, 2013 at 7:33 PM, DJ Delorie wrote:
>
>> The choice appears to be to continue to have broken volatile bitfields
>> on ARM with no way for users to make them conform to the ABI, or to
>> change things so that they conform to the ABI if you specify
>> -fstrict-volatile-bitfields explic
Hi,
On 08/29/2013 09:37 PM, François Dumont wrote:
Indeed, I check the Standard about const_pointer, so here is another
attempt.
Tested under Linux x86_64.
2013-08-29 François Dumont
PR libstdc++/58148
* include/debug/functions.h (__foreign_iterator_aux4): Use
sequence const_p
On Fri, 30 Aug 2013, Richard Biener wrote:
On Sat, Jun 29, 2013 at 9:02 AM, Marc Glisse wrote:
Hello,
this patch changes the test deciding whether to fold "op d" with both
branches in (a ? b : c) op d. I don't know if the new test is right, it
gives what I expect on the new testcase, but I ma
On Sat, Jul 6, 2013 at 9:42 PM, Marc Glisse wrote:
> Hello,
>
> the first attached patch does not bootstrap and has at least 2 main issues.
> The second patch does pass bootstrap+testsuite, but I liked the first
> more...
>
> First, the fold-const bit causes an assertion failure (building libjava)
> > The esitmated profile is already there before reading the profile in, so we
> > only do not want to overwrite it. Does the following work for you?
>
> It does get the estimated frequencies on the bbs.
Good.
> > We wil also need to solve problem that in this case cgraph edges will have
> >
On Sat, Jun 29, 2013 at 9:02 AM, Marc Glisse wrote:
> Hello,
>
> this patch changes the test deciding whether to fold "op d" with both
> branches in (a ? b : c) op d. I don't know if the new test is right, it
> gives what I expect on the new testcase, but I may have missed important
> cases. Cc: E
On Fri, 30 Aug 2013, Jan Hubicka wrote:
> Hi,
> this patch makes COMDAT profiles right with LTO. (made jointly with Martin
> Liska)
>
> To recap the issue: COMDAT functions are produced many times. Each copy gets
> its own set of counters and depending on inlining and linker decision, one
> or
> Great! Is this the LTO merging you were talking about in an earlier
> message, or the gcov runtime fix (that would presumably not be
> lto-specific)?
It is the LTO path - we need to merge profiles there anyway for his code
unification
work.
> > I have patch to track this. Moreover vforks seem
Hi,
On 08/29/2013 09:40 PM, Jason Merrill wrote:
On 08/29/2013 11:24 AM, Paolo Carlini wrote:
+ if ((complain & tf_error)
+ && (flags & LOOKUP_DELEGATING_CONS)
+ && name == complete_ctor_identifier
+ && TREE_CODE (ret) == CALL_EXPR
+ && (DECL_ABSTRACT_ORIGIN (TREE_OPERAND (
Hello!
I was looking at annoying
ERROR: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final:
couldn't compile regular expression pattern: out of memory
UNRESOLVED: g++.dg/abi/mangle33.C -std=c++98: error executing
dg-final: couldn't compile regular expression pattern: out of memory
ERROR:
Ping:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01624.html
and the related:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00230.html
--
Marc Glisse
Hi,
this patch makes COMDAT profiles right with LTO. (made jointly with Martin
Liska)
To recap the issue: COMDAT functions are produced many times. Each copy gets
its own set of counters and depending on inlining and linker decision, one
or more of copies of a given COMDAT function will get exe
1 - 100 of 117 matches
Mail list logo
