Teresa Johnson writes:
> Index: testsuite/gcc.dg/inline-dump.c
> ===
> --- testsuite/gcc.dg/inline-dump.c (revision 0)
> +++ testsuite/gcc.dg/inline-dump.c (revision 0)
> @@ -0,0 +1,11 @@
> +/* Verify that -fopt-info can ou
Invariant loads in the inner loop of a vectorized loop nest are not
supported, so make sure we don't run into the code that isn't prepared
to handle them.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-30 Richard Biener
PR tree-optimization/58228
Loop distribution fails to honor output dependences - the following
patch handles them the same as anti dependences. All the code gathering
up dependences is a little weird and probably needs some TLC.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-08-30 Richard B
Once again the vectorizer isn't prepared to vectorize dead code.
Fortunately in this case it's easy to fix - just remove the assert
that triggers and continue doing nothing for the non-existing
use of the reduction result.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2
Hi,
The patch updates vrp pass to handle conditional compare (CCMP).
CCMP is a combine of BIT_AND_EXPR/BIT_IOR_EXPR and CMP expression. The codes
are similar with those to handle BIT_AND_EXPR/BIT_IOR_EXPR and CMP
expression.
When the compare in CCMP can be simplified, CCMP will be converted to a
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 *)): Likewise.
> * gimple.h (gt_ggc_mx (gimple)): Declare.
>
On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher 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.
>
> GIMPLE isn't supposed to end up in a PCH. Can you please make
On Fri, Aug 30, 2013 at 12:02 AM, Kenneth Zadeck
wrote:
> Fixed
>
> FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
>
> on
>
>
> mips64-unknown-linux-gnu
But now this implementation matches how I thought the wide-int encoding
works but not how it does actually work.
For uns
On Tue, Aug 27, 2013 at 04:30:40PM +0200, Marek Polacek wrote:
> On Thu, Aug 22, 2013 at 09:01:57PM +0200, Marek Polacek wrote:
> > On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> > > Ping.
> >
> > I'm withdrawing the ping for now. I'll have to deal with some bootstrap
> > compar
On Fri, Aug 30, 2013 at 10:13:06AM +0200, Marek Polacek wrote:
> On Tue, Aug 27, 2013 at 04:30:40PM +0200, Marek Polacek wrote:
> > On Thu, Aug 22, 2013 at 09:01:57PM +0200, Marek Polacek wrote:
> > > On Thu, Aug 22, 2013 at 07:51:07PM +0200, Marek Polacek wrote:
> > > > Ping.
> > >
> > > I'm with
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 support is added to to track
> down the individual BB, but it
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_bug.cgi?id=57393 and I have attached
> the updated patch there. Sha
On Thu, Aug 29, 2013 at 5:15 PM, Teresa Johnson wrote:
> On Thu, Aug 29, 2013 at 3:04 AM, Richard Biener
> wrote:
> New patch below that removes this global variable, and also outputs
> the node->symbol.order (in square brackets after the function name so
> as to not clutter it). Inli
On Fri, Aug 30, 2013 at 9:51 AM, Zhenqiang Chen wrote:
> Hi,
>
> The patch updates vrp pass to handle conditional compare (CCMP).
>
> CCMP is a combine of BIT_AND_EXPR/BIT_IOR_EXPR and CMP expression. The codes
> are similar with those to handle BIT_AND_EXPR/BIT_IOR_EXPR and CMP
> expression.
Btw
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 *)): Likewise.
> * gimple.h (gt_ggc_mx (gimple)): Declare.
>
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 files in libsanitizer/ just listed in the ChangeLog entries, but not
> >
On Thu, 29 Aug 2013, Mike Stump wrote:
> On Aug 29, 2013, at 12:36 AM, Richard Biener wrote:
> > On Wed, 28 Aug 2013, Mike Stump wrote:
> >
> >> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote:
> >>> Btw, rtl.h still wastes space with
> >>>
> >>> struct GTY((variable_size)) hwivec_def {
> >>
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
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
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:
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 (
> 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
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
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
> > 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, 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)
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
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 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
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
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
>
> 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
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
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
> 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
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 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
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
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
.. 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
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
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
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, 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
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
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
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
>>
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
(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
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;
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
>>
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;
> >+
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 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
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 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
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 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
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 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
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 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
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
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
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
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
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,
> >
> > 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
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
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: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
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 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 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 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
I've just merged ubsan into trunk. Please send complaints my way.
Thanks,
Marek
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
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 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
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 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
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 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
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 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 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
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 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
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 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 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, 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
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)
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 (
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
> 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, 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
> 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, 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
1 - 100 of 117 matches
Mail list logo
