On Mon, Nov 17, 2014 at 08:16:32AM +0100, Marek Polacek wrote:
> On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> > According to the next code, 'pretty_name' may need additional bytes more
> > than 16. For simplify thinking and being extensible in future, extent it
> > to 256 bytes, dir
On Fri, Nov 14, 2014 at 06:15:16PM +, Joseph Myers wrote:
> On Fri, 14 Nov 2014, Jakub Jelinek wrote:
>
> > On Fri, Nov 14, 2014 at 09:46:14AM +0300, Yury Gribov wrote:
> > > Hi all,
> > >
> > > This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 by
> > > only
> > > limiting
On 11/15/2014 09:34 PM, H.J. Lu wrote:
GCC uses xstrndup/xstrdup throughout the source tree and those memory
may not be freed explicitly before exut. LeakSanitizer isn't very
useful here. This patch suppresses LeakSanitizer in bootstrap. OK
for trunk?
Right, I think until now everyone just d
On Mon, Nov 17, 2014 at 06:40:26AM +0800, Chen Gang wrote:
> According to the next code, 'pretty_name' may need additional bytes more
> than 16. For simplify thinking and being extensible in future, extent it
> to 256 bytes, directly.
I think + 128 bytes should be enough for everyone.
Mar
PING?
BTW: It seems that Alan's way of improving vld1(q?)_dup intrinsic is more
elegant.
So is the improvement of vcls(q?) vcnt(q?) OK for trunk? Thanks.
>
> Hi,
> This patch converts vcls(q?) vcnt(q?) and vld1(q?)_dup intrinsics to use
> builtin functions instead of the previous inl
On 11/15/14 14:37, Matthew Fortune wrote:
Eric Botcazou writes:
IIRC, fill_eager and its related friends are all speculative in some
way
and aren't those precisely the ones that are causing us problems.
Also
note we have backends working around this stuff in fairly blunt ways:
I'd say tha
From: Zhouyi Zhou
In function build_conflict_bit_table, id is set in objects_live before
traversing that sparseset, so the obj is unnessary compared with itself
during the traversing.
The comparing of obj with itself can be avoided by means of moving
sparseset_set_bit (objects_live, id) afte
On Wed, Nov 12, 2014 at 7:08 PM, Vladimir Makarov wrote:
> After submitting LRA rematerialization patch, I got a lot of
> feedback. Some people reported performance degradation and pointed me
> out the most important problem which looks like
>
> p0 <- p1 + p2 p0 <- p1 + p
Hi,
Refer to the previous small multiply patch (r217175).
The conditions in the small multiply test cases are not restrictive enough.
If forcing the march=armv4t/armv5t, these cases will fail.
These cases can be used only if we defined "
-mcpu=cortex-m0/m1/m0plus.small-multiply ".
This patch is
On Tue, Nov 11, 2014 at 8:22 PM, Michael Meissner
wrote:
> This patch adds 2 tests to the testsuite to make sure the -mupper-regs-df and
> -mupper-regs-sf options work, and you can generate add, subtract, multiply,
> divide, and compare instructions on scalars living in the Altivec registers.
>
On Fri, Nov 14, 2014 at 3:16 PM, Michael Meissner
wrote:
> I tracked down the regression in the spec benchmarks, and it was due to
> turning
> off pre-increment/pre-decrement for floating point values, and these two
> benchmarks use pre-increment/pre-decrement quite a bit. My secondary reload
>
On Tue, Nov 11, 2014 at 8:19 PM, Michael Meissner
wrote:
> This patch documents the previously undocumented -mupper-regs-df and
> -mupper-regs-sf switches. It also provides feature test macros that users can
> use to determine if the upper register support is enabled.
>
> Once the prevous patches
On Tue, Nov 11, 2014 at 8:16 PM, Michael Meissner
wrote:
> This is the big patch that enables the upper regs support. It reorganizes the
> secondary reload handler to try and make it easier to understand, by having a
> variable that says it is done, rather than using cascading if statements. The
On Tue, Nov 11, 2014 at 8:07 PM, Michael Meissner
wrote:
> This patch sets up some of the support that will be needed in the next patch,
> and updates the debug functions. It also adds checks to make sure the upper
> regs support has the other options enabled. Is this patch acceptable to be
> ch
> These three are logically independent, but all on a common theme, and I've
> tested them all together by
>
> bootstrapped + check-gcc on aarch64-none-elf cross-tested check-gcc on
> aarch64_be-none-elf
>
> Ok for trunk?
Hi Alan,
It seems that we are duplicating the work for the vld1_dup
According to the next code, 'pretty_name' may need additional bytes more
than 16. For simplify thinking and being extensible in future, extent it
to 256 bytes, directly.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-17 Chen Gang
* ubsan.c (ubsan_type_descripto
Hi,
this patch updates cgraphunit. One non-trivial case is expand_thunk. Jason, I
think expand_thunk should always inherit optimization/target attributes from
the function it is associated with, right?
Bootstrapped/regtested x86_64-linux.
Honza
* cgraphunit.c (analyze_functions): Use o
Hi,
this patch updates cgraph.c. To make flag_devirtualize fully per-function
basis,
we will need some infastructure to figure out if it is used at all and if
the type inheritance graph construction should be done (or do it
uncondtionally).
Adding proper opt_for_fn tests at least makes it possi
Hi,
many of the IPA passes ignore the fact that optimization attributes can
enable/disable
flags per function granuality. Since this is becoming more of an issue for LTO,
I plan to autit individual passes. This is predict.c that uses global
optimize_size
and I also noticed that probably_never_e
This patch describes some user visible changes that were
added to gcc 5.
Ok to commit?
-Andi
Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.25
diff -u -r1.25 cha
On 11/15/2014 02:04 AM, Martin Jambor wrote:
Hi,
this patch adds very simple propagation of alignment of pointers to
IPA-CP. Because I have not attempted to estimate profitability of
such propagation in any way, it does not do any cloning, just
propagation when the alignment is known and the s
> >The patch also hits a bug in i386's ix86_set_current_function. It is
> >responsible
> >for initializing backend and it does so lazily remembering the previous
> >options
> >backend was initialized for. Pragma parsing however clears the cache
> >that leads
> >to wrong settings being used for subs
On Sun, 16 Nov 2014, Marc Glisse wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse
* tree.c (element_mode, integer_truep): New functions.
* tree.h (element_mode, i
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse
* tree.c (element_mode, integer_truep): New functions.
* tree.h (element_mode, integer_truep): Declare them.
* fol
Hi!
This brings move-if-change in sync with upstream gnulib.
MfG, JBG
2014-11-16 Jan-Benedict Glaw
* move-if-change: Sync from upstream gnulib.
diff --git a/move-if-change b/move-if-change
index e7ba25e..88d9574 100755
--- a/move-if-change
+++ b/move-if-change
@@ -2,13 +2,13 @@
#
This looks like an oversight: the entry for TARGET_FLAGS_REGNUM is located in
the "Passing Arguments in Registers" section of the doc, but it really belongs
in the "Representation of condition codes using registers" section.
Fixed thusly, applied on all active branches as obvious.
2014-11-16
Oing libstdc++@, as required for all libstdc++ patches.
Original patch at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02004.html
This WORK-IN-PROGRESS patch uses an atomic unsigned and futex operations
to optimize the synchronization code in std::future. The current code
uses a mutex/condvar
On Sun, Nov 16, 2014 at 8:52 AM, Richard Biener
wrote:
> On November 16, 2014 5:22:26 AM CET, Patrick Palka
> wrote:
>>On Wed, Nov 12, 2014 at 3:38 AM, Richard Biener
>> wrote:
>>> On Wed, Nov 12, 2014 at 5:17 AM, Patrick Palka
>>wrote:
On Tue, Nov 11, 2014 at 8:48 AM, Richard Biener
Oh, sorry, it is incorrect, original code is already add 2 bytes for it.
Thanks.
On 11/16/2014 10:32 PM, Chen Gang wrote:
> When 'is_str' is true, need consider about 2 '"' for the extra space, or
> will cause memory overflow.
>
> 2014-11-16 Chen Gang
>
> * c-family/c-cppbuiltin.c (bu
When 'is_str' is true, need consider about 2 '"' for the extra space, or
will cause memory overflow.
2014-11-16 Chen Gang
* c-family/c-cppbuiltin.c (builtin_define_with_value): Add two
bytes for avoiding memory overflow issue.
---
gcc/c-family/c-cppbuiltin.c | 2 +-
1 file cha
Hi!
This patch updates the files taken from Automake. Committed.
MfG, JBG
2014-11-16 Jan-Benedict Glaw
* compile: Sync with upstream Automake.
* depcomp: Ditto.
* install-sh: Ditto.
* missing: Ditto.
* mkinstalldirs: Ditto.
* ylwrap: Ditto.
The maximize 64-bits integer decimal string length excluding NUL is 20 (
'-9223372036854775808'), so need use 20 instead of 18 for HOST_WIDE_INT.
2014-11-16 Chen Gang
* c-family/c-cppbuiltin.c (builtin_define_with_int_value): Use
20 instead of 18 for the maximize 64-bits integ
>>> +// Bring the parameters of a function declaration back into
>>> +// scope without entering the function body. The declarator
>>> +// must be a function declarator. The caller is responsible
>>> +// for calling finish_scope.
>>> +void
>>> +push_function_parms (cp_declarator *declarator)
>>
>> I
On November 16, 2014 5:22:26 AM CET, Patrick Palka wrote:
>On Wed, Nov 12, 2014 at 3:38 AM, Richard Biener
> wrote:
>> On Wed, Nov 12, 2014 at 5:17 AM, Patrick Palka
>wrote:
>>> On Tue, Nov 11, 2014 at 8:48 AM, Richard Biener
>>> wrote:
On Tue, Nov 11, 2014 at 1:10 PM, Patrick Palka
> wrote
On November 16, 2014 1:07:59 PM CET, Marc Glisse wrote:
>Hello,
>
>this patch breaks gcc.dg/torture/pr50396.c, and I believe this is a
>symptom of a bigger issue: the HONOR_NANS interface is bad (or at least
>
>the way we are using it is bad). To know if a type honors NaN, we first
>
>get its TYP
On 16 Nov 2014, at 22:18, Segher Boessenkool wrote:
> On Sun, Nov 16, 2014 at 05:45:06PM +0900, Oleg Endo wrote:
>> When you commit those, could you please also add PR 59278 to the ChangeLog so
>> that the commit appears in bugzilla? After your patches are in, I'd like to
>> add some SH specifi
On Sun, Nov 16, 2014 at 05:45:06PM +0900, Oleg Endo wrote:
> When you commit those, could you please also add PR 59278 to the ChangeLog so
> that the commit appears in bugzilla? After your patches are in, I'd like to
> add some SH specific test cases (assuming that your patches fix PR 59278).
It
This WORK-IN-PROGRESS patch uses an atomic unsigned and futex operations
to optimize the synchronization code in std::future. The current code
uses a mutex/condvar combination, which is both slower (e.g., due to
mutex contention, stronger ordering requirements for condvars, using an
additional con
Hello,
this patch breaks gcc.dg/torture/pr50396.c, and I believe this is a
symptom of a bigger issue: the HONOR_NANS interface is bad (or at least
the way we are using it is bad). To know if a type honors NaN, we first
get its TYPE_MODE and then call HONOR_NANS on that. But for vectors that
d
On Nov 16, 2014, at 6:36 PM, Uros Bizjak wrote:
> Hello!
>
> 2014-11-16 Uros Bizjak
>
>* config/sh/sh.c: Do not include algorithm.
>(sh_emit_scc_to_t): Replace open-coded swap with std::swap
>to swap values.
>(sh_emit_compare_and_branch): Ditto.
>(sh_emit_compare_and_se
Hello!
2014-11-16 Uros Bizjak
* config/sh/sh.c: Do not include algorithm.
(sh_emit_scc_to_t): Replace open-coded swap with std::swap
to swap values.
(sh_emit_compare_and_branch): Ditto.
(sh_emit_compare_and_set): Ditto.
* config/sh/sh.md (replacement peephole2): Ditto.
Hi Segher,
On 15 Nov 2014, at 04:19, Segher Boessenkool wrote:
> Here are five patches that together allow combine to do more useful
> work with PARALLELs of two SETs, like on many machines a set of a GPR
> and one of the condition code, or a GPR and the carry bit on PowerPC,
> or two GPRs on so
Add a few testcases which I had floating around in a private tree.
Most of these testcases failed in our private tree at one point due to
local changes. Since it is always good to have more testcases, I
decided to commit them.
I tested all of them on x86_64 with no failures.
Thanks,
Andrew
Chan
43 matches
Mail list logo
