> Hi!
>
> As discussed in the PR, ix86_expand_set_or_movmem assumes that count == 0
> means !CONST_INT_P (count_exp), but that is not necessarily true with
> -O0 -ftree-ter, when the middle-end doesn't immediately see the length
> argument be integer_zerop, yet TER results in it being expanded as
On Mon, May 12, 2014 at 11:22:11PM -0400, Jason Merrill wrote:
> On 04/28/2014 08:37 AM, Mark Wielaard wrote:
> >The debugger cares about the actual underlying type used if the language
> >can use multiple. Either explicitly assigned by the user or implicitly
> >as derived by the language/compile f
On Mon, May 12, 2014 at 03:44:42PM +, Joseph S. Myers wrote:
> On Sun, 11 May 2014, Marek Polacek wrote:
>
> > > FAIL: c-c++-common/pr50459.c -std=gnu++1y (test for excess errors)
> > > FAIL: c-c++-common/pr50459.c -Wc++-compat (test for excess errors)
> > >
> > > The errors are
> > >
> >
On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
> Thanks. Committed the patch @r210351 with changes:
> (1) Create shrink-wrap.h.
> (2) Move all shrink-wrapping related interfaces from function.h to
> shrink-wrap.h.
> (3) shrink-wrap.h is included in function.c, shrink-wrap.c and
> c
I've committed this upstream and will include it into my next updated patch:
+#if defined(__x86_64__) && !defined(_LP64)
+ typedef long long __sanitizer_time_t;
+#else
+ typedef long __sanitizer_time_t;
+#endif
+
struct __sanitizer_timeb {
-long time;
+__sanitizer_time_t time;
un
> On May 13, 2014, at 12:59 AM, Konstantin Serebryany
> wrote:
>
> I've committed this upstream and will include it into my next updated patch:
>
> +#if defined(__x86_64__) && !defined(_LP64)
> + typedef long long __sanitizer_time_t;
> +#else
> + typedef long __sanitizer_time_t;
> +#endif
>
On 13 May 2014 15:55, Marek Polacek wrote:
> On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
>> Thanks. Committed the patch @r210351 with changes:
>> (1) Create shrink-wrap.h.
>> (2) Move all shrink-wrapping related interfaces from function.h to
>> shrink-wrap.h.
>> (3) shrink-wrap
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 once to get a
specific mode.
Say you have to turn SZ off and PR on.
On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
> On 13 May 2014 15:55, Marek Polacek wrote:
> > On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
> >> Thanks. Committed the patch @r210351 with changes:
> >> (1) Create shrink-wrap.h.
> >> (2) Move all shrink-wrapping
On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
> This is the first libsanitizer merge in 4.10 (the last merge was in
> December 2013).
Worked on x86_64-linux and i686-linux (Fedora 20 and 17), bootstrap/regtest
showed no regressions.
Jakub
On Tue, May 13, 2014 at 12:05 PM, wrote:
>
>
>> On May 13, 2014, at 12:59 AM, Konstantin Serebryany
>> wrote:
>>
>> I've committed this upstream and will include it into my next updated patch:
>>
>> +#if defined(__x86_64__) && !defined(_LP64)
>> + typedef long long __sanitizer_time_t;
>> +#els
pins...@gmail.com writes:
>> If this is not enough, please contribute patches directly upstream --
>> I can not accept them from here.
>
>
> I am still against the way Libsanitizer is being maintained. I really think
> the maintainers of the source in gcc should submit the patches upstream and
> n
On Mon, 12 May 2014, Evgeny Stupachenko wrote:
> The test is on general changes. However I was able to test it on x86 only.
> I see 2 possible solutions:
> 1. Set the test for x86 only.
> 2. Modify it so that it will pass on sparc-sun-solaris2.
>
> If 2. is not acceptable I'll create patch for 1.
On 13 May 2014 16:13, Marek Polacek wrote:
> On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
>> On 13 May 2014 15:55, Marek Polacek wrote:
>> > On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
>> >> Thanks. Committed the patch @r210351 with changes:
>> >> (1) Create
Konstantin Serebryany writes:
>> I am still against the way Libsanitizer is being maintained.
>
> I do not enjoy it either. Suggestions are welcome, and see below!
>
>> I really think the maintainers of the source in gcc should submit the
>> patches upstream and not burden the target maintainers
Evgeny Stupachenko writes:
> The test is on general changes. However I was able to test it on x86 only.
> I see 2 possible solutions:
> 1. Set the test for x86 only.
> 2. Modify it so that it will pass on sparc-sun-solaris2.
>
> If 2. is not acceptable I'll create patch for 1.
> Currently I don't
2014-05-13 1:20 GMT+04:00 Jeff Law :
> On 01/14/14 02:15, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> I've been working for some time on the prototype of the Pointer Bounds
>> Checker which uses function clones for instrumentation
>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
>> seve
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
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
>> 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
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
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
>>>
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 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
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
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
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_
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 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
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 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
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 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 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!
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 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://
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
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,
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.
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
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
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,
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
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
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 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
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 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.
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 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
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 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
@@
> 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 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
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 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
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
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
=
> 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 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
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));
>
> Howe
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
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
> 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
> OK, thanks. Richard also gave an RM's OK on IRC so I've now applied it.
Thanks!
--
Eric Botcazou
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
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 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
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 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
> 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, 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
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, 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
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
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 (
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
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
I've backported this patch from trunk at r210395.
-cary
gcc/
* opts.c (finish_options): Use -ggnu-pubnames with -gsplit-dwarf.
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
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
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 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 :-
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 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
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 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
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
> Attached patch passes regression tests and benchmark test. OK for google-4_9?
OK. Thanks again!
-cary
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
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
> 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
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
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
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
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
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_
1 - 100 of 117 matches
Mail list logo
