On Tue, May 13, 2014 at 08:13:07PM +0400, Yury Gribov wrote:
> Asan and Tsan allow sanitized applications to tweak runtime behavior
> via API defined in headers in libsanitizer/include/sanitizer. This
> patch adds installation code for these headers and a small test.
>
> Bootstrapped and regtested
On Wed, May 14, 2014 at 9:18 AM, Yury Gribov wrote:
> On 05/14/2014 08:54 AM, Konstantin Serebryany wrote:
>> Shouldn't we just install the entire include/sanitizer directory?
>
> Well, I'd say we should only install headers for components that are
> supported by target platform.
maybe yes. It jus
On 05/14/2014 08:54 AM, Konstantin Serebryany wrote:
> Shouldn't we just install the entire include/sanitizer directory?
Well, I'd say we should only install headers for components that are
supported by target platform.
-Y
> Bootstrapped and regtested on x64.
Forgot to mention: the newly added test currently fails for C because of
C++-isms in asan_interface.h but this should be fixed with next merge
from LLVM.
-Y
Shouldn't we just install the entire include/sanitizer directory?
(And thanks for doing this!!)
On Tue, May 13, 2014 at 8:13 PM, Yury Gribov wrote:
> Hi,
>
> Asan and Tsan allow sanitized applications to tweak runtime behavior via API
> defined in headers in libsanitizer/include/sanitizer. This
[plain text]
On Wed, May 14, 2014 at 2:42 AM, Andrew Pinski wrote:
> On Mon, May 12, 2014 at 4:20 AM, Konstantin Serebryany
> wrote:
>> This is the first libsanitizer merge in 4.10 (the last merge was in
>> December 2013).
>>
>> Tested on Ubuntu 12.04 like this:
>> rm -rf */{*/,}libsanitizer &&
Alan,
Danny may have re-organized the code, but I thought that it originally
came from Tom Rixx, if not earlier.
I seem to remember problems in the past with late creation of TOC
entries for constants causing problems, so it was easier to fall back
to materializing all integer constants inline. I
On Sat, May 10, 2014 at 10:24:34PM -0400, David Edelsohn wrote:
> On Thu, May 8, 2014 at 10:40 PM, Alan Modra wrote:
>
> >> Please do not remove all of the comments from the two functions. The
> >> comments should provide some documentation about the different
> >> purposes of the two functions o
On Mon, 5 May 2014, Jan Hubicka wrote:
> Hi,
> this patch fixes unfortunate thinko in get_class_context that invalidates
> transitions from non-POD type to a polymorphic type that may happen by virtue
> of placement new and apparently breaks openJDK and Qt. I really tried to keep
> placement new in
On Tue, 13 May 2014, Joseph S. Myers wrote:
> On Mon, 12 May 2014, Hans-Peter Nilsson wrote:
> > On Thu, 24 Apr 2014, Jeff Law wrote:
> > > On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
> > > > PR target/60822
> > > > 2014-04-16 Segher Boessenkool
> > > >
> > > > * config/m68k/m68
On 05/13/2014 01:29 PM, Joseph S. Myers wrote:
On Mon, 12 May 2014, Ed Smith-Rowland wrote:
This patch is really a libcpp patch. But UDLs are like that ;-)
Add string user-defined literals and char user-defined literals to the list of
things to look out for while escaping strings in macro arg
On Fri, 2014-05-09 at 15:05 -0400, David Edelsohn wrote:
> On Fri, May 9, 2014 at 2:43 PM, Peter Bergner wrote:
> > gcc/testsuite/
> >
> > * lib/target-support.exp (check_dfp_hw_available): New function.
> > (is-effective-target): Check $arg for dfp_hw.
> > (is-effective-ta
On 05/13/2014 03:41 PM, Richard Sandiford wrote:
Sandra Loosemore writes:
When I was trying to benchmark another patch (which I'll be sending
along shortly) with CSiBE for -mabi=64, I ran into an assembler error
like this:
/tmp/ccJv2faG.s: Assembler messages:
/tmp/ccJv2faG.s:1605: Error: a des
>
> I think the right fix to the problem is to realize that BBs with the
> following conditions y_8 !=0, p.0_10 !=0, and x_5 !=0 are actually
> control equivalent. This fact allows simplifying the USE predicates
> from (y_8 !=0 OR p.0_10 !=0 OR x_5 !=0) into just p.0_10 !=0 which is
> the same as
On Mon, May 12, 2014 at 4:20 AM, Konstantin Serebryany
wrote:
> This is the first libsanitizer merge in 4.10 (the last merge was in
> December 2013).
>
> Tested on Ubuntu 12.04 like this:
> rm -rf */{*/,}libsanitizer && make -j 50
> make -j 40 -C gcc check-g{cc,++}
> RUNTESTFLAGS='--target_board=u
You misunderstood completely: I'm not at all demanding to remove support
for that pragma in the cross-platform part of the docs or even in the
code,
Whew! Ok, that's good. Sorry I went all crazy on you. When I thought
that *was* what you were asking for, I wanted to try to talk you out of it
On Tue, May 13, 2014 at 2:02 AM, Konstantin Serebryany
wrote:
> New patch attached.
> It is based on r208674 which enables LeakSanitizer
> (https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer) by
> default in asan mode.
There are a couple issues for x32:
1. This change
@@ -56,13 +55
I have concerns with the proposed this patch:
1) not sharing cd_root may lead to difficulties in later predication
simplication
2) the change to check post-dom may also lead to incomplete predicate chain.
I think the right fix to the problem is to realize that BBs with the
following conditions y_
On 05/13/14 14:42, Ajit Kumar Agarwal wrote:
Hello Michael:
Resubmitting the Patch with documentation for _break_handler in the
config/microblaze/microblaze.h.
Please put everything together in one place.
When you resubmit a patch, include the ChangeLog.
I'm not sure what you changed, but th
Hello Michael:
Resubmitting the Patch with documentation for _break_handler in the
config/microblaze/microblaze.h.
Thanks & Regards
Ajit
-Original Message-
From: Michael Eager [mailto:ea...@eagercon.com]
Sent: Wednesday, May 14, 2014 12:55 AM
To: Ajit Kumar Agarwal; gcc-patches@gcc.gnu
Sandra Loosemore writes:
> When I was trying to benchmark another patch (which I'll be sending
> along shortly) with CSiBE for -mabi=64, I ran into an assembler error
> like this:
>
> /tmp/ccJv2faG.s: Assembler messages:
> /tmp/ccJv2faG.s:1605: Error: a destination register must be supplied
> `j
On Tue, 2014-05-13 at 09:10 +0100, Joern Rennecke wrote:
> On 12 May 2014 23:39, Oleg Endo wrote:
>
> > This is the same as changing/setting the FP modes (PR, SZ) on SH while
> > preserving the other FPSCR bits, or did I miss something?
>
> It's more like if you have to control multiple bits at
> I don't think that the mechanical change in UI_From_gnu is correct, see the
> comment just above. The annotate_value change is very likely correct, but
> please double check and, upon positive outcome, remove the last sentence of
> the comment just above.
The annotate_value change was wrong, fi
This patch is a follow-up to this thread from a few years ago:
https://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
https://gcc.gnu.org/ml/gcc/2011-01/msg00158.html
As noted there, the current definition of ADJUST_REG_ALLOC_ORDER is
obsolete:
(1) This hook is a holdover from the old pre-IRA regis
When I was trying to benchmark another patch (which I'll be sending
along shortly) with CSiBE for -mabi=64, I ran into an assembler error
like this:
/tmp/ccJv2faG.s: Assembler messages:
/tmp/ccJv2faG.s:1605: Error: a destination register must be supplied
`jalr $31'
Indeed, GCC is generating in
> Attached patch passes regression tests and benchmark test. OK for google-4_9?
OK. Thanks again!
-cary
Patterns that trigger the optimization and warning can form after
inlining, and it can be rather difficult to figure out what exactly is
causing the warning. The inlining context at least provides additional
hints, enabling developers to substitute the arguments and discover
what, precisely, i
On 05/13/14 12:15, Ajit Kumar Agarwal wrote:
Hello Michael:
Thanks for the comments on ChangeLog. Modified ChangeLog is inlined below.
Please resubmit the patch with documentation for _break_handler.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On 05/09/14 01:30, Zhenqiang Chen wrote:
So why restrict this to just cases where we have to propagate into a COMPARE
at the end of a block? So in your example, assume the first block looks
like
prepare_shrink_wrap will move_insn_for_shrink_wrap in BB_INSNS_REVERSE
order. Current prepare_shr
On 05/13/14 02:38, Ilya Enkovich wrote:
propagate constant bounds value and remove checks in called function).
So from a linking standpoint, presumably you have to mangle the instrumented
caller/callee in some manner. Right? Or are you dynamically dispatching
somehow?
Originally the idea wa
Hello Michael:
Thanks for the comments on ChangeLog. Modified ChangeLog is inlined below.
2014-05-13 Ajit Agarwal
* config/microblaze/microblaze.c
(break_handler): New Declaration.
(microblaze_break_function_p,microblaze_is_break_handler) : New function.
(compute_f
On 05/13/14 08:11, Sandra Loosemore wrote:
On 05/05/2014 02:32 PM, Sandra Loosemore wrote:
Ping!
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01618.html
And ping again
As a co-maintainer for the nios2 port, I think this would be something
you could self-approve.
Regardless, approved :-
Attached patch passes regression tests and benchmark test. OK for google-4_9?
Thanks,
Dehao
On Tue, May 13, 2014 at 10:43 AM, Dehao Chen wrote:
> As discussed offline, this is actually due to missing parts of the
> previous patch (some changes does not appear in the change log of
> r199154). I'
On Tue, 13 May 2014, Marek Polacek wrote:
> Here's an attempt to add the -fsanitize=float-cast-overflow
> instrumentation. It should issue a runtime error when a floating-point
> to integer type conversion overflows. Eventually it should instrument
As with divide-by-zero, this should not be par
I've backported this patch from trunk at r210395.
-cary
gcc/
* opts.c (finish_options): Use -ggnu-pubnames with -gsplit-dwarf.
My patch for 60092 failed to consider that we need to avoid obscuring a
capture proxy for 'this', not just 'this' itself.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e40151a986a68e29c169913e36b76fa4310379d7
Author: Jason Merrill
Date: Tue May 13 12:52:37 2014 -0400
PR c++/611
On Tue, May 13, 2014 at 07:38:52PM +0200, Rainer Orth wrote:
> Rainer Orth writes:
>
> > Jakub Jelinek writes:
> >
> >> 2014-04-18 Jakub Jelinek
> >>
> >>PR tree-optimization/60823
> >>* omp-low.c (ipa_simd_modify_function_body): Go through
> >>all SSA_NAMEs and for those refering
On Tue, May 13, 2014 at 07:34:51PM +0200, Eric Botcazou wrote:
> > Even with official release you can apply a patch, that is not the point.
> > The point is that many people expect the release branches (and IMHO rightly
> > so) to be supposedly stable all the time, rather than being seriously
> > u
This patch forces the use of -ggnu-pubnames when using -gsplit-dwarf.
This is necessary so that the gold linker can generate .gdb_index
version 7.
No new regressions. Committed as trivial (has no effect if you're not
using -gsplit-dwarf).
-cary
2014-05-13 Cary Coutant
gcc/
* opts.c (
As discussed offline, this is actually due to missing parts of the
previous patch (some changes does not appear in the change log of
r199154). I've updated the patch to include those missing pieces.
Testing on going.
Dehao
On Tue, May 13, 2014 at 10:04 AM, Cary Coutant wrote:
>> The problem is t
On Tue, 13 May 2014, Rainer Orth wrote:
> right, and that's why I want to keep this info. If it weren't for
> Solaris compatibility, this pragma wouldn't exist, and given that
> heritage, I don't want to encourage its use elsewhere, even though it
> does work.
I can see definite cases where it c
Rainer Orth writes:
> Jakub Jelinek writes:
>
>> 2014-04-18 Jakub Jelinek
>>
>> PR tree-optimization/60823
>> * omp-low.c (ipa_simd_modify_function_body): Go through
>> all SSA_NAMEs and for those refering to vector arguments
>> which are going to be replaced adjust SSA_NA
On Tue, May 13, 2014 at 07:08:01PM +0200, Marek Polacek wrote:
> In essence, the gist of this instrumentation is:
> if (x u<= TYPE_MIN - 1.0 || x u>= TYPE_MAX + 1.0)
> __ubsan_builtin ();
> this checks even +-Inf for free, and because the comparison is
> unordered, it detects even NaNs.
>
> The
> Even with official release you can apply a patch, that is not the point.
> The point is that many people expect the release branches (and IMHO rightly
> so) to be supposedly stable all the time, rather than being seriously
> unstable most of the time and only converging to stability around the
>
On Tue, 13 May 2014, Marek Polacek wrote:
> Yeah, I should've done that in the first place, sorry. Is the
> following ok then?
>
> 2014-05-13 Marek Polacek
>
> * c-c++-common/pr50459.c: Move cdtor tests to a separate testcase.
> * c-c++-common/pr50459-2.c: New test.
OK.
--
Jos
On Tue, 13 May 2014, Marek Polacek wrote:
> Tiny patch, just use available location instead of input_location.
>
> Tested x86_64. Ok?
>
> 2014-05-13 Marek Polacek
>
> PR c/61162
> * c-typeck.c (convert_for_assignment): Pass location to
> WARN_FOR_ASSIGNMENT instead of inpu
On Mon, 12 May 2014, Ed Smith-Rowland wrote:
> This patch is really a libcpp patch. But UDLs are like that ;-)
>
> Add string user-defined literals and char user-defined literals to the list of
> things to look out for while escaping strings in macro args.
>
> I'm not sure how to test this real
This patch ensures everywhere we use std::get we qualify it. It also
changes some uses of the built-in operator& with std::__addressof()
which doesn't do ADL and so doesn't try to complete its argument.
As noted in the bug report, the operator& part of this affects most of
the library, so I don't
On Tue, May 13, 2014 at 07:18:56PM +0200, Eric Botcazou wrote:
> > The point of it is that the release branches are actually used by GCC users,
> > many people don't use just official releases, but arbitrary snapshots from
> > the release branches. If a potentially risky patch is applied immediate
> OK, thanks. Richard also gave an RM's OK on IRC so I've now applied it.
Thanks!
--
Eric Botcazou
> The point of it is that the release branches are actually used by GCC users,
> many people don't use just official releases, but arbitrary snapshots from
> the release branches. If a potentially risky patch is applied immediately
> also to release branches and soon needs follow-ups (happened man
On Mon, 12 May 2014, Hans-Peter Nilsson wrote:
> On Thu, 24 Apr 2014, Jeff Law wrote:
> > On 04/16/14 18:20, seg...@kernel.crashing.org wrote:
> > > PR target/60822
> > > 2014-04-16 Segher Boessenkool
> > >
> > > * config/m68k/m68k.md (extendplussidi): Don't allow memory for
> > > operand 1
Here's an attempt to add the -fsanitize=float-cast-overflow
instrumentation. It should issue a runtime error when a floating-point
to integer type conversion overflows. Eventually it should instrument
even floating-point to floating-point conversions to detect e.g.
(float)1e39 overflow, but I'd l
> The problem is that linemap_location_from_macro_expansion_p will
> always return true if locus has discriminator. And in linemap_lookup,
> this will lead to call linemap_macro_map_lookup, in which there is an
> assertion:
>
> linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
>
> Howe
On 05/13/14 02:14, Ajit Kumar Agarwal wrote:
Hello Michael:
The following patch is to handle Software and Hardware breaks in Microblaze
Architecture.
Deja GNU testcase does not have any regressions and the testcase attached
passes through.
Review comments are incorporated.
Okay for trunk?
J
The problem is that linemap_location_from_macro_expansion_p will
always return true if locus has discriminator. And in linemap_lookup,
this will lead to call linemap_macro_map_lookup, in which there is an
assertion:
linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
However, line is a
> Index: gcc/input.c
> ===
> --- gcc/input.c (revision 210338)
> +++ gcc/input.c (working copy)
> @@ -910,6 +910,8 @@ location_with_discriminator (location_t locus, int
>: next_discriminator_location);
>
>next_discriminator
The previous checkin will break build for most application:
http://gcc.gnu.org/viewcvs/gcc/branches/google/gcc-4_9/gcc/?view=log
This patch fixes the regression by updating highest_location.
Testing on-going,
OK for google-4_9 branch?
Thanks,
Dehao
Index: gcc/input.c
=
Hi,
Asan and Tsan allow sanitized applications to tweak runtime behavior via
API defined in headers in libsanitizer/include/sanitizer. This patch
adds installation code for these headers and a small test.
Bootstrapped and regtested on x64.
-Y
libsanitizer/ChangeLog:
2014-05-13 Yury Gribov
On Mon, 2014-05-05 at 10:18 -0600, Jeff Law wrote:
> On 04/30/14 21:07, David Malcolm wrote:
> > Currently, gengtype does not support template arguments that are
> > explicitly pointers, such as:
> >static GTY(()) vec test_gimple; giving this
> > error:
> >../../src/gcc/gimple-expr.c:902: p
On Tue, May 13, 2014 at 1:39 AM, Richard Biener
wrote:
> On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson wrote:
>> I discovered that the support for the documented -fdump-* options
>> "optimized", "missed", "note" and "optall" was missing. Added that and
>> fixed a minor typo in the documentation.
On Tue, May 13, 2014 at 3:27 PM, David Malcolm wrote:
> On Tue, 2014-05-13 at 15:10 +0200, Richard Biener wrote:
>> On Tue, May 13, 2014 at 2:37 PM, Michael Matz wrote:
>> > Hi,
>> >
>> > On Mon, 12 May 2014, David Malcolm wrote:
>> >
>> >> The "gfoo" type names are pleasantly terse, though I'm a
> I understand that this patch, although target-specific, needs to be
> approved by a global reviewer
Target-specific fragments of build files are generally approved by the
target maintainer. A global maintainer's approval is not required.
> and then propagated to the sourceware.org binutils-gd
On 05/12/2014 11:53 PM, Mike Stump wrote:
I put in one small fix:
Doing diffs in testsuite/objc.dg/ivar-visibility-4.m.~1~:
--- testsuite/objc.dg/ivar-visibility-4.m.~1~ 2014-05-12 12:04:16.0
-0700
+++ testsuite/objc.dg/ivar-visibility-4.m 2014-05-12 13:50:53.0
-0700
@@
On 05/05/2014 02:32 PM, Sandra Loosemore wrote:
Ping!
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01618.html
And ping again
-Sandra
On 12 May 2014 18:14, Jeff Law wrote:
> On 05/12/14 11:10, John Marino wrote:
>>
>> On 5/12/2014 18:59, Jeff Law wrote:
>>>
>>> On 05/09/14 01:14, John Marino wrote:
1) Patch updated online as requested
2) At this exact point in time, we probably can share the files
3) I mi
Hi,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 210052 as r210370. We also have backported Ada AArch64
support as r210372 and 2 other upstream contributions as r210373 and
r210376.
This will be part of our 2014.05 release.
Thanks,
Yvan
On Tue, 2014-05-13 at 15:10 +0200, Richard Biener wrote:
> On Tue, May 13, 2014 at 2:37 PM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 12 May 2014, David Malcolm wrote:
> >
> >> The "gfoo" type names are pleasantly terse, though I'm a little unhappy
> >> about how they no longer match the prefix
On Tue, May 13, 2014 at 1:39 AM, Richard Biener
wrote:
> On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson wrote:
>> I discovered that the support for the documented -fdump-* options
>> "optimized", "missed", "note" and "optall" was missing. Added that and
>> fixed a minor typo in the documentation.
On Tue, May 13, 2014 at 2:37 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 12 May 2014, David Malcolm wrote:
>
>> The "gfoo" type names are pleasantly terse, though I'm a little unhappy
>> about how they no longer match the prefix of the accessor functions e.g.
>> gimple_switch_num_labels (const gsw
On 05/06/14 14:37, Kyrill Tkachov wrote:
Hi all,
This patch removes the NEON builtin functions for vtrn, vzip, vuzp and their
associated wiring and machine descriptions. The builtins were initially used to
implement the corresponding intrinsics in arm_neon.h but those have since been
reimplement
Ping.
Thanks,
Kyrill
On 06/05/14 14:37, Kyrill Tkachov wrote:
Hi all,
This patch removes the NEON builtin functions for vtrn, vzip, vuzp and their
associated wiring and machine descriptions. The builtins were initially used to
implement the corresponding intrinsics in arm_neon.h but those have
On 25/03/14 08:13, Zhenqiang Chen wrote:
> Hi
>
> The patch enables shrink-wrap for apcs frame.
>
> Bootstrap and no make check regression in ARM, THUMB1 and THUMB2 modes.
> No make check regression with "-g/-mapcs/-marm".
> Build linux-3.14-rc7 without error.
>
> Is it OK for next stage1?
>
>
On Mon, May 12, 2014 at 01:19:37PM +0200, Georg-Johann Lay wrote:
> Am 04/18/2014 11:52 AM, schrieb Senthil Kumar Selvaraj:
> >
> >On Sat, Apr 12, 2014 at 06:36:01PM +0200, Georg-Johann Lay wrote:
> >>Senthil Kumar Selvaraj schrieb:
> >>>This patch modifies AVR target's ASM spec to pass -mlink-rela
Hi,
On Mon, 12 May 2014, David Malcolm wrote:
> The "gfoo" type names are pleasantly terse, though I'm a little unhappy
> about how they no longer match the prefix of the accessor functions e.g.
> gimple_switch_num_labels (const gswitch *gs)
> vs
> gimple_switch_num_labels (const gimple_switc
Prompted by the recent failures of c-c++-common/gomp/pr60823-2.c on
Solaris/x86 with Sun as
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00943.html
I've reworked the clearing of hardware capabilities via linker maps for
Sun ld, which is currently replicated in several places all over the
Hi David,
> Thank you for taking the time to review this.
>
>>> the current text makes reference to "compatibility with the Solaris system
>>> headers," the remaining pragma is (according to the existing text)
>>> "currently on all platforms." This makes referring to Solaris both
>>> superfluous
My fix for PR 60497 didn't cover the rvalue overloads of std::get.
I also noticed we don't handle comparisons properly if tuple elements
have perverse overloaded comparison operators.
Tested x86_64-linux, committed to trunk.
commit 0f87ec2cdf390a1234a8562e6b3aba95182a6951
Author: Jonathan Wakely
Thank you for taking the time to review this.
the current text makes reference to "compatibility with the Solaris system
headers," the remaining pragma is (according to the existing text)
"currently on all platforms." This makes referring to Solaris both
superfluous and potentially confusing.
As discussed in the PR, tailcall settings have to be cleared by
the inliner.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and 4.9 branch.
Richard.
2014-05-13 Richard Biener
PR ipa/60973
* tree-inline.c (remap_gimple_stmt): Clear tail call flag,
On Tue, May 13, 2014 at 4:59 PM, Richard Biener
wrote:
> On Sun, May 11, 2014 at 2:49 PM, Bin.Cheng wrote:
>> On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng wrote:
>>> On Tue, May 6, 2014 at 6:44 PM, Richard Biener
>>> wrote:
On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote:
> On Fri, Dec
On Tue, May 13, 2014 at 11:18 AM, Ilya Tocar wrote:
>> > This patch add support for xsavec, xsaves ISA extensions, introduced in
>> > [1], and clflushopt introduced in [2].
>> >
>> > [1]http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
>> > [2]http://
After reading the code in regcprop.c, I think I should reuse the
copyprop_hardreg_forward_1. So rewrite the patch, which is much simple
and should handle HAVE_cc0. But not sure we'd handle DEBUG_INSN or
not.
2014-05-13 Zhenqiang Chen
* regcprop.c (skip_debug_insn_p): New decl.
On 9 May 2014 14:08, Jeff Law wrote:
> On 05/08/14 02:07, Zhenqiang Chen wrote:
>>
>> Hi,
>>
>> The patch splits the live_edge for move_insn_for_shrink_wrap to sink
>> the copy out of the entry block.
>>
>> Bootstrap and no make check regression on X86-64 and ARM.
>>
>> OK for trunk?
>>
>> Thanks!
On Tue, May 13, 2014 at 8:41 AM, wrote:
> From: Trevor Saunders
>
> This implements finalizers by keeping a list of registered finalizers
> and after every mark but before sweeping check to see if any of them are
> for unmarked blocks.
>
> This uses the two vector and forward iteration approach
On Tue, May 13, 2014 at 8:41 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> basically this patch is unchanged from the last time I sent this series,
> except
> I reordered the includes in rtl.c to have ggc.h come before vec.h because
> vec.h
> declares some functions from ggc.h if building a b
On 12 May 15:42, Uros Bizjak wrote:
> On Mon, May 12, 2014 at 3:25 PM, Ilya Tocar wrote:
>
> > This patch add support for xsavec, xsaves ISA extensions, introduced in
> > [1], and clflushopt introduced in [2].
> >
> > [1]http://www.intel.com/content/www/us/en/processors/architectures-software-dev
Hello Michael:
The following patch is to handle Software and Hardware breaks in Microblaze
Architecture.
Deja GNU testcase does not have any regressions and the testcase attached
passes through.
Review comments are incorporated.
Okay for trunk?
Thanks & Regards
Ajit
From 15dfaee8feef37430745d
On Mon, May 12, 2014 at 5:42 AM, Patrick Palka wrote:
> Hi,
>
> This patch fixes a bogus warning generated by -Wmaybe-uninitialized.
> The problem is that we sometimes fail to acknowledge a defining edge
> belonging to a control-dependence chain because we assume that each
> defining edge shares t
On Sun, May 11, 2014 at 2:49 PM, Bin.Cheng wrote:
> On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng wrote:
>> On Tue, May 6, 2014 at 6:44 PM, Richard Biener
>> wrote:
>>> On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote:
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
wrote:
>>
Hi,
>>>
On Sat, May 10, 2014 at 9:25 PM, Richard Sandiford
wrote:
> While testing another patch, I hit cases where Ada was building or
> folding additions involving integer_one_node without converting
> it to the type of the other operand. This looked unintentional,
> since all other uses of integer_one_
Your current policy seems to massively impede contributions.
How? (BTW, I am not the one who sets these policies and discussing
them with me makes little sense)
I think people are mainly worried with checking out Clang, making it to
build (install Cmake, C++11-friendly compiler, etc.), then ma
Konstantin Serebryany writes:
>>> other than by following the standard process because this will violate
>>> the LLVM developer policy.
>>
>> Which says what?
>
> http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
>
> "Once your patch is ready, submit it by emailing it to the
On Sat, May 10, 2014 at 9:19 PM, Richard Sandiford
wrote:
> get_addr_base_and_unit_offset_1 and get_ref_base_and_extent have similar
> code to handle array indices. The code in tree-dfa.c extends from the
> precision of the index, as before wide-int, but the tree-dfa.h version
> was updated in a
Jakub Jelinek writes:
> 2014-04-18 Jakub Jelinek
>
> PR tree-optimization/60823
> * omp-low.c (ipa_simd_modify_function_body): Go through
> all SSA_NAMEs and for those refering to vector arguments
> which are going to be replaced adjust SSA_NAME_VAR and,
> if it i
On Fri, May 9, 2014 at 10:30 PM, Jeff Law wrote:
> On 04/25/14 05:39, Prathamesh Kulkarni wrote:
>>
>> On Thu, Apr 24, 2014 at 9:18 PM, Diego Novillo
>> wrote:
>>>
>>> Please remember to send patches to gcc-patches.
>>>
>>> I'm wondering if you couldn't just use std::string here. No need to
>>>
On 12/05/14 17:30, Ian Bolton wrote:
> Currently, on AArch64, when a caller-save register is saved/restored,
> GCC is accessing the maximum size of the hard register.
>
> So an SImode integer (4 bytes) value is being stored as DImode (8 bytes)
> because the int registers are 8 bytes wide, and an S
>> other than by following the standard process because this will violate
>> the LLVM developer policy.
>
> Which says what?
http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
"Once your patch is ready, submit it by emailing it to the appropriate
project’s commit mailing list
Wei Mi writes:
> Thanks for trying the testcase. rtl scanning will be slightly better
> than assembly scanning. So how about this one?
This one works fine for me.
Thanks.
Rainer
--
-
Rainer Orth, Center for Bi
On Fri, May 9, 2014 at 5:54 PM, Teresa Johnson wrote:
> I discovered that the support for the documented -fdump-* options
> "optimized", "missed", "note" and "optall" was missing. Added that and
> fixed a minor typo in the documentation.
>
> Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok
1 - 100 of 117 matches
Mail list logo
