This patch fixes PR 65657.
When cfgexpand.c expands a function call, it first figures out the
registers in which the arguments will go, followed by expansion of the
arguments themselves (right to left). It later emits mov insns to set
the precomputed registers with the expanded RTXes.
If one of
On 03/20/2015 11:03 AM, Renlin Li wrote:
Hi all,
This is a simple patch to enable two simplifications for UNSIGNED_FLOAT
expression.
For the following rtx patterns, they can be simplified when the integer
x can be
represented in float mode without precision loss:
float_truncate (float x) --> f
On 03/29/2015 01:30 PM, Sandra Loosemore wrote:
As the outcome of this discussion last month about unexpected behavior
of -fisolate-erroneous-paths-dereference
https://gcc.gnu.org/ml/gcc/2015-02/msg00163.html
Altera has asked us to turn off -fdelete-null-pointer-checks on
nios2-elf targets. Pr
Save an instruction with -mprofile-kernel style profiling and require
the mcount handler to save the LR to the stack.
-mprofile-kernel is an undocumented gcc option that was introduced
specifically for the Linux kernel, so it should be safe to make this
change. When we do add support for this opti
gimplify_init_constructor() only attempts to gimplify a CONSTRUCTOR's
elts under two conditions: if the object has not been zero-initialized,
or if categorize_ctor_elements() detected more than one "nonzero" elt in
the CONSTRUCTOR. With the PR's testcase, both of these conditions are
false: the gi
On 16/04/15 08:32, Jakub Jelinek wrote:
> On Thu, Apr 16, 2015 at 08:27:24AM +1000, Kugan wrote:
>> +if ( == LSHIFTRT)
>> + {
>> +emit_insn (gen_aarch64_lshr_sisd_or_int_3 (operands[0],
>> operands[1], operands[2]));
>
> That is way too long line, please wrap it.
>
>> +
Hi,
I've submitted a patch to bug 62182 [1], and I would like to have some
feedback about it (this is still WIP as noted in the bug).
As it is my first patch to gcc, I'm not sure what is the best way to
discuss/review patches (here or in bugzilla).
Anyway, please let me know your thoughts :)
Arna
On Thu, Apr 16, 2015 at 08:27:24AM +1000, Kugan wrote:
> +if ( == LSHIFTRT)
> + {
> +emit_insn (gen_aarch64_lshr_sisd_or_int_3 (operands[0],
> operands[1], operands[2]));
That is way too long line, please wrap it.
> +DONE;
> + }
>}
> )
>
> @@ -3361,11 +3367,1
On 15/04/15 22:32, Jakub Jelinek wrote:
> On Wed, Apr 15, 2015 at 01:18:36PM +0100, Richard Earnshaw wrote:
>> On 14/04/15 22:41, Kugan wrote:
>>> This patch uses clobber with match_scratch instead of earlyclobber for
>>> aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
>>> selectin
On 15/04/15 21:59, Maxim Kuvyrkov wrote:
>> On Apr 15, 2015, at 12:41 AM, Kugan
>> wrote:
>>
>> This patch uses clobber with match_scratch instead of earlyclobber for
>> aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
>> selecting suitable register, as discussed in
>> http://thread
Currently we clobber objects at the end of the destructor to express
that the language guarantees nothing about the state of storage after an
object is destroyed. The same is true at the other end: when a
constructor begins the object has indeterminate value, so any stores to
the underlying st
The first patch uses get_template_info instead of more verbose code.
The second patch avoids decls with DECL_COMDAT && !TREE_PUBLIC, which
honza has complained about in the past.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6447d3fc822afb4f8fe0d8488a0423cb0240e262
Author: Jason Merril
Here we were getting confused because we push into type_e when parsing
the initializer for type_e::b, but then don't find any 'this' for
resolving the reference to type_e::d. We should allow that in decltype
context, but the code wasn't handling it.
Marek suggested just handling null return f
Hello!
2015-04-15 Uros Bizjak
* config/i386/i386.md (*cmpi_mixed):
Merge with *cmpi_sse using enabled attribute.
(*extendsfdf2_mixed): Merge with *extendsfdf2_sse using enabled
attribute.
(*truncdfsf_fast_mixed): Merge with *truncdfsf_fast_sse using
enabled attribute.
This just moves a few functions around to avoid the need for forward
declarations in an upcoming change towards fixing 47679. This shouldn't
affect code generation in any way shape or form.
Bootstrapped and regression tested on x86_64-linux-gnu. Installed on
the trunk.
jeff
commit a633
> OK to apply ?
Ok.
> gcc/ChangeLog
> 2015-04-15 Nick Clifton
>
> * config/rl78/rl78-opts.h (enum rl78_mul_types): Add MUL_G14 and
> MUL_UNINIT.
> (enum rl78_cpu_type): New.
> * config/rl78/rl78-virt.md (attr valloc): Add divhi and divsi.
> (umulhi3_shift_virt
Hi all,
by accident I patched this pr. For short, when a structure constructor for a
structure with an allocatable component or a function returning a type with an
allocatable component is passed as actual argument to a function, then gfortran
ICEs. This patch fixes, both the ICE and a segfault at
On Wed, 15 Apr 2015, Nicholas Clifton wrote:
The attached patch updates the gcc html documentation to mention the
new RX command line option that I checked in today. Is this patch OK
to apply ?
This looks good to me, thank you!
The only question I have is: where it says "on addresses with
t
Hi Ville,
On Sun, Apr 12, 2015 at 8:24 PM, Ville Voutilainen
wrote:
> The patch is a bit large since it does the baseline_symbols regeneration
> and other new-version api-dance.
> Hence attached gzipped.
>
> Tested on Linux x86-64.
>
> 2015-04-13 Ville Voutilainen
> Add support for std::un
Hi,
Some of the avx512 tests include values.h which is an obsolete header on
Linux which provides compatibility macros based on limits.h and float.h
definitions. On QNX we have no values.h ;), so these tests fail to
build. The include doesn't appear to be needed on Linux, as
x86_64-linux-gnu
> Hi!
>
> When ICF encounteres a GIMPLE_PREDICT (as in the testcase) or GIMPLE_NOP,
> it stops looking at further statements in the bb (assumes they must be the
> same), which is of course wrong.
>
> I'm attaching 3 versions of the patch, the first one I've
> bootstrapped/regtested on x86_64-linu
On 15/04/15 16:41, Jeff Law wrote:
On 04/14/2015 02:07 AM, Kyrill Tkachov wrote:
Hi Jeff,
Thanks for looking at this.
On 13/04/15 19:18, Jeff Law wrote:
On 03/16/2015 04:12 AM, Kyrill Tkachov wrote:
Hi all,
Eyeballing the mult_by_coeff_cost function I think it has a typo/bug.
It's supposed
On 04/14/2015 02:07 AM, Kyrill Tkachov wrote:
Hi Jeff,
Thanks for looking at this.
On 13/04/15 19:18, Jeff Law wrote:
On 03/16/2015 04:12 AM, Kyrill Tkachov wrote:
Hi all,
Eyeballing the mult_by_coeff_cost function I think it has a typo/bug.
It's supposed to return the cost of multiplying by
This patch was originally from Chen Gang S. However, his address at
sunrus.com.cn bounces. So presumably he didn't get the approved
message. I'm checking in the patch for him (with the fixed ChangeLog).
I've verified by hand that the warning goes away with a cross toolchain
and that it do
Hi all,
This patch goes through the arm backend and replaces expressions of the form
a >= lo && a <= hi with IN_RANGE (a, lo, hi) which is that tiny bit smaller
and easier to read in my opinion. I guess there's also a chance it might make
things infinitesimally faster since IN_RANGE evaluates 'a'
On 15/04/15 11:15 -0300, Federico Lenarduzzi wrote:
The idea of this patch is that using this function not depends from a
configuration
flag but depends of a flag which participates in the selection of the
correct multilib.
OK, then I agree it's better to make it conditional on
__cpp_exceptions
> (Not asking for review just yet, JFYI.)
This is not a review! but the patch fixes PR65742.
Dominique
Thanks for comments.
I forgot to mention that this change came of working with the target
fragment file
for the generation of libraries with and without exceptions. After that, the
choice of the multilibs with or without exceptions will depend on the use the
-fno-excepcions flag at the moment of c
On 03-04-15 14:39, Tom de Vries wrote:
On 27-03-15 15:10, Tom de Vries wrote:
Hi,
this patch fixes PR65443, a todo in the parloops pass for function
transform_to_exit_first_loop:
...
TODO: the common case is that latch of the loop is empty and immediately
follows the loop exit. In this
On 15-04-15 15:10, Tom de Vries wrote:
Hi,
This patch series fixes PR65637.
Currently, ssa-handling code in expand_omp_for_static_chunk is dead and not
exercised by testing.
Ssa-handling code in omp-low.c is only triggered by pass_parallelize_loops, and
that pass doesn't specify a chunk size o
Sorry, thought I had responded to this. OK.
Jason
Hi DJ,
The attached patch adds support for the RL78 divide and modulus
capabilities (both as an instruction in G14 cores and as a hardware
peripheral in G13 cores). It also updates the multiply patterns to
add clobbers of the AX and BC registers, which helps fix some reload
problems wit
On 15-04-15 15:10, Tom de Vries wrote:
Hi,
This patch series fixes PR65637.
Currently, ssa-handling code in expand_omp_for_static_chunk is dead and not
exercised by testing.
Ssa-handling code in omp-low.c is only triggered by pass_parallelize_loops, and
that pass doesn't specify a chunk size o
On 15-04-15 15:10, Tom de Vries wrote:
Hi,
This patch series fixes PR65637.
Currently, ssa-handling code in expand_omp_for_static_chunk is dead and not
exercised by testing.
Ssa-handling code in omp-low.c is only triggered by pass_parallelize_loops, and
that pass doesn't specify a chunk size o
Hi,
This patch series fixes PR65637.
Currently, ssa-handling code in expand_omp_for_static_chunk is dead and not
exercised by testing.
Ssa-handling code in omp-low.c is only triggered by pass_parallelize_loops, and
that pass doesn't specify a chunk size on the GIMPLE_OMP_FOR it constructs, s
Yep, looks good.
Jason
On 04/15/2015 08:34 AM, Marek Polacek wrote:
Since r217664 use_new_call is always defined to true, which allows us to
remove a bit of dead code. But maybe you'd prefer to keep that #define,
I don't know.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Now that we're branched, OK.
Jason
Hi,
On 14 April 2015 at 17:36, Vladimir Makarov wrote:
> On 04/14/2015 04:11 AM, Jakub Jelinek wrote:
>>
>> On Tue, Apr 14, 2015 at 10:08:24AM +0200, Yvan Roux wrote:
>>>
>>> --- a/gcc/lra-constraints.c
>>> +++ b/gcc/lra-constraints.c
>>> @@ -1656,8 +1656,7 @@ prohibited_class_reg_set_mode_p (enu
Since r217664 use_new_call is always defined to true, which allows us to
remove a bit of dead code. But maybe you'd prefer to keep that #define,
I don't know.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-04-15 Marek Polacek
* constexpr.c (use_new_call): Remove #define.
On Wed, Apr 15, 2015 at 01:18:36PM +0100, Richard Earnshaw wrote:
> On 14/04/15 22:41, Kugan wrote:
> >This patch uses clobber with match_scratch instead of earlyclobber for
> >aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
> >selecting suitable register, as discussed in
> >http://t
I've bootstrapped and regression tested this patch on x86_64-linux-gnu
and committed it to the trunk.
The bug is latent on the reported target (m68k), so no testcase.
Forwarded Message
Subject: [PATCH][PR rtl-optimization/42522] Incorrect simplification of
ZERO_EXTRACT and
On 14/04/15 22:41, Kugan wrote:
This patch uses clobber with match_scratch instead of earlyclobber for
aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
selecting suitable register, as discussed in
http://thread.gmane.org/gmane.comp.gcc.patches/336162 and reported in
https://gcc.gnu.
> On Apr 15, 2015, at 12:41 AM, Kugan wrote:
>
> This patch uses clobber with match_scratch instead of earlyclobber for
> aarch64_lshr_sisd_or_int_3 so that RA can have more freedom in
> selecting suitable register, as discussed in
> http://thread.gmane.org/gmane.comp.gcc.patches/336162 and repor
> On Apr 15, 2015, at 2:18 PM, James Greenhalgh
> wrote:
>
> On Wed, Apr 15, 2015 at 11:45:36AM +0100, Kugan wrote:
>>> There are two ways I see that we could clean things up, both of which
>>> require some reworking of your patch.
>>>
>>> Either we remove my check above and teach the RTX costs
On 15/04/15 21:18, James Greenhalgh wrote:
> On Wed, Apr 15, 2015 at 11:45:36AM +0100, Kugan wrote:
>>> There are two ways I see that we could clean things up, both of which
>>> require some reworking of your patch.
>>>
>>> Either we remove my check above and teach the RTX costs how to properly
>
On Wed, Apr 15, 2015 at 11:45:36AM +0100, Kugan wrote:
> > There are two ways I see that we could clean things up, both of which
> > require some reworking of your patch.
> >
> > Either we remove my check above and teach the RTX costs how to properly
> > cost vector operations, or we fix my check
On Wed, Apr 15, 2015 at 11:05 AM, Steven Bosscher wrote:
> On Wed, Apr 15, 2015 at 9:53 AM, Kugan wrote:
>> 2015-04-15 Kugan Vivekanandarajah < >
>> Zhenqiang Chen <>
>>
>> PR target/65768
>> * cprop.c (try_replace_reg): Check cost of constants before
>> propagating
On 15/04/15 12:05, James Greenhalgh wrote:
On Wed, Apr 15, 2015 at 11:14:11AM +0100, Kyrill Tkachov wrote:
On 15/04/15 10:25, James Greenhalgh wrote:
On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
Now that Stage1 is open, is this OK for trunk.
Hi Kugan,
diff --git a/gcc/config/aarc
2015-04-14 8:22 GMT+03:00 Jeff Law :
> On 03/15/2015 02:30 PM, Richard Sandiford wrote:
>>
>> Ilya Enkovich writes:
>>>
>>> This patch allows propagation of loop invariants for i386 if propagated
>>> value is a constant to be used in address operand. Bootstrapped and
>>> tested on x86_64-unknown-
On Wed, Apr 15, 2015 at 11:14:11AM +0100, Kyrill Tkachov wrote:
>
> On 15/04/15 10:25, James Greenhalgh wrote:
> > On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
> >> Now that Stage1 is open, is this OK for trunk.
> > Hi Kugan,
> >
> >> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/confi
On 15/04/15 19:25, James Greenhalgh wrote:
> On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
>> Now that Stage1 is open, is this OK for trunk.
>
> Hi Kugan,
>
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index cba3c1a..d6ad0af 100644
>> --- a/gcc/config/
Ping for trunk?
Hale
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Friday, February 27, 2015 4:04 AM
> To: Terry Guo
> Cc: Segher Boessenkool; Richard Sandiford; GCC Patches; Hale Wang
> Subject: Re: Ping : [PATCH] [gcc, combine] PR46164: Don't
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Sivanupandi, Pitchumani
> Sent: Thursday, April 09, 2015 6:26 PM
> To: Georg-Johann Lay; Denis Chertykov
> Cc: GCC Patches; Joerg Wunsch; Selvaraj, Senthil_Kumar
> Subject: RE:
On 15/04/15 10:25, James Greenhalgh wrote:
On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
Now that Stage1 is open, is this OK for trunk.
Hi Kugan,
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index cba3c1a..d6ad0af 100644
--- a/gcc/config/aarch64/aarch64.c
Hi Gerald,
The attached patch updates the gcc html documentation to mention the
new RX command line option that I checked in today. Is this patch OK to
apply ?
Cheers
Nick
Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs
On Wed, 15 Apr 2015, Jakub Jelinek wrote:
> Hi!
>
> When ICF encounteres a GIMPLE_PREDICT (as in the testcase) or GIMPLE_NOP,
> it stops looking at further statements in the bb (assumes they must be the
> same), which is of course wrong.
>
> I'm attaching 3 versions of the patch, the first one I
On Tue, Apr 14, 2015 at 06:14:50PM +0200, Andreas Schwab wrote:
> Please try this patch:
I've tested your patch on x86_64-linux (both normal configure invocation
and the bogus ./configure) and committed to trunk and 5 branch as obvious.
2015-04-15 Andreas Schwab
PR bootstrap/65763
On Tue, Apr 14, 2015 at 11:08:55PM +0100, Kugan wrote:
> Now that Stage1 is open, is this OK for trunk.
Hi Kugan,
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index cba3c1a..d6ad0af 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
>
Hi!
When ICF encounteres a GIMPLE_PREDICT (as in the testcase) or GIMPLE_NOP,
it stops looking at further statements in the bb (assumes they must be the
same), which is of course wrong.
I'm attaching 3 versions of the patch, the first one I've
bootstrapped/regtested on x86_64-linux and i686-linux
On Wed, Apr 15, 2015 at 9:53 AM, Kugan wrote:
> 2015-04-15 Kugan Vivekanandarajah < >
> Zhenqiang Chen <>
>
> PR target/65768
> * cprop.c (try_replace_reg): Check cost of constants before
> propagating.
> +
> + /* For CONSTANT_P (to), loop2_invariant pass might ho
Hi,
On 04/07/2015 05:19 PM, Paolo Carlini wrote:
... thus I prepared the below. I tried to minimize the diagnostic
changes but a few more testcases needed tweaking anyway.
Is this version Ok for the trunk?
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00260.html
Thanks,
Paolo.
Hi,
On 04/15/2015 03:31 AM, Jason Merrill wrote:
Agreed, let's defer this until stage 1.
I note that it's now stage 1. :)
There are various places in the compiler that error and continue if
tf_error is set, but return error_mark_node immediately if not; it
seems reasonable to follow that pa
Committed with a typo-fix in the text, /an list/a list/, and in the change log
/details about implementation/details about the implementation/.
2015-04-14 Matthew Wahab
* doc/extend.texi (__sync Builtins): Simplify some text. Update
details about the implementation. Make cle
On 15/04/15 18:21, Kyrill Tkachov wrote:
> Hi Kugan,
>
> On 15/04/15 08:48, Kugan wrote:
>> As mentioned in PR65768, ARM gcc generates suboptimal code for constant
>> Uses in loop. Part of the reason is that ARM back-end is splitting
>> constants during expansion of RTL, making it hard for the R
Hi Kugan,
On 15/04/15 08:48, Kugan wrote:
As mentioned in PR65768, ARM gcc generates suboptimal code for constant
Uses in loop. Part of the reason is that ARM back-end is splitting
constants during expansion of RTL, making it hard for the RTL
optimization passes to optimize it. Zhenqiang posted
Hello Thomas,
first, thanks for working on an inline version of matmul. (I wonder
whether there is a PR which would be fixed by it; presumably yes.
Secondly, I wonder whether we then still need the version in the
library; if not, can you when the final patch is in update
https://gcc.gnu.org/wiki/
As mentioned in PR65768, ARM gcc generates suboptimal code for constant
Uses in loop. Part of the reason is cprop is undoing what loop invariant
code motion did.
Zhenqiang posted a patch at to fix this based on rtx costs:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html
I cleaned it up an
As mentioned in PR65768, ARM gcc generates suboptimal code for constant
Uses in loop. Part of the reason is that ARM back-end is splitting
constants during expansion of RTL, making it hard for the RTL
optimization passes to optimize it. Zhenqiang posted a patch at
https://gcc.gnu.org/ml/gcc-patches
Hi Guys,
I am applying the attached patch to the RX backend. It adds a new
command line option -mno-allow-string-insns which stops the compiler
from using any of the RX string instructions (SMOVF, SUNTIL, etc).
These instructions are problematic because they are unsafe if used in
the RX
On Tue, 14 Apr 2015, Jonathan Wakely wrote:
> On 14 April 2015 at 13:59, Rainer Orth wrote:
> > Bootstrapped without regressions on i386-pc-solaris2.1[01] and
> > sparc-sun-solaris2.1[01] (with as/ld, gas/gld) on both mainline and
> > gcc-5 branch. Ok for mainline and gcc-5 branch? I suppose the
70 matches
Mail list logo
