On Fri, Dec 23, 2016 at 05:54:01PM +0100, Georg-Johann Lay wrote:
> Segher Boessenkool schrieb:
> >On Thu, Dec 22, 2016 at 04:18:34PM +0100, Georg-Johann Lay wrote:
> >If you don't have instruction scheduling subregs of mem are allowed (and
> >are counted as registers). Combine asks recog,
On Fri, Dec 23, 2016 at 05:54:01PM +0100, Georg-Johann Lay wrote:
> >The purpose of the combine change is to write widening extracts in a
> >more general form, so that backends for processors that can do such
> >more general things do not have to write hundreds (literally) extra
> >patterns for all
Segher Boessenkool schrieb:
On Thu, Dec 22, 2016 at 04:18:34PM +0100, Georg-Johann Lay wrote:
If you don't have instruction scheduling subregs of mem are allowed (and
are counted as registers). Combine asks recog, and it think this is
fine.
Why does reload use r31 here? Why does it think th
On Thu, Dec 22, 2016 at 04:18:34PM +0100, Georg-Johann Lay wrote:
> >>>If you don't have instruction scheduling subregs of mem are allowed (and
> >>>are counted as registers). Combine asks recog, and it think this is
> >>>fine.
> >>>
> >>>Why does reload use r31 here? Why does it think that is v
On 22.12.2016 15:27, Dominik Vogt wrote:
On Thu, Dec 22, 2016 at 12:00:37PM +0100, Georg-Johann Lay wrote:
On 21.12.2016 18:46, Segher Boessenkool wrote:
On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
$ avr-gcc
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr268
On Thu, Dec 22, 2016 at 12:00:37PM +0100, Georg-Johann Lay wrote:
> On 21.12.2016 18:46, Segher Boessenkool wrote:
> >On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
> >>$ avr-gcc
> >>/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c -S
> >>-O1 -mmcu=avr4 -S -v
On 21.12.2016 18:46, Segher Boessenkool wrote:
On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
$ avr-gcc
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c -S
-O1 -mmcu=avr4 -S -v
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c: In
functi
On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
> $ avr-gcc
> /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c -S
> -O1 -mmcu=avr4 -S -v
>
> /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c: In
> function 'yasm_lc3b__parse_insn':
> /gnu/
On 21.12.2016 15:42, Dominik Vogt wrote:
On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
On 12.12.2016 17:54, Segher Boessenkool wrote:
On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
Patch with these changes and a fix because of not handling
VOIDmode attached.
On Wed, Dec 21, 2016 at 01:58:18PM +0100, Georg-Johann Lay wrote:
> On 12.12.2016 17:54, Segher Boessenkool wrote:
> >On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> >>Patch with these changes and a fix because of not handling
> >>VOIDmode attached. Bootstrapped and regression test
On 12.12.2016 17:54, Segher Boessenkool wrote:
On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
Patch with these changes and a fix because of not handling
VOIDmode attached. Bootstrapped and regression tested on s390 and
s390x.
Okay for trunk.
When did you see VOIDmode, btw? It
On Mon, Dec 12, 2016 at 10:54:12AM -0600, Segher Boessenkool wrote:
> On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> > Patch with these changes and a fix because of not handling
> > VOIDmode attached. Bootstrapped and regression tested on s390 and
> > s390x.
>
> Okay for trunk.
>
On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> Patch with these changes and a fix because of not handling
> VOIDmode attached. Bootstrapped and regression tested on s390 and
> s390x.
Okay for trunk.
When did you see VOIDmode, btw? It wasn't on a const_int I hope?
Segher
>
On Sat, Dec 10, 2016 at 10:37:38AM -0600, Segher Boessenkool wrote:
> On Fri, Dec 09, 2016 at 04:23:44PM +0100, Dominik Vogt wrote:
> > 0001-*
> >
> > Deal with mode expanding zero_extracts in change_zero_ext. The
> > patch looks good to me, but not sure whether endianness is
> > handled pr
14 matches
Mail list logo