If f2d need fix, then please fix d2f too as current implementation for
both behave similarly.
- Joey
On Mon, May 19, 2014 at 5:23 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On ARM soft-float, the float to double conversion doesn't convert a sNaN
to qNaN as the IEEE Std 754 standard
On Sat, May 17, 2014 at 12:52 AM, Mike Stump mikest...@comcast.net wrote:
On May 16, 2014, at 3:07 AM, Bin.Cheng amker.ch...@gmail.com 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
On Sat, May 17, 2014 at 12:32 AM, Jeff Law l...@redhat.com 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 with each other, then
On Sat, May 17, 2014 at 12:18 AM, Jeff Law l...@redhat.com wrote:
On 05/16/14 04:07, Bin.Cheng wrote:
On Fri, May 16, 2014 at 1:13 AM, Jeff Law l...@redhat.com wrote:
On 05/15/14 10:51, Mike Stump wrote:
On May 15, 2014, at 12:26 AM, bin.cheng bin.ch...@arm.com wrote:
Here comes up with
Ping^2
Thanks,
bin
On Mon, May 12, 2014 at 11:17 AM, Bin.Cheng amker.ch...@gmail.com wrote:
Ping.
Thanks,
bin
On Tue, May 6, 2014 at 12:59 PM, bin.cheng bin.ch...@arm.com wrote:
Precisely, I configured gcc with options --with-arch=armv7-a
--with-cpu|--with-tune=cortex-a9.
I read gcc
Gerald Pfeifer ger...@pfeifer.com 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) and amd64.
When I
On Mon, May 19, 2014 at 02:08:06PM +0800, Joey Ye wrote:
If f2d need fix, then please fix d2f too as current implementation for
both behave similarly.
I have done some tests with double to float conversion, and the NaN
behaviour is correct. This is due to specific code handling that in
d2f:
3:
Eric Botcazou ebotca...@adacore.com 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
On 1 May 2014 17:57, Yufeng Zhang yufeng.zh...@arm.com 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
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.
Patch was
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 of
On Fri, May 16, 2014 at 4:20 PM, Mike Stump mikest...@comcast.net wrote:
On May 15, 2014, at 11:52 PM, Richard Biener richard.guent...@gmail.com
wrote:
On May 16, 2014 4:47:11 AM CEST, Mike Stump mikest...@comcast.net wrote:
This reorders the avx checks and gates on a target triplet check
Eric Botcazou ebotca...@adacore.com 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
On Fri, May 16, 2014 at 9:12 PM, Jan Hubicka hubi...@ucw.cz 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
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
On Fri, May 16, 2014 at 6:17 PM, David Malcolm dmalc...@redhat.com wrote:
On Fri, 2014-05-16 at 14:59 +0200, Richard Biener wrote:
On Tue, Apr 29, 2014 at 5:01 PM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-04-29 at 11:16 +0200, Richard Biener wrote:
On Tue, Apr 29, 2014 at 2:58
On Mon, May 19, 2014 at 10:52:52AM +0200, Richard Biener wrote:
On Fri, May 16, 2014 at 9:12 PM, Jan Hubicka hubi...@ucw.cz 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
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
rdsandif...@googlemail.com 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
On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka hubi...@ucw.cz 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
On Fri, May 16, 2014 at 11:19 PM, Xinliang David Li davi...@google.com 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
On Sun, May 18, 2014 at 10:59 PM, Jan Hubicka hubi...@ucw.cz 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
Richard Biener richard.guent...@gmail.com writes:
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
rdsandif...@googlemail.com 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
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
considering
On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou ebotca...@adacore.com 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
On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
The main thing keeping zero-precision wide-ints alive was
On Mon, May 19, 2014 at 11:30 AM, Thomas Preud'homme
thomas.preudho...@arm.com 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
On May 19, 2014, at 2:39 AM, Richard Biener richard.guent...@gmail.com
wrote:
On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou ebotca...@adacore.com
wrote:
Hi,
this fixes an over-optimization of the GIMPLE optimizer, whereby two
otherwise
identical calls to a pure function present
Richard Biener richard.guent...@gmail.com writes:
On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
The main thing
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 references?
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 }
foo (0);
Ping.
On Mon, May 5, 2014 at 8:49 PM, Evgeny Stupachenko evstu...@gmail.com 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
+++
Ping.
On Mon, May 5, 2014 at 8:54 PM, Evgeny Stupachenko evstu...@gmail.com 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
---
On 8 May 2014 18:41, Ian Bolton ian.bol...@arm.com 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
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
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
On 1 April 2014 23:24, Richard Henderson r...@redhat.com 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_nsec in
On Mon, May 19, 2014 at 12:03 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
On Sat, May 17, 2014
On Mon, May 19, 2014 at 12:21 PM, Eric Botcazou ebotca...@adacore.com 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
On Mon, May 19, 2014 at 12:11 PM, Eric Botcazou ebotca...@adacore.com 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
On 30 April 2014 18:42, Ryan Mansfield rmansfi...@qnx.com 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 rmansfi...@qnx.com
*
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
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
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 rguent...@suse.de
PR tree-optimization/61209
* tree-ssa-sccvn.c
On 23 April 2014 21:22, Alan Lawrence alan.lawre...@arm.com wrote:
2014-03-27 Alan Lawrence alan.lawre...@arm.com
* config/aarch64/aarch64-builtins.c
(aarch64_types_binopv_qualifiers,
TYPES_BINOPV): New static data.
* config/aarch64/aarch64-simd-builtins.def
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
On 15 May 2014 16:52, Alan Lawrence alan.lawre...@arm.com wrote:
2014-05-15 Alan Lawrence alan.lawre...@arm.com
* config/aarch64/aarch64-simd.md
(aarch64_revREVERSE:rev-opmode):
New pattern.
* config/aarch64/aarch64.c (aarch64_evpc_rev): New function.
On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:52 AM, Mike Stump mikest...@comcast.net wrote:
On May 16, 2014, at 3:07 AM, Bin.Cheng amker.ch...@gmail.com wrote:
I don't see how regrename will help resolve [base+offset] false
dependencies. Can you explain? I'd expect effects
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 ??? instead.
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 as I
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 := 33; --
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 future, then
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 r...@redhat.com 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
On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka hubi...@ucw.cz 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
On Mon, May 19, 2014 at 04:45:02PM +0200, Jan Hubicka wrote:
On Sun, May 18, 2014 at 9:32 PM, Jan Hubicka hubi...@ucw.cz 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
anything
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 timshe...@gmail.com
Date: Mon May 19 10:40:16 2014 -0400
2014-05-19 Tim Shen timshe...@gmail.com
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 here?
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
richard.guent...@gmail.com wrote:
On Fri, May 16,
On Mon, May 19, 2014 at 6:48 AM, Jan Hubicka hubi...@ucw.cz 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 particularly
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 true;
No,
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
On May 19, 2014, at 12:27 AM, Richard Sandiford rdsandif...@googlemail.com
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
On Mon, May 19, 2014 at 9:14 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, May 19, 2014 at 6:48 AM, Jan Hubicka hubi...@ucw.cz 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
On Mon, May 19, 2014 at 6:42 PM, H.J. Lu hjl.to...@gmail.com 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 to
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
On Mon, May 19, 2014 at 9:45 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, May 19, 2014 at 6:42 PM, H.J. Lu hjl.to...@gmail.com 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
On May 19, 2014 6:57:52 PM CEST, Jeff Law l...@redhat.com 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
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:
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
the
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
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
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
Richard Sandiford rdsandif...@googlemail.com writes:
Gerald Pfeifer ger...@pfeifer.com 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
OK.
Jason
On 05/18/14 22:36, David Wohlferd wrote:
2014-05-18 David Wohlferd d...@limegreensocks.com
* 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
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 excessively
On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:32 AM, Jeff Law l...@redhat.com 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
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
Charles Baylis charles.bay...@linaro.org writes:
On 13 February 2014 09:18, Richard Sandiford rdsandif...@googlemail.com
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
Ping.
On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com 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
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 tmsri...@google.com wrote:
Ping.
On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
I would like this patch reviewed and considered for commit when
Stage 1 is active again.
Patch Description:
A C++
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
Jeff Law l...@redhat.com 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
On 19 May 2014 19:07, Richard Sandiford rdsandif...@googlemail.com 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 rguent...@suse.de 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/
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
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
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
1 - 100 of 134 matches
Mail list logo
