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
> + PR middle-end/60281
Extra line missing
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 b
> 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
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 bootstr
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 merel
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
* tree-vect-data-refs.c (vect_grouped_store_supported): New
check for stores group of length 3.
(vect_per
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
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 applied to GCC 4.9 branch a
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
>
On Fri, Apr 18, 2014 at 06:05:35PM +0800, lin zuojian wrote:
> 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?
No need for that, that was meant
> 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
> implement
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_g
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 Sun, Mar 23, 2014 at 05:13:46PM +0100, Marc Glisse wrote:
> 2014-03-23 Marc Glisse
>
> PR tree-optimization/57742
> gcc/
> * tree-ssa-strlen.c (get_string_length): Ignore malloc.
> (handle_builtin_malloc, handle_builtin_memset): New functions.
> (strlen_optimize
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 ef
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)
> >
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
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 to not d
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
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
wrote:
> Hello,
> Here is another version of fix. This time, I added
> complete_type_or_else call just before aggregate_value_p. Bootstraped
> and t
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 wi
On Thu, Apr 17, 2014 at 11:06 PM, Bill Schmidt
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 not
> adjusted for lit
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 vectorized
On Mon, Jan 6, 2014 at 7:20 AM, Jakub Jelinek 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 smaller.
>>
>
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 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 we do have
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 awa
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 uncondit
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 res
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 pr
On Fri, Apr 18, 2014 at 10:26 AM, Jan Hubicka 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, working
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
Date: Thu Apr 17 09:22:15 2014 -0400
P
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 imple
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
eve
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
represent
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 will
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 a,
> 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
http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64-2
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 avaiabl
> 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 dow
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
On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka 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
> off-noise win o
On Fri, Apr 18, 2014 at 12:51 PM, Jan Hubicka 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 that som
> On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka 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 wrote:
>> On Fri, Apr 18, 2014 at 12:27 PM, Jan Hubicka 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,
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,
>
56 matches
Mail list logo
