On Fri, Apr 18, 2014 at 07:49:22AM +0200, Marc Glisse wrote:
On Fri, 18 Apr 2014, Marek Polacek wrote:
This patch implements a new warning that warns when controlling
expression of a switch has boolean value. (Intentionally I don't
warn if the controlling expression is (un)signed:1
Hi Jakub,
I can take that task over and will boot-strap with all languages and run the
test suite on my armv7-linux-gnueabihf system.
But that will take until next week as it is currently occupied with other tests.
Can you please review Lin's latest patch and give your OK for check-in on trunk
On Fri, Apr 18, 2014 at 08:00:45AM +0200, Marek Polacek wrote:
On Fri, Apr 18, 2014 at 07:49:22AM +0200, Marc Glisse wrote:
On Fri, 18 Apr 2014, Marek Polacek wrote:
This patch implements a new warning that warns when controlling
expression of a switch has boolean value. (Intentionally
On Fri, Apr 18, 2014 at 12:21:50PM +0800, lin zuojian wrote:
Here is the patch after the Jakub's review, and Jakub helps with the
coding style.
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2014-04-18 Lin Zuojian manjian2...@gmail.com
+ PR middle-end/60281
On Fri, Apr 18, 2014 at 07:49:22AM +0200, Marc Glisse wrote:
On Fri, 18 Apr 2014, Marek Polacek wrote:
This patch implements a new warning that warns when controlling
expression of a switch has boolean value. (Intentionally I don't
warn if the controlling expression is (un)signed:1
this is stand alone testcase for that PR.
Comitted to mainline.
...
The test fails on darwin with
/opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr60820_0.c:13:1: warning: alias
definitions not supported in Mach-O; ignored
TIA
Dominique
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd,
I have added the corresponding field, so we can
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01480.html
On Thu, 23 Jan 2014, Marc Glisse wrote:
Hello,
although setting CFLAGS_FOR_TARGET before compiling gcc works fine,
CXXFLAGS_FOR_TARGET is ignored. I don't see any good reason for that.
I tested the patch by doing a regular
Hello,
Here is another version of fix. This time, I added
complete_type_or_else call just before aggregate_value_p. Bootstraped
and tested on x86_64-pc-linux-gnu with no new regressions. Ok to
apply
to trunk?
Thanks, Dinar.
On Mon, Apr 7, 2014 at 11:47 PM, Jason Merrill
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-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely
Hi,
Merged with current master the patch passes bootstrap and is giving
expected gains.
Patch and new tests are attached.
ChangeLog:
2014-04-18 Evgeny Stupachenko evstu...@gmail.com
* tree-vect-data-refs.c (vect_grouped_store_supported): New
check for stores group of length
Hi Jakub,
On Fri, Apr 18, 2014 at 09:09:17AM +0200, Jakub Jelinek wrote:
Extra line missing before the PR line.
Should I post PATCH v9 or someone helps adding one when committing
the patch?
--
Regards
lin zuojian
But for the Solaris 9 stuff, it crystal clear that this cannot occur on
Solaris 10 and up (no single-threaded case anymore since libthread.so.1
has been folded into libc.so.1). Ok to remove this part?
OK for the Solaris 9 - single-threaded part.
--
Eric Botcazou
From: Sebastian Huber sebastian-hu...@web.de
The command line to build a GCC for RTEMS contained virtually always a
'--enable-threads'. This patch helps to avoid this extra configuration
command line parameter and makes the GCC build a bit more user friendly
for RTEMS.
This patch should be
On Wed, Apr 16, 2014 at 03:28:59PM +, Zamyatin, Igor wrote:
Likely after this was checked in appeared following on x86
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (internal
compiler error)
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (test for
Now the question is what does this tell us? Not re-using
the same pseudo as op and target is always better?
I think that generally better is the most appropriate wording, there is even
a specific pass (web.c) to that effect.
--
Eric Botcazou
On 17 April 2014 21:43, François Dumont wrote:
Hi
Here is a patch to globally enhance debug containers implementation.
I have isolated all code of special functions in a base class so that in
C++11 we can use default implementations for the debug containers. This way
implementation
On Wed, Apr 16, 2014 at 10:22:52PM -0400, DJ Delorie wrote:
+ {
+ other_amount
+ = simplify_gen_unary (NEG, GET_MODE (op1),
+ op1, GET_MODE (op1));
+ other_amount
+ = simplify_gen_binary
On Fri, Apr 18, 2014 at 7:30 AM, Marek Polacek wrote:
+ if (TREE_CODE (type) == BOOLEAN_TYPE
+ || exp_code == TRUTH_ANDIF_EXPR
+ || exp_code == TRUTH_AND_EXPR
+ || exp_code == TRUTH_ORIF_EXPR
+ || exp_code == TRUTH_OR_EXPR
+
On Thu, Apr 17, 2014 at 4:00 PM, Michael Matz wrote:
And to have sth that TER not immediately un-does we have
to disable TER which conveniently happens for coalesced
SSA names.
So, instead TER should be improved to not disturb the incoming instruction
order (except where secondary effects of
On Fri, Apr 18, 2014 at 12:11:45PM +0200, Jakub Jelinek wrote:
On Wed, Apr 16, 2014 at 03:28:59PM +, Zamyatin, Igor wrote:
Likely after this was checked in appeared following on x86
FAIL: gcc.dg/vect/vect-simd-clone-11.c -flto -ffat-lto-objects (internal
compiler error)
FAIL:
On Fri, Apr 18, 2014 at 01:33:54PM +0200, Martin Jambor wrote:
I am aware this problem has been reported but my problem is that I
cannot reproduce it anywhere. The tests pass on x86_64 host and the
only i686 host I use is gcc45 on gcc farm where these tests are
skipped. It is very likely
On Fri, 18 Apr 2014, Steven Bosscher wrote:
On Fri, Apr 18, 2014 at 7:30 AM, Marek Polacek wrote:
+ if (TREE_CODE (type) == BOOLEAN_TYPE
+ || exp_code == TRUTH_ANDIF_EXPR
+ || exp_code == TRUTH_AND_EXPR
+ || exp_code == TRUTH_ORIF_EXPR
+
On April 18, 2014 1:30:59 PM CEST, Steven Bosscher stevenb@gmail.com
wrote:
On Thu, Apr 17, 2014 at 4:00 PM, Michael Matz wrote:
And to have sth that TER not immediately un-does we have
to disable TER which conveniently happens for coalesced
SSA names.
So, instead TER should be improved
On Fri, Apr 18, 2014 at 01:20:59PM +0200, Steven Bosscher wrote:
On Fri, Apr 18, 2014 at 7:30 AM, Marek Polacek wrote:
+ if (TREE_CODE (type) == BOOLEAN_TYPE
+ || exp_code == TRUTH_ANDIF_EXPR
+ || exp_code == TRUTH_AND_EXPR
+ || exp_code ==
Sorry for the delayed reply.
On Mon, 2014-03-31 at 09:44 +0200, Christian Bruel wrote:
On 03/30/2014 11:02 PM, Oleg Endo wrote:
Hi,
On Wed, 2014-03-26 at 08:58 +0100, Christian Bruel wrote:
This patches adds a few instructions to the inlined builtin_strlen to
unroll the remaining
I found typo in the testcase header, fixed. Ok to apply to trunk?
thanks, Dinar.
On Fri, Apr 18, 2014 at 1:13 PM, Dinar Temirbulatov
dtemirbula...@gmail.com wrote:
Hello,
Here is another version of fix. This time, I added
complete_type_or_else call just before
On Fri, Apr 18, 2014 at 01:49:36PM +0200, Jakub Jelinek wrote:
It reproduces on x86_64 too, I guess the reason why you aren't seeing this
is that you might have too old assembler that doesn't support
avx2 instructions (you actually don't need avx2 hw to reproduce, any
x86_64 or i686 just with
On Thu, Apr 17, 2014 at 11:06 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
I missed a case in the vector API work for little endian. When VSX is
enabled, the vec_mergeh and vec_mergel interfaces for 4x32 vectors are
translated into xxmrghw and xxmrglw. The patterns for these were
Hi!
This patch fixes the adjustments performed by ipa_simd_modify_function_body
on omp declare simd clones.
Previously we've been trying to replace typically SSA_NAMEs with underlying
PARM_DECLs of the to be replaced arguments with loads/stores from/to
array refs (that will be hopefully
On Mon, Jan 6, 2014 at 7:20 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 04, 2014 at 12:37:57AM +0100, Jakub Jelinek wrote:
That is certainly doable (as attached), but strangely if the patch (that I've
already committed) is reverted and this one applied, the .text savings are
much
On 04/18/2014 08:53 AM, Dinar Temirbulatov wrote:
+ if (TREE_CODE (TREE_TYPE(result)) != VOID_TYPE)
Space after TREE_TYPE. OK with that change.
Jason
Hi,
On 18 aprile 2014 17:20:40 CEST, Jason Merrill ja...@redhat.com wrote:
On 04/18/2014 08:53 AM, Dinar Temirbulatov wrote:
+ if (TREE_CODE (TREE_TYPE(result)) != VOID_TYPE)
Space after TREE_TYPE. OK with that change.
I'm traveling and I can't really check, but I seem to remember that
On 04/18/2014 11:39 AM, Paolo Carlini wrote:
I'm traveling and I can't really check, but I seem to remember that we do have
a VOID_TYPE_P.
True, I suppose that would be preferable.
Jason
Building mainline I got
.../aarch64.c:4879:134: error: invalid conversion from ‘reg_class_t {aka
int}’ to ‘machine_mode’ [-fpermissive]
if (! TARGET_SIMD GET_MODE_SIZE (from) == 128 GET_MODE_SIZE (to) ==
128)
Sure enough, TO and FROM are not modes. Did mainline just change away from
On 04/16/2014 12:55 AM, Eric Botcazou wrote:
Similarly with the HAVE_GNAT_ALTERNATE_STACK stuff. There aren't any
linux hosts that don't support sigaltstack, so why is this
conditionalized?
Hum, I didn't know that Android also used the alternate stack... OK, let's
use it unconditionally
Honza,
Seeing your recent patches relating to inliner heuristics for LTO, I
thought I should mention some related work I'm doing.
By way of introduction, I've recently joined the IBM LTC's PPC Toolchain
team, working on gcc performance.
We have not generally seen good results using LTO on
Hello,
Honza,
Seeing your recent patches relating to inliner heuristics for LTO,
I thought I should mention some related work I'm doing.
By way of introduction, I've recently joined the IBM LTC's PPC
Toolchain team, working on gcc performance.
We have not generally seen good results
Do you witness similar problems with LTO +FDO?
My concern is it can be tricky to get the register pressure estimate
right. The register pressure problem is created by downstream
components (code motions etc) but only exposed by the inliner. If you
want to get it 'right' (i.e., not exposing the
On Fri, Apr 18, 2014 at 10:26 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hello,
Honza,
Seeing your recent patches relating to inliner heuristics for LTO,
I thought I should mention some related work I'm doing.
By way of introduction, I've recently joined the IBM LTC's PPC
Toolchain team,
When building up the internal representation of a conversion, G++ was
trying to apply 'restrict' to void, which doesn't make sense.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 53c6cb04ee081b959788da69d36b8d4db1e3d442
Author: Jason Merrill ja...@redhat.com
Date: Thu Apr 17 09:22:15
On 02/25/2014 04:27 PM, Jason Merrill wrote:
Getting the reference binding rules for C++11 right (in the standard)
has taken quite a few iterations. I'm pretty happy with the latest
wording, which deals with user-defined conversions by recursing on the
result of the conversion. This patch
Thanks for the comments!
On Fri, 18 Apr 2014, Jakub Jelinek wrote:
The passes.def change makes me a little bit nervous, but if it works,
perhaps.
Would you prefer running the pass twice? I thought there would be less
resistance to moving the pass than duplicating it. By the way, I think
Hi,
this patch adds dumping of some summary stats that I used to getnerate
data for
http://hubicka.blogspot.ca/2014/04/devirtualization-in-c-part-5-feedback.html
and found it relatively enlightening, so I think they are useful for mainline,
too.
Bootstrapped/regtested x86_64-linux, comitted.
On Fri, 2014-04-18 at 19:26 +0200, Jan Hubicka wrote:
This is intresting. I sort of planned to add register pressure logic
but always tought it is somewhat hard to do at GIMPLE level in a way
that would work for all CPUs.
Yes, this is just meant to try to measure something that is
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
I agree that an exact estimate of the register pressure would be a
difficult problem. I'm hoping that something that approximates potential
register pressure downstream
Hi,
This patch adds predicates (taken and renamed from the MSP430 backend)
to allow more efficient code generation when accessing volatile memory
turning this (for example):
movwr10, #240
movwax, r10
movwhl, ax
mov a, [hl]
or a, #32
mov [hl], a
into this:
mov
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
On SPEC2k6?
This is quite surprising, for our (well SUSE's) spec testers (AMD64) LTO seems
off-noise win on SPEC2k6
Hi,
this patch makes FDO inliner to be more aggressive on inlining function
calls that are considered hot. This is based on observation that
INLINE_INSNS_AUTO is the most common reason for inlining not happening
(20.5% for Firefox, where 63.2% of calls are not inlinable because body
is not
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
I agree that an exact estimate of the register pressure would be a
difficult problem. I'm hoping that something that approximates potential
register pressure
On 04/18/14 10:02, Richard Henderson wrote:
Building mainline I got
.../aarch64.c:4879:134: error: invalid conversion from ‘reg_class_t {aka int}’
to ‘machine_mode’ [-fpermissive]
if (! TARGET_SIMD GET_MODE_SIZE (from) == 128 GET_MODE_SIZE (to) ==
128)
Sure enough, TO and FROM are
Here's a patch that tidies up diagnostics given when there's
an arithmetic on pointer to an incomplete type. Firstly, we ought not
to say unknown structure when the type is not a structure; secondly,
we shouldn't report identical error twice.
(It might make sense to instead increment/decrement of
On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka hubi...@ucw.cz wrote:
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
On SPEC2k6?
This is quite surprising, for our (well SUSE's) spec testers (AMD64) LTO seems
On Fri, Apr 18, 2014 at 12:51 PM, Jan Hubicka hubi...@ucw.cz wrote:
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
I agree that an exact estimate of the register pressure would be a
difficult problem. I'm hoping
On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka hubi...@ucw.cz wrote:
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
On SPEC2k6?
This is quite surprising, for our (well SUSE's) spec testers (AMD64) LTO
seems
On Fri, Apr 18, 2014 at 2:16 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka hubi...@ucw.cz wrote:
What I've observed on power is that LTO alone reduces performance and
LTO+FDO is not significantly different than FDO alone.
On SPEC2k6?
This is quite
Ping?
On 10/04/14 06:07, Kugan wrote:
Value range propagation simplifies convergence in vrp_visit_phi_node by
setting minimum to TYPE_MIN when the computed minimum is smaller than
the previous minimum. This can however result in pessimistic value
ranges in some cases.
for example,
57 matches
Mail list logo
