Update plugin document after switching to C++, also make it more friendly to
cross-build.
ChangeLog:
2014-01-08 Joey Ye
doc/plugin.texi (Building GCC plugins): Update to C++.
OK to trunk?
diff --git a/gcc/doc/plugins.texi b/gcc/doc/plugins.texi
index fc2d754..e668de6 100644
--- a/gcc/
> Committed after private email approval from Jakub. I made one
> additional trivial change (missing whitespace in a comment).
This breaks bootstrap with RTL checking enabled:
/home/eric/svn/gcc/libgcc/config/libbid/bid64_noncomp.c:119:1: internal
compiler error: RTL check: expected code 'set'
Hi Bernd,
The patch is OK to me. But do we need reorder_loops for the c6x backend ?
I mean we can set the do_reorder parameter to FALSE to save compile
time, since c6x backend only choose hw-doloops whose body contains only one
basic block.
Cheers,
Felix
>
> On 01/05/2014 05:10 P
On Tue, 7 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 07, 2014 at 04:12:57PM +0100, Richard Biener wrote:
> > > What about if something post gimplification creates VCE(BFR(VCE())) or
> > > similar and tries to force_gimple_operand_gsi or similar, then without
> > > making the above invalid in the
All,
I was looking at PR49718. I have enclosed a simple fix for this bug report.
2014-01-07 Laurent Alfonsi
* c-family/c-common.c (handle_no_instrument_function_attribute): Allow
no_instrument_function attribute in class member
definition/declaration.
Looking at the implemen
On 7 January 2014 19:36, Tim Shen wrote:
>
> I didn't noticed that's so time consuming. I think reducing the
> compile time is possible (by templating several member functions
> instead of whole _Compiler<> class).
Ouch! Yes, that's quite a bit slower, and this code is already very
slow to compile
Hi!
The recent change to get_mode_bounds for partial mode, where
GET_MODE_PRECISION instead of GET_MODE_SIZE is now used, has broken
ia64 bootstrap. The problem is that BImode is special cased in various
places, e.g. trunc_int_for_mode, so the two values of the mode are
0 and STORE_FLAG_VALUE (wh
Joey Ye wrote:
>ChangeLog:
>2014-01-08 Joey Ye
>doc/plugin.texi (Building GCC plugins): Update to C++.
>
>OK to trunk?
Okay unless anyone raises concrete issues in the next couple of days (or
approves directly, of course).
Thanks,
Gerald
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> The recent change to get_mode_bounds for partial mode, where
> GET_MODE_PRECISION instead of GET_MODE_SIZE is now used, has broken
> ia64 bootstrap. The problem is that BImode is special cased in various
> places, e.g. trunc_int_for_mode, so the
On 27 December 2013 18:27, François Dumont wrote:
> Hi
>
> Here is a patch to fix an issue in normal mode during the move
> assignment. The destination vector allocator instance is moved too during
> the assignment which is wrong.
Thanks for your patience, the normal-mode fix is definitely cor
Hi,
On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
On 7 January 2014 19:36, Tim Shen wrote:
I didn't noticed that's so time consuming. I think reducing the
compile time is possible (by templating several member functions
instead of whole _Compiler<> class).
Ouch! Yes, that's quite a bit slower
Fix trunk plugin build by adding missing headers and remove headers no
longer exist.
Test passed:
- arm-none-eabi build --enable-plugins
- build test plugin
- x86_64 bootstrap --enable-plugins
OK to trunk?
ChangeLog.gcc
2013-11-19 Joey Ye
PR plugin/59335
* Makefile.i
On 07/01/14 21:06, Andrew Pinski wrote:
> On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law wrote:
>> On 01/07/14 09:16, Bernd Schmidt wrote:
>>>
>>> This is PR56791. The address inside of an autoinc is reloaded, and the
>>> autoinc is reloaded, but the reload insns are emitted in the wrong order.
>>>
>>>
On Wed, 8 Jan 2014, Kugan wrote:
>
> On 07/01/14 23:23, Richard Biener wrote:
> > On Tue, 7 Jan 2014, Kugan wrote:
>
> [snip]
>
>
> > Note that VIEW_CONVERT_EXPR is wrong here. I think you are
> > handling this wrong still. From a quick look you want to avoid
> > the actual promotion for
> >
On Tue, 7 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Jan 03, 2014 at 11:33:50AM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
>
> Anyway, back to the original patch, so do you prefer something like
> this instead? I.e. handle only __builti
On Wed, Jan 08, 2014 at 12:10:13AM +, Andrew Pinski wrote:
> On Tue, Jan 7, 2014 at 4:05 PM, Marcus Shawcroft
> wrote:
> >
> > Andrew, We know that there are numerous issues with aarch64 BE advsimd
> > support in GCC. The aarch64_be support is very much a work in progress.
> > Tejas sorted
On 01/07/2014 08:36 PM, Tim Shen wrote:
On Tue, Jan 7, 2014 at 4:02 AM, Paolo Carlini wrote:
Ideally, I would suggest committing first the improvements in your previous
patch (by the way, thanks for the numbers!) + the pure bug fixes and
separate the further performance improvements which have
On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> I prefer to always do this, not do the fancy insertion-before. That
> would do repeated folding for
>
>fold_stmt (gsi);
>fold_stmt (gsi);
>fold_stmt (gsi);
>
> where the last two should be a no-op.
I don't see how is
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> > I prefer to always do this, not do the fancy insertion-before. That
> > would do repeated folding for
> >
> >fold_stmt (gsi);
> >fold_stmt (gsi);
> >fold_stmt (gsi);
> >
>
On Wed, 8 Jan 2014, Richard Biener wrote:
> On Wed, 8 Jan 2014, Jakub Jelinek wrote:
>
> > On Wed, Jan 08, 2014 at 11:45:28AM +0100, Richard Biener wrote:
> > > I prefer to always do this, not do the fancy insertion-before. That
> > > would do repeated folding for
> > >
> > >fold_stmt (gsi)
On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > I start to think this is a too complex transform for stmt folding ...
>
> Alternatively do update_call_from_tree (gsi, get_or_create_ssa_default_def
> (cfun, create_tmp_var (TREE_TYPE (lhs.
The lhs might not be is_gimple_reg
On Wed, 8 Jan 2014, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > > I start to think this is a too complex transform for stmt folding ...
> >
> > Alternatively do update_call_from_tree (gsi, get_or_create_ssa_default_def
> > (cfun, create_tmp_var (TRE
On Tue, Jan 7, 2014 at 5:31 PM, Bernd Edlinger
wrote:
> Hello,
>
> Ping...
>
> We still need a decision how to fix this.
>
> There are two alternative patches:
>
> 1. My latest proposal: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01675.html
>
> 2. Eric's latest proposal:
> http://gcc.gnu.org/ml
On Tue, Jan 7, 2014 at 7:27 PM, Martin Jambor wrote:
> Hi,
>
> I forgot to put the optimize test to the ipa_compute_jump_functions
> when fixing PR 57358 which is where it is most necessary. This patch
> adds it there and to parm_preserved_before_stmt_p which is also
> reachable through ipa_load_
On Tue, Jan 7, 2014 at 8:39 PM, Jakub Jelinek wrote:
> On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>> Of course, IMO, the cleanest fix would be to use switchable targets
>> for i386...
>
> The following patch does that, bootstrapped/regtested on x86_64-linux and
> i686-linux
On Tue, Jan 07, 2014 at 09:35:54PM +, Mike Stump wrote:
> On Dec 17, 2013, at 6:06 AM, Vidya Praveen wrote:
> > bind_pic_locally is broken for targets that doesn't pass -fPIC/-fpic by
> > default [1][2].
>
> Let's give Jakub 2 days to weigh in? If no objections, Ok, though, do see
> about a
On 27 December 2013 18:30, François Dumont wrote:
> Hi
>
> Here is a patch to add recycling of Rb tree nodes when possible.
The change looks good, but it is not a bug fix, so I don't think it's
suitable for Stage 3. Please re-submit this after 4.9 is released
when we are in Stage 1 again, tha
On Wed, Jan 08, 2014 at 11:49:08AM +, Vidya Praveen wrote:
> On Tue, Jan 07, 2014 at 09:35:54PM +, Mike Stump wrote:
> > On Dec 17, 2013, at 6:06 AM, Vidya Praveen wrote:
> > > bind_pic_locally is broken for targets that doesn't pass -fPIC/-fpic by
> > > default [1][2].
> >
> > Let's give
On Wed, Jan 08, 2014 at 12:32:59PM +0100, Richard Biener wrote:
> > Either before writing PCH c-common.c could call some tree.c routine that
> > would traverse the cl_option_hash_table hash table and for every
> > TARGET_OPTION_NODE in the hash table clear TREE_TARGET_GLOBALS.
> > Or perhaps some g
Hi,
On 12/27/2013 07:30 PM, François Dumont wrote:
Note that this patch contains also a cleanup of a useless template
parameter _Is_pod_comparator on _Rb_tree_impl.
The useless parameter is a remnant of an attempt at exploiting the EBO
for _Rb_tree_impl. At some point Benjamin got a patch from
On 01/08/2014 02:34 PM, Paolo Carlini wrote:
Hi,
On 12/27/2013 07:30 PM, François Dumont wrote:
Note that this patch contains also a cleanup of a useless template
parameter _Is_pod_comparator on _Rb_tree_impl.
The useless parameter is a remnant of an attempt at exploiting the EBO
for _Rb_tree_
On 01/08/14 01:14, Eric Botcazou wrote:
Committed after private email approval from Jakub. I made one
additional trivial change (missing whitespace in a comment).
This breaks bootstrap with RTL checking enabled:
[ ... ]
Thanks. I'm on it.
jeff
On Mon, Jan 6, 2014 at 9:49 AM, Teresa Johnson wrote:
> On Sun, Jan 5, 2014 at 12:08 PM, Jan Hubicka wrote:
>>> 2014-01-03 Rong Xu
>>>
>>> * gcc/gcov-io.c (gcov_var): Move from gcov-io.h.
>>> (gcov_position): Ditto.
>>> (gcov_is_error): Ditto.
>>> (gcov_rewrite)
> From: Hans-Peter Nilsson
> Date: Mon, 23 Dec 2013 23:34:02 +0100
Just as previously done on trunk, I'm going to cover up PR59584
(which was fixed and then exposed on the 4.8 branch) by applying
commit r206187 from trunk below. Again, the PR bug is an ICE
caused by the combination of expr.c:fin
On Wed, Jan 8, 2014 at 1:45 PM, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 12:32:59PM +0100, Richard Biener wrote:
>> > Either before writing PCH c-common.c could call some tree.c routine that
>> > would traverse the cl_option_hash_table hash table and for every
>> > TARGET_OPTION_NODE in the
>
> Actually, I tried changing these two, but gcc_checking_assert is
> undefined in libgcov.a. Ok to commit without this change?
OK.
incrementally can you please define gcov_nonruntime_assert that will wind into
gcc_assert for code within gcc/coverage tools and into nothing for libgcov
runtime an
On 01/07/2014 02:37 PM, Jakub Jelinek wrote:
On Tue, Jan 07, 2014 at 02:27:04PM +0100, Florian Weimer wrote:
gimplify_modify_expr_rhs, in the CALL_EXPR case:
if (use_target)
{
CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
mark_address
Hi,
Commit 206131 introduced check_effective_target_arm_crypto_ok in
lib/target-supports.exp, to check that the target supports
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp.
However, when GCC is configured for target arm-none-linux-gnueabihf, I
can see all the new tests fail:
sysroot-arm-none-li
We can also get NULL for the default definition, so we need to handle that
before calling has_zero_uses on it.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-01-08 Marek Polacek
PR middle-end/59669
* omp-low.c (simd_clone_adjust): Don't crash if def is NULL.
testsu
On Wed, Jan 08, 2014 at 04:09:08PM +0100, Marek Polacek wrote:
> We can also get NULL for the default definition, so we need to handle that
> before calling has_zero_uses on it.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
Looks ok, but there is similar code a few lines above, can yo
On 08/01/14 15:00, Christophe Lyon wrote:
Hi,
Commit 206131 introduced check_effective_target_arm_crypto_ok in
lib/target-supports.exp, to check that the target supports
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp.
However, when GCC is configured for target arm-none-linux-gnueabihf, I
can see
On Wed, Jan 08, 2014 at 04:14:06PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 08, 2014 at 04:09:08PM +0100, Marek Polacek wrote:
> > We can also get NULL for the default definition, so we need to handle that
> > before calling has_zero_uses on it.
> >
> > Bootstrapped/regtested on x86_64-linux, ok
On Wed, Jan 08, 2014 at 04:25:47PM +0100, Marek Polacek wrote:
> Indeed it does. So like this?
>
> 2014-01-08 Marek Polacek
>
> PR middle-end/59669
> * omp-low.c (simd_clone_adjust): Don't crash if def is NULL.
> testsuite/
> * gcc.dg/gomp/pr59669-1.c: New test.
> * gc
Hi all,
I just committed an 'obvious' patch for a ICE-on-invalid regression on trunk:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206429
Cheers,
Janus
Hi Sterling,
This patch implements zero-overhead looping for xtensa backend using
hw-doloop facility.
If OK for trunk, please apply it for me. Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog(revision 206431)
+++ gcc/Chang
On Wed, Jan 8, 2014 at 6:34 AM, Jan Hubicka wrote:
>>
>> Actually, I tried changing these two, but gcc_checking_assert is
>> undefined in libgcov.a. Ok to commit without this change?
>
> OK.
> incrementally can you please define gcov_nonruntime_assert that will wind into
> gcc_assert for code with
Hi Renlin,
The new test you added introduces 2 new FAILs when the target is
arm-none-linux-gnueabi (as opposed to arm-none-linux-gnueabihf).
Christophe.
On 24 December 2013 15:46, Renlin Li wrote:
> Hi,
>
> I just updated my patch according your suggestion.
> Thank you for committing it for me
On Wed, Jan 8, 2014 at 8:27 AM, Felix Yang wrote:
> Hi Sterling,
>
> This patch implements zero-overhead looping for xtensa backend using
> hw-doloop facility.
> If OK for trunk, please apply it for me. Thanks.
Hi Felix,
I last worked on zero-overhead loops for Xtensa in the gcc 4.3
timefram
Hello!
>> So like this instead? Bootstrapped/regtested on x86_64-linux and
>> i686-linux. For 4.8 I'd still prefer the earlier patch though.
>>
>> 2013-12-18 Jakub Jelinek
>>
>> PR rtl-optimization/58668
>> * cfgcleanup.c (flow_find_cross_jump): Don't count
>> any jumps if dir_p is NULL. Rem
A small but major typo.
The second sentence should read "...usage of _Cilk_spawn [ and _Cilk_sync]
*without* -fcilkplus..." instead of "...with -fcilkplus..."
I am sorry about this.
Sincerely,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Tuesday, January 7, 201
Hi Christophe,
There is a minor issue about this test case. It requires the `float-abi`
of your target to be either `softfp` or `hard` (to utilize the floating
point hardware).
Could you please check whether this solves the problem or not?
I should add it to the `dg-options` section of the te
On Tue, Jan 07, 2014 at 10:11:59PM +, Iyer, Balaji V wrote:
> I used a similar existing one (safelen). Attached, please find 2
> fixed patches for C and C++ along with their changelogs.
But safelen is something completely different, while if I skim
the _Cilk_for docs, the grain is really
On 8 January 2014 18:15, Renlin Li wrote:
> Hi Christophe,
>
> There is a minor issue about this test case. It requires the `float-abi` of
> your target to be either `softfp` or `hard` (to utilize the floating point
> hardware).
> Could you please check whether this solves the problem or not?
>
In
* config/aarch64/aarch64.md (mulditi3): New expander.
---
gcc/config/aarch64/aarch64.md | 17 +
1 file changed, 17 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index c4acdfc..0b3943d 100644
--- a/gcc/config/aarch64/aarch64.md
+++
* config/aarch64/aarch64 (addti3, subti3): New expanders.
(add3_compare0): Remove leading * from name.
(add3_carryin): Likewise.
(sub3_compare0): Likewise.
(sub3_carryin): Likewise.
---
gcc/config/aarch64/aarch64.md | 45 +
* config/aarch64/aarch64.md (multi3): New expander.
(madd): Remove leading * from name.
---
gcc/config/aarch64/aarch64.md | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
in
The recent longlong.h patch
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00286.html
reminded me that the other common patterns really ought to be supported
somehow. We had patterns defining ADDS, ADC, and UMULH, but we didn't
have the proper expanders in place to make use of them.
The final
We have good support for TImode arithmetic, so no need to do anything
with inline assembly.
include/
* longlong.h [__aarch64__] (add_ss, sub_ddmmss, umul_ppmm): New.
[__aarch64__] (COUNT_LEADING_ZEROS_0): Define in terms of W_TYPE_SIZE.
---
include/longlong.h | 28
No need to do this over and over for different 64-bit hosts.
libgcc/
* config/soft-fp/soft-fp.h (TItype, UTItype, TI_BITS): New.
* config/aarch64/sfp-machine.h (TItype, UTItype, TI_BITS): Remove.
* config/i386/64/sfp-machine.h: Likewise.
* config/ia64/sfp-machine.h:
The documentation for longlong.h says this type must be defined.
We've gotten away with this because so far longlong.h hasn't
actually used the type.
libgcc/
* soft-fp/soft-fp.h: (UDWtype): New define.
---
libgcc/soft-fp/soft-fp.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/
On Wed, Jan 08, 2014 at 01:45:40PM +0100, Jakub Jelinek wrote:
> I'd like to get rid of all the XCNEW calls in target-globals.c as a
> follow-up.
Here it is. The rationale is both to avoid many separate heap allocations
and if TARGET_OPTION_NODE is no longer needed (all FUNCTION_DECLs
referencing
Hi!
The recent ipa_analyze_params_uses changes broke i686-linux bootstrap
with --enable-checking=release, the reduced testcase below shows it.
Obviously we need to ignore debug stmt uses during analysis.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2014-0
I was forgetting that recursing into template arguments would in turn
recurse into their template arguments, leading to quadratic behavior.
So, look at template arguments only once and add any inherited tags to
the instantiated type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f97c95
This patch removes mod_id_to_name map because the info is already
there in module_infos. And also, AutoFDO don't have access to update
this map because its a file-static structure.
Bootstrapped and passed regression test.
OK for google branch?
Thanks,
Dehao
Index: gcc/coverage.c
===
On Wed, Dec 25, 2013 at 2:32 PM, Uros Bizjak wrote:
> On Wed, Dec 25, 2013 at 10:31 PM, H.J. Lu wrote:
>
>>> cpu_names in i386.c is only used by ix86_function_specific_print
>>> which
>>> accesses it with enum processor_type index. But cpu_names is
>>> define
PR 59137 is another case where dbr_schedule gets confused about liveness.
We start out with:
A: $2 = x
B: if $4 == $2 goto L1 [REG_DEAD: $2]
C: if $4 < 0 goto L2
...
L1:
D: $2 = y
E: goto L3
L2:
F: $2 = x
G: goto L3
...
L3:
...
r
This patch just reverts some changes I'd made to the BADDU patterns
for the infamous (truncate:QI (plus:SI ...)) -> (plus:QI ...) simplification.
That simplification was limited to CISCy targets for PR 58295.
Tested on mips64-linux-gnu and applied. It fixes the octeon-baddu-1.c
failures.
Thanks,
Hello!
>> gcc.target/i386/pr59099.c fails on x86_64-redhat-linux-gnu with
>> --disable-multilib because linking -m32 code is not supported. The
>> test case passes in 64-bit mode as well. The other -m32 tests do
>> not use dg-do run, so they do not exhibit this problem.
>>
>> Okay for trunk?
>
>
Jakub Jelinek writes:
> 2014-01-08 Jakub Jelinek
>
> * target-globals.c (save_target_globals): Allocate most of the
> structs using GC in payload of target_globals struct instead
> of allocating them on the heap.
Looks good to me FWIW. I don't know either way about the one-b
On Tue, Jan 7, 2014 at 8:07 AM, Bernd Schmidt wrote:
> On 01/05/2014 05:10 PM, Teresa Johnson wrote:
>>
>> On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt
>> wrote:
>>>
>>> I have a different patch which I'll submit next week after some more
>>> testing. The assert in cfgrtl is unnecessarily broad
On Wed, Jan 8, 2014 at 8:27 PM, Richard Sandiford wrote:
> gcc/
> PR rtl-optimization/59137
> * reorg.c (steal_delay_list_from_target): Call update_block for
> elided insns.
> (steal_delay_list_from_fallthrough, relax_delay_slots): Likewise.
>
> gcc/testsuite/
>
On Wed, Jan 08, 2014 at 07:41:26PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > 2014-01-08 Jakub Jelinek
> >
> > * target-globals.c (save_target_globals): Allocate most of the
> > structs using GC in payload of target_globals struct instead
> > of allocating them on t
On Mon, Dec 23, 2013 at 6:14 AM, H.J. Lu wrote:
> On Sun, Dec 22, 2013 at 11:11:12PM +0100, Uros Bizjak wrote:
>
>> Please get someone to review config.gcc changes. They are OK as far as
>> x86 rename is concerned, but I can't review functional changes.
>
> Hi Paolo,
>
> Can you review this config
This patch removes a couple of redundant entries I noticed in
altivec_overloaded_builtins. Identical entries occur nearby.
Bootstrapped and tested on powerpc64-unknown-linux-gnu with no
regressions, applied as obvious.
Thanks,
Bill
2014-01-08 Bill Schmidt
* config/rs6000/rs6000-c.c
soft-fp patches should go first to glibc.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 8 Jan 2014, Richard Henderson wrote:
> diff --git a/libgcc/soft-fp/soft-fp.h b/libgcc/soft-fp/soft-fp.h
> index 696fc86..b54b1ed 100644
> --- a/libgcc/soft-fp/soft-fp.h
> +++ b/libgcc/soft-fp/soft-fp.h
> @@ -237,6 +237,11 @@ typedef int DItype __attribute__ ((mode (DI)));
> typedef unsign
Hi Richard,
It looks like the microMIPS implementation is missing support for the JRC
instruction and also misses an opportunity to generate JALS.
I've attached a patch, plus some new test cases to correct this. Does this
look okay to commit? I'd like to get it in 4.9.
Thanks,
Catherine
jr
Hello Everyone,
Attached, please find a patch will fix the bug mentioned in PR 59524.
The main issue was that Cilk keywords tests are running even when the user
configured the compiler with --disable-libcilkrts. This patch should fix this
issue for C and C++. This is tested on x86 and x8
"Moore, Catherine" writes:
> 2014-01-08 Catherine Moore
>
> gcc/testsuite/
> * gcc.target/mips/umips-branch-3.c: New test.
> * gcc.target/mips/umips-branch-4.c: New test.
>
> gcc/
> * config/mips/mips.md (simple_return): Attempt to use JRC for microMIPS.
>
On Wed, Jan 8, 2014 at 3:15 PM, Bill Schmidt
wrote:
> This patch removes a couple of redundant entries I noticed in
> altivec_overloaded_builtins. Identical entries occur nearby.
>
> Bootstrapped and tested on powerpc64-unknown-linux-gnu with no
> regressions, applied as obvious.
>
> Thanks,
> Bi
On Tue, Jan 7, 2014 at 6:59 PM, Bill Schmidt
wrote:
> On Tue, 2014-01-07 at 22:18 +, Joseph S. Myers wrote:
>> On Tue, 7 Jan 2014, Bill Schmidt wrote:
>>
>> > Yes, sorry for not being more clear. This is indeed for interpretation
>> > of element numbers in Altivec intrinsics such as vec_splat
Hello Uros, and everyone else,
Now that LRA is always used for the i386 targets, reload_in_progress
is never set so all code conditional on it is now dead. The attached
patch removes this code.
Sadly I'm having difficulty testing the patch because I have no access
to a suitable x86_64 or ix86 box
On Wed, 2014-01-08 at 16:46 -0500, David Edelsohn wrote:
> On Tue, Jan 7, 2014 at 6:59 PM, Bill Schmidt
> wrote:
> > On Tue, 2014-01-07 at 22:18 +, Joseph S. Myers wrote:
> >> On Tue, 7 Jan 2014, Bill Schmidt wrote:
> >>
> >> > Yes, sorry for not being more clear. This is indeed for interpret
On Wed, Jan 08, 2014 at 10:51:53PM +0100, Steven Bosscher wrote:
> Hello Uros, and everyone else,
>
> Now that LRA is always used for the i386 targets, reload_in_progress
> is never set so all code conditional on it is now dead. The attached
> patch removes this code.
>
> Sadly I'm having difficu
Here is the patch that addresses Honza's concern about bss increment.
It just makes this_prg a local variable.
Some comments are inlined.
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>
> Do you know how the size of libgcov changed with your patch?
> Quick check of current mainline on
On Wed, Jan 8, 2014 at 5:20 AM, Paolo Carlini wrote:
> On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
>> Ouch! Yes, that's quite a bit slower, and this code is already very
>> slow to compile.
With this patch (who is based on a-fixed.diff, committed earlerly),
who use templated member functions i
Some of the tests were failing due to the branch cost and some were
failing due to !LOGICAL_OP_NON_SHORT_CIRCUIT. I just skipped the
latter, as for ARM Cortex-M.
I'll look at the gcc.dg/tree-ssa/ssa-dom-thread-4.c failure separately.
Tested on mips64-linux-gnu and applied.
Thanks,
Richard
gcc
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li wrote:
>>>
>>> #ifdef L_gcov_merge_ior
>>> /* The profile merging function that just adds the counters. It is given
>>> - an array COUNTERS of N_COUNTERS old counters and it reads the same
>>> number
>>> - of counters from the gcov file.
> This patch just reverts some changes I'd made to the BADDU patterns
> for the infamous (truncate:QI (plus:SI ...)) -> (plus:QI ...)
> simplification. That simplification was limited to CISCy targets for PR
> 58295.
>
> Tested on mips64-linux-gnu and applied. It fixes the octeon-baddu-1.c
> fail
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> @@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
>> #endif
>> /* crc32 for this program. */
>> static gcov_unsigned_t crc32;
>> +/* Use this summary checksum rather the computed one if the value is
>> + *non-zero. */
>> +static
On Tue, Jan 07, 2014 at 03:54:56PM +0100, Richard Biener wrote:
> 2014-01-07 Richard Biener
>
> PR middle-end/59471
> * gimplify.c (gimplify_expr): Gimplify register-register type
> VIEW_CONVERT_EXPRs to separate stmts.
>
> * gcc.dg/pr59471.c: New testcase.
The testcas
Hi,
On 01/08/2014 11:11 PM, Tim Shen wrote:
On Wed, Jan 8, 2014 at 5:20 AM, Paolo Carlini wrote:
On 01/08/2014 10:24 AM, Jonathan Wakely wrote:
Ouch! Yes, that's quite a bit slower, and this code is already very
slow to compile.
With this patch (who is based on a-fixed.diff, committed earler
This is a regression present on the mainline for weak external symbols and
languages with non-call exceptions:
0xb222df crash_signal
/home/eric/svn/gcc/gcc/toplev.c:337
0x75ed9c symtab_alias_ultimate_target(symtab_node*, availability*)
/home/eric/svn/gcc/gcc/symtab.c:989
0xb69a59
On Wed, Jan 08, 2014 at 05:54:55PM +0100, Uros Bizjak wrote:
> This caused PR59724 on alpha:
>
> 20021116-1.c: In function ‘foo’:
> 20021116-1.c:31:1: error: NOTE_INSN_BASIC_BLOCK is missing for block 9
> }
> ^
> 20021116-1.c:31:1: error: insn outside basic block
> (jump_insn 94 52 93 9 (return)
On Wed, Jan 08, 2014 at 12:19:02PM +0100, Richard Biener wrote:
> On Wed, 8 Jan 2014, Jakub Jelinek wrote:
>
> > On Wed, Jan 08, 2014 at 12:15:40PM +0100, Richard Biener wrote:
> > > > I start to think this is a too complex transform for stmt folding ...
> > >
> > > Alternatively do update_call_f
On Wed, Jan 8, 2014 at 5:38 PM, Paolo Carlini wrote:
> I agree, it's probably fine for now, but please actually attach the patch ;)
Oops sorry >.<
So my plan is to instantiate _Compiler and _Executor instead of user
interfaces like basic_regex or regex_match, because the implementation
may chan
On 01/08/14 01:14, Eric Botcazou wrote:
Committed after private email approval from Jakub. I made one
additional trivial change (missing whitespace in a comment).
This breaks bootstrap with RTL checking enabled:
/home/eric/svn/gcc/libgcc/config/libbid/bid64_noncomp.c:119:1: internal
compiler
On Wed, Jan 08, 2014 at 04:02:17PM -0700, Jeff Law wrote:
> * ree.c (get_sub_rtx): New function, extracted from...
> (merge_def_and_ext): Here.
> (combine_reaching_defs): Use get_sub_rtx.
> --- a/gcc/ree.c
> +++ b/gcc/ree.c
> @@ -580,27 +580,17 @@ make_defs_and_copies_lists (rtx
Hi,
On Tue, 7 Jan 2014 15:10:20, Richard Biener wrote:
>
> On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
> wrote:
>> Bernd Edlinger writes:
How about this patch for the big comment?
>>>
>>> The comment should say that target_set_current_function()
>>> cannot call target_reinit() be
Ok.
David
On Wed, Jan 8, 2014 at 10:58 AM, Dehao Chen wrote:
> This patch removes mod_id_to_name map because the info is already
> there in module_infos. And also, AutoFDO don't have access to update
> this map because its a file-static structure.
>
> Bootstrapped and passed regression test.
>
>
1 - 100 of 111 matches
Mail list logo
