Eric Botcazou writes:
>> This is the second part of PR 61084, which it seems I'd forgotten to post.
>> pdist calculates a wide result from narrower inputs, so I should have
>> used widest_int rather than wide_int.
>
> Is that documented? Because, if even you wide-int guys got it wrong...
Well, I
On 1 May 2014 17:57, Yufeng Zhang wrote:
> "On AArch64, the singleton vector types int64x1_t, uint64x1_t and
> float64x1_t exported by arm_neon.h are defined to be the same as their
> base types. This results in incorrect application of parameter passing
> rules to arguments of types int64x1_t a
On 16 May 13:39, Jeff Law wrote:
> On 04/16/14 05:35, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch introduces Intel MPX bound registers and instructions. It was
> >approved earlier for 4.9 and had no significant changes since then. I'll
> >assume patch is OK if no objections arise.
> >
> >Patc
> Well, I understood the distinction between wide_int and widest_int.
> I just didn't understand what pdist did. :-)
>
> The difference is documented (a bit verbosely) in wide-int.h.
Yes, but not really why it's not correct to use wide_int for the computation
made in pdist (and whether the use o
On Fri, May 16, 2014 at 4:20 PM, Mike Stump wrote:
> On May 15, 2014, at 11:52 PM, Richard Biener
> wrote:
>> On May 16, 2014 4:47:11 AM CEST, Mike Stump wrote:
>>> This reorders the avx checks and gates on a target triplet check before
>>> compiling any code.
>>
>> Can you explain why?
>
> Sur
Eric Botcazou writes:
>> Well, I understood the distinction between wide_int and widest_int.
>> I just didn't understand what pdist did. :-)
>>
>> The difference is documented (a bit verbosely) in wide-int.h.
>
> Yes, but not really why it's not correct to use wide_int for the computation
> made
On Fri, May 16, 2014 at 9:12 PM, Jan Hubicka wrote:
> Hi,
> this patch makes also the rtti type info for A in the testcase:
>
> struct A
> {
> virtual void foo(void) {};
> virtual void foo2(void) {};
> virtual void foo3(void) {};
> virtual void foo4(void) {};
> virtual void foo5(void) {}
Hi,
this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise
identical calls to a pure function present in different EH regions are CSEd,
which changes the semantics of the program because the second EH handler is
not invoked:
begin
I := F(0);
exception
when E
On Fri, May 16, 2014 at 6:17 PM, David Malcolm wrote:
> On Fri, 2014-05-16 at 14:59 +0200, Richard Biener wrote:
>> On Tue, Apr 29, 2014 at 5:01 PM, David Malcolm wrote:
>> > On Tue, 2014-04-29 at 11:16 +0200, Richard Biener wrote:
>> >> On Tue, Apr 29, 2014 at 2:58 AM, David Malcolm
>> >> wrot
On Mon, May 19, 2014 at 10:52:52AM +0200, Richard Biener wrote:
> On Fri, May 16, 2014 at 9:12 PM, Jan Hubicka wrote:
> > this patch makes also the rtti type info for A in the testcase:
> >
> > struct A
> > {
> > virtual void foo(void) {};
> > virtual void foo2(void) {};
> > virtual void foo
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
wrote:
> The main thing keeping zero-precision wide-ints alive was void_zero_node,
> a tree used in the C and C++ frontends that has type VOID_TYPE but code
> INTEGER_CST.
>
> Richard B. asked me to replace the INTEGER_CST with a new constant typ
On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka wrote:
> Hi,
> this patch enables -fdeclone-ctor-dtor by default: I believe it is up to the
> optimizers to decide when the actual worker body should be inlined into the
> thunks.
>
> Bootstrapped/regtested x86_64-linux, OK?
Please make sure to not ena
On Fri, May 16, 2014 at 11:19 PM, Xinliang David Li wrote:
> Modified the patch according to yours and Richard's feedback. PTAL.
ENOPATCH.
Btw, I don't see any issue with leaking node order to opt-report.
Richard.
> thanks,
>
> David
>
> On Fri, May 16, 2014 at 9:03 AM, Jan Hubicka wrote:
>>>
On Sun, May 18, 2014 at 10:59 PM, Jan Hubicka wrote:
> Sandra,
>> This patch seems quite similar in purpose to the
>> remove_local_statics optimization that Mentor has proposed, although
>> the implementation is quite different. Here is the last version of
>> our patch, prepared by Bernd Schmidt
Richard Biener writes:
> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
> wrote:
>> The main thing keeping zero-precision wide-ints alive was void_zero_node,
>> a tree used in the C and C++ frontends that has type VOID_TYPE but code
>> INTEGER_CST.
>>
>> Richard B. asked me to replace the IN
> From: Richard Biener [mailto:richard.guent...@gmail.com]
>
> Oh, and what happens for
>
> unsigned foo (unsigned char *x)
> {
> return x[0] << 24 | x[2] << 8 | x[3];
> }
>
> ? We could do an unsigned int load from x and zero byte 3
> with an AND. Enhancement for a followup, similar to also
On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou wrote:
> Hi,
>
> this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise
> identical calls to a pure function present in different EH regions are CSEd,
> which changes the semantics of the program because the second EH handler
On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
>> wrote:
>>> The main thing keeping zero-precision wide-ints alive was void_zero_node,
>>> a tree used in the C and C++ frontends that has type VOID_TYPE bu
On Mon, May 19, 2014 at 11:30 AM, Thomas Preud'homme
wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>
>> Oh, and what happens for
>>
>> unsigned foo (unsigned char *x)
>> {
>> return x[0] << 24 | x[2] << 8 | x[3];
>> }
>>
>> ? We could do an unsigned int load from x and zer
> On May 19, 2014, at 2:39 AM, Richard Biener
> wrote:
>
>> On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou
>> wrote:
>> Hi,
>>
>> this fixes an over-optimization of the GIMPLE optimizer, whereby two
>> otherwise
>> identical calls to a pure function present in different EH regions are CSE
Richard Biener writes:
> On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
>>> wrote:
The main thing keeping zero-precision wide-ints alive was void_zero_node,
a tree used in the C and C++ fro
> I thought we had decided a long time ago that pure and const functions could
> not throw and that was the documented behavior.
No, it's precisely the opposite.
--
Eric Botcazou
On Mon, May 19, 2014 at 12:11:25PM +0200, Eric Botcazou wrote:
> > I thought we had decided a long time ago that pure and const functions could
> > not throw and that was the documented behavior.
>
> No, it's precisely the opposite.
Can either of you back that up with mailing list archive referen
On Fri, 16 May 2014, Jeff Law wrote:
> On 05/14/14 03:06, Richard Biener wrote:
> >
> > The following fixes pre/post-inc/dec gimplification of promoted
> > integer types. There is the issue with the way TYPE_OVERFLOW_UNDEFINED
> > is related to TYPE_OVERFLOW_WRAPS and the (non-)semantics of
> >
> Please keep the "redundant" test, it speeds up comparison on hash
> collisions. As you are on it I'd use size_int (lr).
The redundant test is very redundant, see the line just below it.
> I think it's ok to CSE foo (0) for
>
>try {
> foo (0);
>} catch (...) { side-effect }
>
Ping.
On Mon, May 5, 2014 at 8:49 PM, Evgeny Stupachenko wrote:
> Is the following patch ok? It passes bootstrap and make check.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 88142a8..91f6f21 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -428
Ping.
On Mon, May 5, 2014 at 8:54 PM, Evgeny Stupachenko wrote:
> Assuming first part of the patch is committed. Is the following patch
> ok? It passes bootstrap and make check.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 91f6f21..475448e 100644
> --- a/gcc/config/i38
On 8 May 2014 18:41, Ian Bolton wrote:
> gcc/testsuite
> * gcc.target/aarch64/vdup_lane_2.c (force_simd): Emit an
> actual instruction to move into the allocated register.
This macro is attempting to force a value to a particular class of
register, we don't need or want the mov i
> Can either of you back that up with mailing list archive references?
See https://gcc.gnu.org/ml/gcc-patches/2008-08/msg00043.html which points to a
previous discussion in January. There are 2 tests in the gnat.dg testsuite:
gnat.dg/handle_raise_from_pure.adb
gnat.dg/test_raise_from_pure.ad
There was a patch to change GET_CODE(..) == CONST_INT to CONST_INT_P,
and in one instance this was done incorrectly, leaving only a plain
GET_CODE without any comparison. I've committed the following as
obvious after testing on x86_64-linux.
Bernd
* simplify-rtx.c (simplify_unary_operation
On 1 April 2014 23:24, Richard Henderson wrote:
> Comments? If approved, should this go in for 4.9, or wait for stage1?
> Certainly it's self-contained...
Hi, I think this should go in, with the cache line increased to 128 as
discussed with Andrew.
/Marcus
On Wed, 2014-05-14 at 12:53 +0200, Eric Botcazou wrote:
> > Attached is a patch for support of GNU/Hurd in gnat-4.9. This patch has
> > been used and updated in Debian since gnat-4.6, and is currently used to
> > build gnat-4.9. Now when the body file s-osinte-posix.adb in gcc-4.9
> > defines tv_ns
On Mon, May 19, 2014 at 12:03 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
wrote:
> The main thing keeping zero-precision wide-
On Mon, May 19, 2014 at 12:21 PM, Eric Botcazou wrote:
>> Please keep the "redundant" test, it speeds up comparison on hash
>> collisions. As you are on it I'd use size_int (lr).
>
> The redundant test is very redundant, see the line just below it.
Oh... ok ;)
>> I think it's ok to CSE foo (0)
On Mon, May 19, 2014 at 12:11 PM, Eric Botcazou wrote:
>> I thought we had decided a long time ago that pure and const functions could
>> not throw and that was the documented behavior.
>
> No, it's precisely the opposite.
Btw, I agree. For this and other attributes the behavior is that it speci
On 30 April 2014 18:42, Ryan Mansfield wrote:
> aarch64_function_profiler was removed in rev203028 but the prototype was
> left behind. If OK, can someone apply? Thanks.
>
> Regards,
>
> Ryan Mansfield
>
> 2014-04-30 Ryan Mansfield
>
> * config/aarch64/aarch64-protos.h (aarch64_function
The following is my current idea on progressing on the HOST_WIDE_INT
removal
1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)
2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT
3) s/HOST_WIDE_INT/int64_t/ (same for unsigned HOST_WIDE_INT)
Leaves us with
> The build went fine. Is something still missing?
We never keep commented out code, except with a ??? comment explaining why.
We don't use 'FIXME', we use ??? instead.
Also, some of the comments seem to be copy/paste from freebsd, which is
likely not appropriate for GNU Hurd, so need to be revis
This fixes PR61209, we were leaking VN_TOP into the cached
expr used for folding. That's of course a no-no.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
Richard.
2014-05-19 Richard Biener
PR tree-optimization/61209
* tree-ssa-sccvn.c (visit_phi): Avoid setting
On 23 April 2014 21:22, Alan Lawrence wrote:
> 2014-03-27 Alan Lawrence
> * config/aarch64/aarch64-builtins.c
> (aarch64_types_binopv_qualifiers,
> TYPES_BINOPV): New static data.
> * config/aarch64/aarch64-simd-builtins.def (im_lane_bound): New
> builtin.
> * c
In this PR we run into the issue that releasing SSA names from
FRE/PRE elimination corrupts the VN lattice and thus the VN lookup
we perform for removing redudnant stores ICEs. The patch works
around the particular case by making unreachable code detection
in SCCVN more optimistic by ignoring bac
On 15 May 2014 16:52, Alan Lawrence wrote:
> 2014-05-15 Alan Lawrence
>
> * config/aarch64/aarch64-simd.md
> (aarch64_rev):
> New pattern.
> * config/aarch64/aarch64.c (aarch64_evpc_rev): New function.
> (aarch64_expand_vec_perm_const_1): Add call to aarch64_evp
On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:52 AM, Mike Stump wrote:
On May 16, 2014, at 3:07 AM, Bin.Cheng wrote:
I don't see how regrename will help resolve [base+offset] false
dependencies. Can you explain? I'd expect effects from
hardreg-copyprop "commoning" a base re
Hi,
I'd like to once again ping this patch from 2014-04-22:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html
Thanks!
Bill
On Mon, 2014-05-19 at 14:50 +0200, Arnaud Charlet wrote:
> > The build went fine. Is something still missing?
>
> We never keep commented out code, except with a ??? comment explaining why.
Do you want me to remove all GNU/Hurd specific header file info?
> We don't use 'FIXME', we use ??? instea
> Do you want me to remove all GNU/Hurd specific header file info?
No, I want you to remove commented out code, such as:
> +-- SIGLTHRRES : constant := 32; -- GNU/LinuxThreads restart signal
> +-- SIGLTHRCAN : constant := 33; -- GNU/LinuxThreads cancel signal
> +-- SIGLTHRDBG : constant :
On Wed, 7 May 2014, Richard Biener wrote:
>
> This removes the need_64bit_hwi logic, nothing else (well, brings
> libcpp in line with gcc).
>
> Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
Thanks,
Richard.
> Just a
On Mon, 2014-05-19 at 15:53 +0200, Arnaud Charlet wrote:
> > Do you want me to remove all GNU/Hurd specific header file info?
>
> No, I want you to remove commented out code, such as:
>
> > +-- SIGLTHRRES : constant := 32; -- GNU/LinuxThreads restart signal
> > +-- SIGLTHRCAN : constant := 3
> > That's actually the biggest concern when people submit a new port: they
> > submit it, get it approved, commit it and then are no longer available
> > for any maintenance when these files need to be updated/become outdated/
> > no longer compile or run.
>
> I can try to do that in the near fut
On 17-05-14 12:51, Eric Botcazou wrote:
This is the updated version of the previously approved patch
submitted here (http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01320.html ).
The changes are:
- using a new hook call_fusage_contains_non_callee_clobbers,
- incorporating minor review comments from
> Hi,
>
> this fixes an over-optimization of the GIMPLE optimizer, whereby two
> otherwise
> identical calls to a pure function present in different EH regions are CSEd,
> which changes the semantics of the program because the second EH handler is
> not invoked:
>
> begin
> I := F(0);
>
On 05/19/2014 05:15 AM, Marcus Shawcroft wrote:
> On 1 April 2014 23:24, Richard Henderson wrote:
>> Comments? If approved, should this go in for 4.9, or wait for stage1?
>> Certainly it's self-contained...
>
>
> Hi, I think this should go in, with the cache line increased to 128 as
> discussed
> On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka wrote:
> > Hi,
> > this patch enables -fdeclone-ctor-dtor by default: I believe it is up to the
> > optimizers to decide when the actual worker body should be inlined into the
> > thunks.
> >
> > Bootstrapped/regtested x86_64-linux, OK?
>
> Please ma
On Mon, May 19, 2014 at 04:45:02PM +0200, Jan Hubicka wrote:
> > On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka wrote:
> > > Hi,
> > > this patch enables -fdeclone-ctor-dtor by default: I believe it is up to
> > > the
> > > optimizers to decide when the actual worker body should be inlined into
>
> > Hmm, but if the optimizers or the target can rely on DATA_ABI_ALIGNMENT
> > then we can't really lower it. Because we can make the vtable escape
> > to another unit that sees it as just an array of pointers?
>
> Sure, they can rely on DATA_ABI_ALIGNMENT (if that macro is defined), but
> anyth
Here's the patch. I did a simple test on 28_regex/*.
A bootstrap may be needed, but I can't do it now.
--
Regards,
Tim Shen
commit 2fd6be816c1d1797b3aad228b9fb2cfb7374483c
Author: tim
Date: Mon May 19 10:40:16 2014 -0400
2014-05-19 Tim Shen
PR libstdc++/61227
* include
On 05/05/2014 09:49 AM, Evgeny Stupachenko wrote:
> @@ -42946,6 +42948,10 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
>if (expand_vec_perm_pshufb (d))
> return true;
>
> + /* Try the AVX2 vpshufb. */
> + if (expand_vec_perm_vpshufb2_vpermq (d))
> +return true;
Why is this h
Hi,
On 05/19/2014 05:08 PM, Tim Shen wrote:
+ // TODO Refactor this piece of junk.
I suggest rewording this or avoiding it completely.
Paolo.
Sorry about it. Here is the patch. There is one remaining case where
cgraph_dump_file and dump_enable_p are checked separately --
cgraph_dump_file is set up differently from 'dump_file'.
David
On Mon, May 19, 2014 at 2:21 AM, Richard Biener
wrote:
> On Fri, May 16, 2014 at 11:19 PM, Xinliang
On Mon, May 19, 2014 at 6:48 AM, Jan Hubicka wrote:
>> > Thanks for the pointer, there is indeed the recommendation in
>> > optimization manual [1], section 3.6.4, where it is said:
>> >
>> > --quote--
>> > Misaligned data access can incur significant performance penalties.
>> > This is particular
On 05/05/2014 09:54 AM, Evgeny Stupachenko wrote:
> @@ -42943,6 +42944,10 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
>if (expand_vec_perm_vpermil (d))
> return true;
>
> + /* Try palignr on one operand. */
> + if (d->one_operand_p && expand_vec_perm_palignr (d))
> +return t
A fault in thumb1_reorg means we can try to get the insn_code of
something that isn't an insn. This appears to be a latent problem
that's suddenly started to bite on trunk. The code in question appears
to go back to gcc-4.8.
RTL checking would probably have found this quickly, but that's very
ex
On May 19, 2014, at 12:27 AM, Richard Sandiford
wrote:
> Does anyone have any suggestions for a better name than "wide_int" though?
Please, no.
> The main property of wide_int is that it has a variable precision, whereas
> widest_int and offset_int have constant precisions.
Right, I'd clarify
On Mon, May 19, 2014 at 9:14 AM, Uros Bizjak wrote:
> On Mon, May 19, 2014 at 6:48 AM, Jan Hubicka wrote:
>>> > Thanks for the pointer, there is indeed the recommendation in
>>> > optimization manual [1], section 3.6.4, where it is said:
>>> >
>>> > --quote--
>>> > Misaligned data access can incu
On Mon, May 19, 2014 at 6:42 PM, H.J. Lu wrote:
>>> Uros,
>>> I am looking into libreoffice size and the data alignment seems to make huge
>>> difference. Data section has grown from 5.8MB to 6.3MB in between GCC 4.8
>>> and 4.9,
>>> while clang produces 5.2MB.
>>>
>>> The two patches I posted t
On 05/19/14 06:54, Richard Biener wrote:
In this PR we run into the issue that releasing SSA names from
FRE/PRE elimination corrupts the VN lattice and thus the VN lookup
we perform for removing redudnant stores ICEs. The patch works
around the particular case by making unreachable code detecti
On Mon, May 19, 2014 at 9:45 AM, Uros Bizjak wrote:
> On Mon, May 19, 2014 at 6:42 PM, H.J. Lu wrote:
>
Uros,
I am looking into libreoffice size and the data alignment seems to make
huge
difference. Data section has grown from 5.8MB to 6.3MB in between GCC 4.8
and 4.9,
On May 19, 2014 6:57:52 PM CEST, Jeff Law wrote:
>On 05/19/14 06:54, Richard Biener wrote:
>>
>> In this PR we run into the issue that releasing SSA names from
>> FRE/PRE elimination corrupts the VN lattice and thus the VN lookup
>> we perform for removing redudnant stores ICEs. The patch works
>
On 05/19/14 02:58, Eric Botcazou wrote:
Hi,
this fixes an over-optimization of the GIMPLE optimizer, whereby two otherwise
identical calls to a pure function present in different EH regions are CSEd,
which changes the semantics of the program because the second EH handler is
not invoked:
beg
On Wed, 2014-05-14 at 12:09 -0600, Jeff Law wrote:
> On 05/12/14 15:36, David Malcolm wrote:
> [ ... Big Snip ... ]
> This series of 3 patches is approved.
FWIW, I've been working my way through the remainder of the patches,
updating them to take account of the largely mechanical changes [1] for
t
On 05/19/14 07:58, Richard Biener wrote:
On Wed, 7 May 2014, Richard Biener wrote:
This removes the need_64bit_hwi logic, nothing else (well, brings
libcpp in line with gcc).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for
On 05/19/14 00:38, Bin.Cheng wrote:
1) Should we do it in a separated pass, or just along with scheduler?
ISTM that when we're able to combine insns that can impact the schedule
we'd like to generate, possibly in significant ways. That argues for a
separate pass that runs before the scheduler.
On 05/19/14 07:10, Bill Schmidt wrote:
Hi,
I'd like to once again ping this patch from 2014-04-22:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html
OK for the trunk. Thanks for your patience.
jeff
So, before we forget to do this…
https://gcc.gnu.org/ml/gcc/2014-04/msg00284.html
Index: MAINTAINERS
===
--- MAINTAINERS (revision 210619)
+++ MAINTAINERS (working copy)
@@ -301,6 +301,9 @@ register allocation Kenneth Zadeck
On 05/19/14 02:19, Ilya Enkovich wrote:
On 16 May 13:39, Jeff Law wrote:
On 04/16/14 05:35, Ilya Enkovich wrote:
Hi,
This patch introduces Intel MPX bound registers and instructions. It was
approved earlier for 4.9 and had no significant changes since then. I'll
assume patch is OK if no ob
Richard Sandiford writes:
> Gerald Pfeifer writes:
>> On Sat, 17 May 2014, Richard Sandiford wrote:
>>> To rule out one possibility: which GCC are you using for stage1?
>>
>> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
>> FreeBSD 8, 9 and 10 all build fine on i386 (= i486)
OK.
Jason
On 05/18/14 22:36, David Wohlferd wrote:
2014-05-18 David Wohlferd
* doc/extend.texi: Create Label Attributes section,
move all label attributes into it and reference it.
THanks. Installed.
If you're going to continue to submit changes with any regularity, then
it would
On Sun, 18 May 2014, Sandra Loosemore wrote:
> H, I'm guessing this was some concern about invalid code motion around a
> setjmp. Our original analysis document lists "F does not call setjmp" as a
> requirement for the optimization, so this was probably a case where we were
> being excessivel
On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:32 AM, Jeff Law wrote:
On 05/16/14 04:07, Bin.Cheng wrote:
Yes, I think this one does have a good reason. The target independent
pass just makes sure that two consecutive memory access instructions
are free of data-dependency wit
On 05/18/14 09:33, John David Anglin wrote:
The attached change appears to fix PR middle-end/61141. On PA, we can get
deleted insn notes in call sequences. The attached change checks to
make sure we have
a valid insn before calling reset_insn_used_flags and verify_insn_sharing.
Tested on hppa-
Charles Baylis writes:
> On 13 February 2014 09:18, Richard Sandiford
> wrote:
>> This patch tries to reduce that by providing an alternative single-script
>> version. I was torn between Python and Tcl, but given how most people
>> tend to react to Tcl, I thought I'd better go for Python. I wo
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam wrote:
> Optimize access to globals with -fpie, x86_64 only:
>
> Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
> module
> using the GOT. This is two instructions, one to get the address of the global
> from the G
On 05/17/14 01:33, Richard Sandiford wrote:
I suppose we could put the onus on the users of the iterator to invoke
a "handle subrtxes of this code" routine once they know what the code is.
That could make things a bit ugly though. E.g.:
FOR_EACH_SUBRTX (iter, array, expr, NONCONST)
if (
Ping.
On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam wrote:
> Ping.
>
> On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> I would like this patch reviewed and considered for commit when
>> Stage 1 is active again.
>>
>> Patch Description:
>>
>> A C++ thunk's section name i
How about doing digest_init in get_nsdmi, so that the conversion is also
exposed to walk_field_subobs?
Jason
The problem in this testcase was that when we go to instantiate the
lambda in the NSDMI, since it wasn't defined in a function we
push_to_top_level and thereby clobber the current_class_ptr we set up.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e9fdfb3ea5ea6672a2dd72d3ed717686fe060cef
Jeff Law writes:
> On 05/17/14 01:33, Richard Sandiford wrote:
>> I suppose we could put the onus on the users of the iterator to invoke
>> a "handle subrtxes of this code" routine once they know what the code is.
>> That could make things a bit ugly though. E.g.:
>>
>>FOR_EACH_SUBRTX (iter,
On 19 May 2014 19:07, Richard Sandiford wrote:
>
> Sorry for the breakage. I wanted to make the script as picky as I could
> get away with though, so that results aren't lost accidentally.
>
> Could you try the attached?
That works for me.
Thanks for looking into it.
Richard Biener writes:
> The following is my current idea on progressing on the HOST_WIDE_INT
> removal
>
> 1) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00381.html (ping)
>
> 2) make sure [u]int64_t is available and use that to define HOST_WIDE_INT
>
> 3) s/HOST_WIDE_INT/int64_t/ (same for uns
On 04/29/14 09:28, Prathamesh Kulkarni wrote:
Append "evaluates to 0", in Wundef diagnostic.
clang prints the following diagnostic for -Wundef:
undef.c:1:5: warning: 'FOO' is not defined, evaluates to 0 [-Wundef]
#if FOO
^
OK to commit ?
[libcpp]
* expr.c (eval_token): Modify Wundef diagno
Rebased patch to current master attached. DWARF parts approved by
Cary Coutant, GDB already contains Tom Tromey's code to take advantage
of the new information. Earlier discussions:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00713.html
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01859.html
htt
Catherine included an earlier version of this patch with the microMIPS
submission a couple years ago:
https://gcc.gnu.org/ml/gcc-patches/2012-07/msg00972.html
Richard's response was:
Looks like the wrong place to do this. Please treat this as a separate
patch and get a tree expert to comment
Hi,
> On 19/mag/2014, at 20:28, Jason Merrill wrote:
>
> How about doing digest_init in get_nsdmi, so that the conversion is also
> exposed to walk_field_subobs?
Thanks, I'll look into that.
Paolo
On 15/05/2014 22:52, Jonathan Wakely wrote:
On 15/05/14 22:20 +0200, François Dumont wrote:
Hi
Here is a proposal to fix PR 61143. As explained in the PR I
finally prefer to leave the container in a valid state that is to say
with a non zero number of bucket, that is to say 1, after a move
I was playing around with this a few months ago but set it aside because
we weren't in stage 1 at the time. The way we currently set up comdat
groups early means that we need to mangle decls early, significantly
negating the earlier work to lazily set DECL_ASSEMBLER_NAME. This patch
improves
I've updated the patch. Shall I move the check inside cgraph_clone_node?
Thanks,
Dehao
Index: gcc/ipa-inline-transform.c
===
--- gcc/ipa-inline-transform.c (revision 210535)
+++ gcc/ipa-inline-transform.c (working copy)
@@ -183,8 +18
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
characters, but rather use heap allocated buffers limited only by the
available memory. The
On 19/05/14 11:08 -0400, Tim Shen wrote:
* testsuite/28_regex/algorithms/regex_match/ecma/char/quoted_char.cc:
New testcase.
This sounds like it's adding a new file, not extending it with new
tests.
@@ -435,6 +439,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::vector<_CharT>
> I've updated the patch. Shall I move the check inside cgraph_clone_node?
Thanks,
I think it is OK as it is. I belive individual users should know what do to
in such cases themselves.
You may want to also check what ipa-cp is doing.
Patch is OK (with Changelog)
Honza
>
> Thanks,
> Dehao
>
> In
1 - 100 of 134 matches
Mail list logo
