Bootstrapped regression tested on x86_64-unknown-linux. Also
bootstrapped with --enable-checking=rtl.
Note that you can do only one bootstrap with --enable-checking=yes,rtl.
Installed on the trunk.
As far as I can see, no, it was not installed.
--
Eric Botcazou
On 01/17/14 01:41, Eric Botcazou wrote:
Bootstrapped regression tested on x86_64-unknown-linux. Also
bootstrapped with --enable-checking=rtl.
Note that you can do only one bootstrap with --enable-checking=yes,rtl.
Installed on the trunk.
As far as I can see, no, it was not installed.
On 01/16/14 15:07, Jakub Jelinek wrote:
On Thu, Jan 16, 2014 at 02:31:09PM -0700, Jeff Law wrote:
+2014-01-16 Jeff Law l...@redhat.com
+
+ * ree.c (combine_set_extension): Correct test for changing number
+ of hard registers when widening a reaching definition.
+
2014-01-16
On 01/17/14 14:51, Jeff Law wrote:
Anyway, I clearly need to rethink that test. Given this is something we
haven't seen in the wild, I'm going to disable it over the
weekend/monday so that enable-checking bugs pass and continue to ponder.
And the patch which disables the test.
jeff
* gcc.c-torture/execute/pr59747.c (fn1): Return a value.
Index: gcc.c-torture/execute/pr59747.c
===
--- gcc.c-torture/execute/pr59747.c (revision 206658)
+++ gcc.c-torture/execute/pr59747.c (working copy)
@@ -1,13
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler error: RTL check:
expected code 'reg', have
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler
On 01/16/14 11:23, Dominique Dhumieres wrote:
The test gcc.c-torture/execute/pr59747.c fails on darwin13 at execution time
(Abort)
for all tested optimizations, -m32/-m64, and gcc versions before or after the
commit.
Should I
(1) reopen pr59749,
(2) open a new pr,
(3) let you handle the
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler
On 01/16/14 04:52, Eric Botcazou wrote:
Yes, like in the attached patch? OK for the trunk?
Unfortunately this broke again bootstrap with RTL checking enabled on x86-64:
/home/eric/svn/gcc/libgcc/libgcc2.c: In function '__negdi2':
/home/eric/svn/gcc/libgcc/libgcc2.c:71:1: internal compiler
On Thu, Jan 16, 2014 at 02:31:09PM -0700, Jeff Law wrote:
+2014-01-16 Jeff Law l...@redhat.com
+
+ * ree.c (combine_set_extension): Correct test for changing number
+ of hard registers when widening a reaching definition.
+
2014-01-16 Bernd Schmidt ber...@codesourcery.com
On 01/13/14 00:34, Jakub Jelinek wrote:
On Sun, Jan 12, 2014 at 11:21:59PM -0700, Jeff Law wrote:
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -297,6 +297,13 @@ combine_set_extension (ext_cand *cand, rtx curr_insn, rtx
*orig_set)
else
new_reg = gen_rtx_REG (cand-mode, REGNO (SET_DEST
On Wed, Jan 15, 2014 at 10:56:35AM -0700, Jeff Law wrote:
On 01/13/14 00:34, Jakub Jelinek wrote:
On Sun, Jan 12, 2014 at 11:21:59PM -0700, Jeff Law wrote:
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -297,6 +297,13 @@ combine_set_extension (ext_cand *cand, rtx curr_insn,
rtx *orig_set)
else
On 01/10/14 14:52, Jakub Jelinek wrote:
There is one thing I still worry about, if some target has
an insn to say sign extend or zero extend a short memory load
into HARD_REGNO_NREGS () 1 register, but the other involved
register has the only one (or fewer) hard registers available to it.
On Sun, Jan 12, 2014 at 11:21:59PM -0700, Jeff Law wrote:
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -297,6 +297,13 @@ combine_set_extension (ext_cand *cand, rtx curr_insn,
rtx *orig_set)
else
new_reg = gen_rtx_REG (cand-mode, REGNO (SET_DEST (*orig_set)));
+ /* We're going to be
As mentioned in the PR. We have a memory load and two extensions.
The first extension requires a copy because its source and destination
are not the same hard register.
The second extension does not require a copy and has a wider mode than
the first extension.
In this case we have to
On Fri, Jan 10, 2014 at 02:36:47PM -0700, Jeff Law wrote:
As mentioned in the PR. We have a memory load and two extensions.
The first extension requires a copy because its source and
destination are not the same hard register.
The second extension does not require a copy and has a wider
On 01/10/14 14:52, Jakub Jelinek wrote:
There is one thing I still worry about, if some target has
an insn to say sign extend or zero extend a short memory load
into HARD_REGNO_NREGS () 1 register, but the other involved
register has the only one (or fewer) hard registers available to it.
18 matches
Mail list logo
