Manuel López-Ibáñez wrote:
On 27 November 2014 at 23:58, Tobias Burnus wrote:
Hmm, theoretically, it would be possible. However, my feeling is that there
is no such case. What would be needed is something which is ambiguous, the
compiler assumes first the wrong kind of statement, fails, and ret
On Nov 27, 2014, at 9:28 AM, Andrew Stubbs wrote:
> On 27/11/14 17:05, Mike Stump wrote:
>> Could you include a link or the patch. If the test suite, I'll review it if
>> no one else steps up.
>
> The original patch is here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119.html
Sorry,
On Thu, Nov 27, 2014 at 7:21 PM, Segher Boessenkool
wrote:
> A slight oversight. and3_imm is predicated by rs6000_gen_cell_microcode
> so we had better not generate it otherwise; and in that case, we need to force
> the constant to a register.
>
> Bootstrap and testsuite run are fine (of course,
This work around brings thumb1 bootstrap back. Though I cannot
approve, I would like it in stage 3. A complete fix in thumb1 pattern
will be welcomed.
Thanks,
Joey
On Thu, Nov 20, 2014 at 7:54 PM, Tom de Vries wrote:
> Richard,
>
> This patch fixes PR63718, which currently breaks Thumb1 bootstra
If one of the resulting insns is a noop set it is safe to allow the
combination, for it will never lead to a loop: any following combination
using that noop will delete it. In fact, in most cases combine deletes
the noop immediately; for cc0 targets it does not in some cases, but it
deletes anothe
Currently reg_dead_at_p returns 0 for registers that are set but never
used. This patch repairs that oversight. This fixes PR59278.
2014-11-27 Segher Boessenkool
gcc/
PR rtl-optimization/59278
combine (reg_dead_at_p): Consider REG_UNUSED notes.
---
gcc/combine.c | 3 +++
1
If I2 is a PARALLEL of two SETs, split it into two instructions, I1
and I2. If there already was an I1, rename it to I0. If there
already was an I0, don't do anything.
This surprisingly simple patch is enough to let combine handle such
PARALLELs properly.
v2: Add some functions to make the chec
On 27 November 2014 at 23:58, Tobias Burnus wrote:
> Manuel López-Ibáñez wrote:
>> Sure, but I would like to test specifically triggering and discarding
>> the gfc_warning that I converted (or another single one that you
>> suggest), if this were possible.
>
>
> Hmm, theoretically, it would be pos
Now that LOG_LINKS are per regno, we can distribute them on PARALLELs
just fine. Do so. This makes PARALLELs not lose their LOG_LINKS early
when e.g. a trivial reg-reg move is combined, so that they can be used
in more useful combinations as well.
2014-11-27 Segher Boessenkool
gcc/
[What a great subject line].
This simplifies the code right before the new code of the previous patch
to use one of the new helper functions that introduces.
2014-11-27 Segher Boessenkool
gcc/
* combine.c (try_combine): Use is_parallel_of_n_reg_sets some more.
---
gcc/combine.c |
The first three of these are from the previous series, with hopefully
all comments addressed.
The fourth simplifies the code that breaks up an arith insn with a
compare to zero, using the helpers that the third patch introduced.
The fifth and the sixth are separate from the rest and each other;
t
With this new field in place, we can have LOG_LINKS for insns that set
more than one register and distribute them properly in distribute_links.
This then allows many more PARALLELs to be combined.
Also split off new functions can_combine_{def,use}_p from the
create_log_links function.
v2: Add use
A slight oversight. and3_imm is predicated by rs6000_gen_cell_microcode
so we had better not generate it otherwise; and in that case, we need to force
the constant to a register.
Bootstrap and testsuite run are fine (of course, since this isn't
tested at all); comparing testsuite runs between -mc
On 11 Oct 18:49, Ilya Verbin wrote:
> (run_gcc): Outline options handling into the new functions:
> find_and_merge_options, append_compiler_options, append_linker_options.
> ...
> @@ -625,18 +893,13 @@ run_gcc (unsigned argc, char *argv[])
>/* Look at saved options in the IL files.
On Thursday 2014-11-27 11:09, Kyrill Tkachov wrote:
Thanks for the review. The invoke.texi changes were posted and
approved at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02683.html
and I'm attaching the proposed changes.html patch.
Looks good.
Note that once you have "has been added" and o
On 21 Nov 21:36, Jakub Jelinek wrote:
> On Fri, Nov 21, 2014 at 11:19:26PM +0300, Ilya Verbin wrote:
> > '#pragma omp critical (name)' can be placed in the function, marked
> > with '#pragma omp declare target', in this case the corresponding node
> > should be marked as offloadable too.
> > Bootst
On 27 Nov 16:00, Richard Biener wrote:
> On Thu, Nov 27, 2014 at 2:31 PM, Ilya Verbin wrote:
> > On 25 Nov 10:51, Richard Biener wrote:
> >> In the patch adding flag_generate_offload sounds like a good solution,
> >> I didn't like emitting fat LTO objects unconditionally just because we
> >> offl
Manuel López-Ibáñez wrote:
Oh, I didn't notice that the _now versions override the buffered
messages. Where do you see that?
I think I messed up a bit - they do not seem to get cleared. I was
reading gfc_error_now_1, which has:
error_buffer.flag = 1;
error_buffer.index = 0;
cur_error_b
Hi
Here is a revisited version. I finally go without compiling in
C++11 as I prefer to use __builtin_alloca instead of using
std::unique_ptr and heap memory. I also realized that I could use
codecvt::max_length to know the max number of multibytes.
Tested under Linux x86_64 with all
On 27 November 2014 at 22:33, Manuel López-Ibáñez wrote:
> On 27 November 2014 at 20:28, Tobias Burnus wrote:
>> I think the approach is fine. As the _now version overrides the buffer, one
>> might even do with a single buffer by clearing it, setting flush_p
>> temporarily to true and printing th
Hello!
Yx and Yd register constraints depend on optimize_function_for_speed.
However, optimize_function_for_size is not stable during the
compilation, so this can result in unrecognized insn (as was the case
with *float2_sse insn failure).
The patch uses preferred_for_{size,speed} infrastructure
On Thu, Nov 27, 2014 at 3:19 AM, Uros Bizjak wrote:
> Hello!
>
> Attached patch helps RA to choose the most appropriate PIC register by
> changing the register preference for set_got patterns. Using this
> patch, there should really be a reason for RA to avoid ABI mandated
> hard PIC reg.
>
> This
On 27 November 2014 at 20:28, Tobias Burnus wrote:
> I think the approach is fine. As the _now version overrides the buffer, one
> might even do with a single buffer by clearing it, setting flush_p
> temporarily to true and printing the message. It only might collide with
> buffered warnings (for
Hi all,
this is the second attempt.
I reworked the issues Richard mentioned in the previous review.
I also found one issue which will break build/bootstrap if I pass
--enable-gnu-indirect-function, also fixed.
One thing which came up is the way we generate code for the
armv6*-*-freebsd* triplet
Sorry, missed to add needed hunk to disable pedantic warnings for this testcase.
Committed it as obvious fix at rev 218130.
Kai
On Wed, Nov 12, 2014 at 3:53 PM, H.J. Lu wrote:
> We have been using the wrong register to hold GOT in 64-bit large model,
> which is used by the large model PLT. The only reason we haven't run into
> any problem is linker doesn't support the large model PLT. I am looking
> into linker issue. Th
On Wed, Nov 12, 2014 at 6:53 AM, H.J. Lu wrote:
> We have been using the wrong register to hold GOT in 64-bit large model,
> which is used by the large model PLT. The only reason we haven't run into
> any problem is linker doesn't support the large model PLT. I am looking
> into linker issue. Th
On Wed, Nov 26, 2014 at 9:52 AM, Kai Tietz wrote:
> Ok. Adjusted patch attached. Nevertheless we should use here
> unsigned HWI instead of possible truncation to signed int. I admit
> that it is unlikely to have more then 2^31 elements, but well
>
> Ok for apply with adjusted ChangeLog?
>
On Thu, Nov 27, 2014 at 08:24:03PM +0100, Marek Polacek wrote:
> On Thu, Nov 27, 2014 at 10:56:06AM +0100, Richard Biener wrote:
> > But then rather than using integer_type_node I'd convert to
> > unsigned_type_node (if that doesn't work you know we have some nasty
> > dependence on negative shift
Manuel López-Ibáñez wrote:
* Fortran devs: Is this approach acceptable? The main idea is to have
an output_buffer called pp_warning_buffer with the flush_p bit unset
if we are buffering. When printing buffered warnings, use this
output_buffer in the global_dc->printer instead of the (unbuffered
o
On Thu, Nov 27, 2014 at 10:56:06AM +0100, Richard Biener wrote:
> But then rather than using integer_type_node I'd convert to
> unsigned_type_node (if that doesn't work you know we have some nasty
> dependence on negative shift counts "working")
Yeah, I think adding the conversion into c_gimplify_
On Thu, Nov 27, 2014 at 06:25:01PM +0100, Manuel López-Ibáñez wrote:
>
> The ugliest part is how to handle warningcount and werrorcount. I
> could handle this in the common machinery in a better way by storing
> DK_WERROR in the diagnostic->kind and checking it after printing. This
> way we can fi
2014-11-27 19:55 GMT+03:00 Mike Stump :
> On Nov 26, 2014, at 1:35 AM, Ilya Enkovich wrote:
>> This patch fixes LTO streamers which were not adjusted when function_code
>> field was extended up to 12 bits.
>>
>> OK for trunk after bootstrap and check?
>
> Please could you burry this in a #define
On 27/11/14 17:05, Mike Stump wrote:
Could you include a link or the patch. If the test suite, I'll review it if no
one else steps up.
The original patch is here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119.html
Thanks
Andrew
This is just a RFC so no Changelog yet. It bootstraps and passes the
testsuite. I have three major questions:
* Dodji: Do the common diagnostics part look reasonable? I tried to be
as least invasive as possible. If you have comments or suggestions
they are very welcome.
* Fortran devs: Is this ap
This patch bootstraps fine on x86_64-apple-darwin14 against isl
0.14 at r218098.
Jack
On Wed, Nov 26, 2014 at 10:55 AM, Tobias Burnus
wrote:
> This patch adds a configure check for
> isl_schedule_constraints_compute_schedule,
> which is new in ISL 0.13 - and uses it for conditio
On 11/21/2014 04:21 PM, Martin Liška wrote:
On 11/21/2014 04:02 PM, Richard Biener wrote:
On Fri, Nov 21, 2014 at 3:39 PM, Martin Liška wrote:
Hello.
Ok, this is simplified, one can use sreal a = 12345 and it works ;)
that's a new API, right? There is no max () and I think that using
LON
On Nov 26, 2014, at 4:24 AM, Andrew Stubbs wrote:
> On 14/11/14 11:12, Andrew Stubbs wrote:
>> On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options
On Nov 26, 2014, at 1:35 AM, Ilya Enkovich wrote:
> This patch fixes LTO streamers which were not adjusted when function_code
> field was extended up to 12 bits.
>
> OK for trunk after bootstrap and check?
Please could you burry this in a #define someplace. I think I have a patch
that takes i
On 27/11/14 15:37, H.J. Lu wrote:
On Thu, Nov 27, 2014 at 7:32 AM, Renlin Li wrote:
On 26/11/14 18:12, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote:
On 26/11/14 12:16, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
On 20/11/14 16:17, Renlin Li wrote:
Hi all,
PR63661 is effectively fixed by my previous patch here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html
This patch add a test case for it.
Okay for trunk?
gcc/testsuite/ChangeLog:
2014-11-27 Renlin Li
PR target/63661
* gcc.target/i386/pr63661.c: New.diff --git
On Thu, Nov 27, 2014 at 7:32 AM, Renlin Li wrote:
> On 26/11/14 18:12, H.J. Lu wrote:
>>
>> On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote:
>>>
>>> On 26/11/14 12:16, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
>
> On 20/11/14 16:17, Renlin Li wrote:
>>>
Ping.
Thanks,
Kyrill
On 13/11/14 09:42, Kyrill Tkachov wrote:
Hi all,
Following the trend in i386 and alpha, this patch uses std::swap to
perform swapping of values in the aarch64 backend instead of declaring
temporaries.
Tested and bootstrapped on aarch64-linux.
Ok for trunk?
Thanks,
Kyrill
On 26/11/14 18:12, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote:
On 26/11/14 12:16, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
On 20/11/14 16:17, Renlin Li wrote:
Hi all,
This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC
generates
UN
On Fri, Nov 21, 2014 at 2:32 PM, Patrick Palka wrote:
> On Fri, Nov 21, 2014 at 7:18 AM, Richard Biener
> wrote:
>> On Fri, Nov 21, 2014 at 12:29 PM, Patrick Palka wrote:
>>> When adjusting the value range of an induction variable using SCEV, VRP
>>> calls scev_probably_wraps_p() with use_overfl
On Tue, Nov 25, 2014 at 5:05 PM, H.J. Lu wrote:
> On Tue, Nov 25, 2014 at 7:01 AM, Richard Biener
> wrote:
>> On Tue, Nov 25, 2014 at 1:57 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> The enclosed testcase fails on x86 when compiled with -Os since we pass
>>> a byte parameter with a byte load in caller an
On Thu, Nov 27, 2014 at 3:36 PM, Martin Liška wrote:
> On 11/23/2014 10:01 AM, Markus Trippelsdorf wrote:
>>
>> On 2014.11.22 at 17:46 +0100, Markus Trippelsdorf wrote:
>>>
>>> On 2014.11.22 at 16:04 +0100, Martin Liška wrote:
On 11/22/2014 10:09 AM, Markus Trippelsdorf wrote:
>
On Thu, Nov 27, 2014 at 2:31 PM, Ilya Verbin wrote:
> On 25 Nov 10:51, Richard Biener wrote:
>> In the patch adding flag_generate_offload sounds like a good solution,
>> I didn't like emitting fat LTO objects unconditionally just because we
>> offload.
>
> Here is updated patch. Bootstrap and ma
Ping.
Thanks,
Kyrill
On 11/11/14 11:55, Kyrill Tkachov wrote:
Hi all,
This is the arm implementation of the macro fusion hook.
It tries to fuse movw+movt operations together. It also tries to take
lo_sum RTXs into account since those generate movt instructions as well.
Bootstrapped and tested
Currently the order in which patterns in match.pd match is pretty
random (well, it's deterministic of course). This is bad if there
are multiple possible matches such as in
z = x + 1;
w = z + 0;
where we have both z + 0 -> z and (x + 1) + 0 -> x + (1 + 0).
Currently the latter happens to be
> On 18 November 2014 10:14, David Sherwood wrote:
> > Hi Christophe,
> >
> > Ah sorry. My mistake - it fixes this in bugzilla:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>
> I did look at that PR, but since it has no testcase attached, I was unsure.
> And I am still not :-)
> PR
On 11/23/2014 10:01 AM, Markus Trippelsdorf wrote:
On 2014.11.22 at 17:46 +0100, Markus Trippelsdorf wrote:
On 2014.11.22 at 16:04 +0100, Martin Liška wrote:
On 11/22/2014 10:09 AM, Markus Trippelsdorf wrote:
On 2014.11.22 at 09:05 +0100, Martin Liška wrote:
Following patch removes memory le
On Wed, Nov 26, 2014 at 11:56:26AM -0500, Jason Merrill wrote:
> Please give diagnostics explaining what's wrong with the shift rather than
> the generic "is not a constant expression".
Done.
> >+ tree t = build_int_cst (unsigned_type_node, uprec - 1);
> >+ t = fold_build2 (MINUS_EXPR,
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-11-27 Richard Biener
PR tree-optimization/64088
* tree-ssa-tail-merge.c (update_debug_stmt): After resetting
the stmt break from the loop over use operands.
* gcc.dg/torture/
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-11-27 Richard Biener
PR middle-end/64088
* fold-const.c (const_unop): Re-instantiate missing condition
before calling fold_abs_const.
* gcc.dg/torture/pr64088.c: New testcase
On 11/19/2014 06:01 PM, Marat Zakirov wrote:
Hi all!
Here is the patch which forces ASan to ignore alignment of memory
access. It increases ASan overhead but it's still useful because some
programs like linux kernel often cheat with alignment which may cause
false negatives.
--Marat
gcc/
On Wed, Nov 26, 2014 at 12:03:45PM -0500, Jason Merrill wrote:
> On 11/20/2014 02:04 PM, Marek Polacek wrote:
> >+ if (fun == NULL_TREE)
> >+switch (CALL_EXPR_IFN (t))
> >+ {
> >+ case IFN_UBSAN_NULL:
> >+ case IFN_UBSAN_BOUNDS:
> >+return void_node;
> >+ default:
> >+
On 25 Nov 10:51, Richard Biener wrote:
> In the patch adding flag_generate_offload sounds like a good solution,
> I didn't like emitting fat LTO objects unconditionally just because we
> offload.
Here is updated patch. Bootstrap and make check passed on i686-linux and
x86_64-linux. Tests with o
On Tue, Nov 25, 2014 at 09:59:46PM +0100, Jan Hubicka wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > the interesting symbol in the test case for pr61324 is __GLOBAL__sub_I_s.
> > It
> > refers to nothing, and is called by nothing, however it is kept (I believe
> > because of -fkeep-inlin
Hi all,
We have the following code in aarch64_override_options() function.
/* The selected cpu may be an architecture, so lookup tuning by core
ID. */
if (!selected_tune)
selected_tune = &all_cores[selected_cpu->core];
However, the logic here is not right any more according to our cu
Hello!
Attached patch helps RA to choose the most appropriate PIC register by
changing the register preference for set_got patterns. Using this
patch, there should really be a reason for RA to avoid ABI mandated
hard PIC reg.
This patch avoids many mov %exx,%ebx in front of the calls, that
happen
On 27/11/14 11:09, Kyrill Tkachov wrote:
On 27/11/14 08:52, Ramana Radhakrishnan wrote:
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov wrote:
Hi all,
This patch adds support for the Cortex-A17 processor to the arm backend.
Cortex-A17 is an ARMv7ve core with the same architectural features
On 27/11/14 08:52, Ramana Radhakrishnan wrote:
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov wrote:
Hi all,
This patch adds support for the Cortex-A17 processor to the arm backend.
Cortex-A17 is an ARMv7ve core with the same architectural features as the
Cortex-A7, A12 and A15 cores.
The -m
Well, FWIW, I was able to do "parallel" out-of-tree testing using only
contrib/test_installed and the Makefile from build/gcc/ (plus "touch
config.status" and some fiddling around with paths). Again I needed both
target_triplet and also target_list, but that may be particular to my setup!!
--A
On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel wrote:
>
>
> On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote:
>>
>> On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel
>> wrote:
>>
>>> I think I missed the stage3, Anyway would it be OK for stage1 when it
>>> reopens ?
>>
>>
>> Since you submitte
On Wed, Oct 29, 2014 at 10:20 AM, Jiong Wang wrote:
> On 26/08/14 13:36, Richard Earnshaw wrote:
>
>> On 29/07/14 15:49, Jiong Wang wrote:
>>>
>>> test done
>>> ===
>>> no regression on the full toolchain test on arm-none-eabi.
>>>
>>>
>>> ok to install?
>>
>> Hmm, I think this is wrong for DF mod
On Tue, Nov 18, 2014 at 10:40 AM, Kyrill Tkachov wrote:
> Hi all,
>
> Following up from adding Cortex-A17 support this patch adds a big.LITTLE
> option cortex-a17.cortex-a7.
> Similar to the existing cortex-a15.cortex-a7 support we schedule for
> Cortex-A7 and make the other tuning
> decisions as
On Tue, Nov 11, 2014 at 3:40 PM, Thomas Preud'homme
wrote:
> Fixed the subject.
>
> Best regards,
>
> Thomas
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>> Sent: Tuesday, November 11, 2014 3:31 PM
On Thu, Nov 13, 2014 at 4:03 PM, Thomas Preud'homme
wrote:
> [Taking over Tony's patch]
>
> Ping?
>
> Best regards,
>
> Thomas
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Tony Wang
>> Sent: Thursday, August 21, 2014
On Thu, Nov 27, 2014 at 11:03:20AM +0100, Richard Biener wrote:
> > The testcase shows that when expanding ARRAY_REF from a const static var
> > with initializer that contains COMPOUND_LITERAL_EXPR, we can try to expand
> > COMPOUND_LITERAL_EXPR even when modifier is not EXPAND_INITIALIZER (it is
>
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Thursday, November 27, 2014 9:57 AM
> To: Ramana Radhakrishnan
> Cc: Thomas Preud'homme; 'Jonathan Wakely'; Jakub Jelinek; Tony Wang;
> gcc-patches@gcc.gnu.org; d...@debian.org; aph-
> g...@littlepinkcloud.com;
On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> On Tue, Nov 25, 2014 at 09:20:13AM +0100, Jakub Jelinek wrote:
> > Actually, thinking about it more, at least according to
> > commutative_operand_precedence the canonical order is
> > what we used to return (i.e. (something - _G_O_T_) + (symbol_ref)
> >
On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> The testcase shows that when expanding ARRAY_REF from a const static var
> with initializer that contains COMPOUND_LITERAL_EXPR, we can try to expand
> COMPOUND_LITERAL_EXPR even when modifier is not EXPAND_INITIALIZER (it is
> EXPAND_SUM in tha
On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR and on IRC, the problem here is that peeling
> for alignment can for some linear argument that during vect analysis
> passed simple_iv no longer pass it during vect transform phase.
>
> So, to fix this, this patch remembe
On 27/11/14 10:03, Kyrill Tkachov wrote:
On 26/11/14 10:14, Christophe Lyon wrote:
Hi Kyrill,
Hi Christophe,
On 21 November 2014 at 16:52, Marcus Shawcroft
wrote:
On 17 November 2014 17:35, Kyrill Tkachov wrote:
2014-11-17 Kyrylo Tkachov
* config/aarch64/arm_neon.h (vsqrt_f64
On 26/11/14 10:14, Christophe Lyon wrote:
Hi Kyrill,
Hi Christophe,
On 21 November 2014 at 16:52, Marcus Shawcroft
wrote:
On 17 November 2014 17:35, Kyrill Tkachov wrote:
2014-11-17 Kyrylo Tkachov
* config/aarch64/arm_neon.h (vsqrt_f64): New intrinsic.
2014-11-17 Kyrylo Tkac
On Thu, 27 Nov 2014, Ramana Radhakrishnan wrote:
>
>
> On 27/11/14 09:34, Richard Biener wrote:
> > On Thu, 27 Nov 2014, Thomas Preud'homme wrote:
> >
> > > Thanks. Ccing release manager for their opinion.
> >
> > It doesn't look ARM specific and frankly I have not too much expertise
> > in th
On Thu, 27 Nov 2014, Jakub Jelinek wrote:
> On Thu, Nov 27, 2014 at 10:30:16AM +0100, Richard Biener wrote:
> > On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> >
> > > On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > > > Well, if you want to aggressively prune unused bits then you
On 27/11/14 09:34, Richard Biener wrote:
On Thu, 27 Nov 2014, Thomas Preud'homme wrote:
Thanks. Ccing release manager for their opinion.
It doesn't look ARM specific and frankly I have not too much expertise
in this area. The patch has been on trunk for more than two months
though so I gue
The following allows gimple_fold_stmt_to_constant_1 in SCCVN to follow
SSA edges. This fixes regressions caused by no longer dispatching to
fold_unary from it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-11-27 Richard Biener
* tree-ssa-sccvn
The following fixes an omission from when I introduced the
mark_loop_for_removal abstraction. thread_through_all_blocks still
uses the old way of killing a loop. The following patch fixes this
by not killing it at all (it's just likely that the loop will break
and a loop-fixup is scheduled anywa
On Thu, Nov 27, 2014 at 10:30:16AM +0100, Richard Biener wrote:
> On Wed, 26 Nov 2014, Jakub Jelinek wrote:
>
> > On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > > Well, if you want to aggressively prune unused bits then you could
> > > "back-propagate" the shift count value-r
On 12.11.2014 19:40, Kai Tietz wrote:
> TerminateProcess is actually bad, as it doesn't call any of the atexit
> handlers. You simply nuke the process off. For cygwin this behavior
> is inacceptable. Why a classical abort, or a classical exit call
> cause for you that issues? It seems to me mor
On Thu, 27 Nov 2014, Thomas Preud'homme wrote:
> Thanks. Ccing release manager for their opinion.
It doesn't look ARM specific and frankly I have not too much expertise
in this area. The patch has been on trunk for more than two months
though so I guess it is ok to backport.
Richard.
> Best re
On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > Well, if you want to aggressively prune unused bits then you could
> > "back-propagate" the shift count value-range.
> >
> > And note that all the frontend shorten-optimizations should
Vladimir Makarov writes:
> Mike Meissner pointed me out that my last patch broke PPC bootstrap. I
> submitted a quick fix for it and now I am sending the path after
> bootstrap on ppc is done successfully.
>
> Sorry for the inconvinience.
>
> 2014-11-25 Vladimir Makarov
>
> * ira-li
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov wrote:
> Hi all,
>
> The Cortex-A12 very close to the Cortex-A17 and this patch updates the
> tuning struct
> parameters to match the Cortex-A17 ones.
>
> This has improved performance in a number of benchmarks that I tried.
> The instruction schedul
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds support for the Cortex-A17 processor to the arm backend.
> Cortex-A17 is an ARMv7ve core with the same architectural features as the
> Cortex-A7, A12 and A15 cores.
> The -m{tune, cpu}=cortex-a17 option is added a
Thanks. Ccing release manager for their opinion.
Best regards,
Thomas
> -Original Message-
> From: Jonathan Wakely [mailto:jwak...@redhat.com]
> Sent: Wednesday, November 26, 2014 5:33 PM
> To: Thomas Preud'homme
> Cc: Tony Wang; gcc-patches@gcc.gnu.org; d...@debian.org; aph-
> g...@litt
89 matches
Mail list logo
