On October 29, 2016 6:12:50 PM GMT+02:00, Jakub Jelinek
wrote:
>On Fri, Oct 28, 2016 at 10:59:35AM +0200, Jakub Jelinek wrote:
>> On Fri, Oct 28, 2016 at 10:52:34AM +0200, Richard Biener wrote:
>> > > I've already committed the original patch based on Eric's review,
>but
>> > > managed to come up
On Fri, Oct 28, 2016 at 10:59:35AM +0200, Jakub Jelinek wrote:
> On Fri, Oct 28, 2016 at 10:52:34AM +0200, Richard Biener wrote:
> > > I've already committed the original patch based on Eric's review, but
> > > managed to come up with another testcase that still ICEs (one with two
> > > different c
On Fri, Oct 28, 2016 at 10:52:34AM +0200, Richard Biener wrote:
> > I've already committed the original patch based on Eric's review, but
> > managed to come up with another testcase that still ICEs (one with two
> > different complex modes). Is the following ok for trunk if it passes
> > bootstra
On Fri, 28 Oct 2016, Jakub Jelinek wrote:
> On Fri, Oct 28, 2016 at 01:32:22AM -0600, Jeff Law wrote:
> > >I think so. I'll leave the rest to people more familiar with RTL
> > >expansion -- generally I thought the callers of expand() have to deal
> > >with expansions that return a different mode?
On Fri, Oct 28, 2016 at 01:32:22AM -0600, Jeff Law wrote:
> >I think so. I'll leave the rest to people more familiar with RTL
> >expansion -- generally I thought the callers of expand() have to deal
> >with expansions that return a different mode?
> You generally have to deal with expansions that
On 10/28/2016 01:25 AM, Richard Biener wrote:
On Thu, 27 Oct 2016, Jakub Jelinek wrote:
Hi!
The following testcase ICEs on x86_64-linux with -O1, the problem is
that we expand assignment from COMPONENT_REF of MEM_REF into a V4SImode
SSA_NAME. The MEM_REF has non-addressable DCmode var inside
On Thu, 27 Oct 2016, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on x86_64-linux with -O1, the problem is
> that we expand assignment from COMPONENT_REF of MEM_REF into a V4SImode
> SSA_NAME. The MEM_REF has non-addressable DCmode var inside of it, and
> type of a struct containin
> Though, perhaps COMPLEX_MODE_P (mode1) is also wrong, if mode1 isn't
> GET_MODE (op0), then we still will return something with unexpected mode
> (e.g. DCmode vs. CDImode); I wonder if for such mismatches we shouldn't
> just force_reg (convert_modes ()) each CONCAT operand separately and
> create
Hi!
The following testcase ICEs on x86_64-linux with -O1, the problem is
that we expand assignment from COMPONENT_REF of MEM_REF into a V4SImode
SSA_NAME. The MEM_REF has non-addressable DCmode var inside of it, and
type of a struct containing a single V4SImode element.
The bug seems to be that
