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
com
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
+
+ * ree.c (combine_set_extension): Correct test for changing number
+ of hard registers when widening a reaching definition.
+
2014-01-16 Bernd Schmidt
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.
Pi
> 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 Thu, Jan 16, 2014 at 02:31:09PM -0700, Jeff Law wrote:
> +2014-01-16 Jeff Law
> +
> + * ree.c (combine_set_extension): Correct test for changing number
> + of hard registers when widening a reaching definition.
> +
> 2014-01-16 Bernd Schmidt
>
> PR middle-end/56791
> diff
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 err
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 err
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 proble
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 problem without further fuss?
For (1) or (2) do you n
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 err
> 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
* 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 +1,1
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)
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 (*orig_se
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
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.
Consi
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.
Cons
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 wi
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 make
19 matches
Mail list logo
