public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "irar at il dot ibm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c
Date: Mon, 03 May 2010 12:31:00 -0000	[thread overview]
Message-ID: <20100503123100.10216.qmail@sourceware.org> (raw)
In-Reply-To: <bug-43901-682@http.gcc.gnu.org/bugzilla/>



------- Comment #12 from irar at il dot ibm dot com  2010-05-03 12:30 -------

> Well.  For loops we'd have disqualified it as there is no vector
> type for the external def (well, the stmt inside the loop).

I don't think that's true. With -fno-tree-pre we get the same ICE for loop
vectorization for:

#define N 64

union U
{
  __complex__ int ci;
  __complex__ float cf;
};

union U u[N];

void foo (double f1, double f2)
{
  int i;

  for (i=0; i<N; i++)
    {
      __real__ u[i].cf = f1;
      __imag__ u[i].cf = f2;
    }
}

> So we do not do this for SLP?  In that case
> yes, if we can return false at this point then we should replace this
> (and similar) asserts with return false.  Or we should fix
> the code that scans the BB initially and sets vector types properly?

The loop scan that sets vector types, only checks lhs types (or the smallest
type in stmt) in order to decide on vectorization factor. There is a similar
scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it
also looks only at lhs. 

The failure occurs in analysis, so it's ok to return false at this point. 
But I don't understand why external def has to have the same size as the lhs?
(And it is, of course, possible that both types are vectorizable, but still the
rhs type is bigger than the lhs type).

Thanks,
Ira

> 
> Thanks,
> Richard.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901


  parent reply	other threads:[~2010-05-03 12:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-26 19:19 [Bug middle-end/43901] New: " hjl dot tools at gmail dot com
2010-04-27  5:53 ` [Bug middle-end/43901] " irar at il dot ibm dot com
2010-04-27  9:36 ` rguenth at gcc dot gnu dot org
2010-04-27 13:07 ` hjl dot tools at gmail dot com
2010-04-27 13:11 ` rguenth at gcc dot gnu dot org
2010-05-02  5:51 ` irar at il dot ibm dot com
2010-05-02 10:44 ` ubizjak at gmail dot com
2010-05-02 10:46 ` ubizjak at gmail dot com
2010-05-02 10:50 ` ubizjak at gmail dot com
2010-05-02 11:02 ` ubizjak at gmail dot com
2010-05-02 11:08 ` irar at il dot ibm dot com
2010-05-02 12:12 ` irar at il dot ibm dot com
2010-05-03 11:17 ` rguenth at gcc dot gnu dot org
2010-05-03 11:17 ` rguenther at suse dot de
2010-05-03 12:31 ` irar at il dot ibm dot com [this message]
2010-05-03 12:35 ` rguenther at suse dot de
2010-05-05  9:02 ` irar at il dot ibm dot com
2010-05-06  6:43 ` irar at gcc dot gnu dot org
2010-05-10  8:18 ` irar at il dot ibm dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100503123100.10216.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).