This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: "exotic" machine modes
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 19 May 2004 17:59:35 -0700
- Subject: Re: "exotic" machine modes
- References: <s0aa3fca.090@emea1-mh.id2.novell.com>
Jan Beulich wrote:
While putting together a generic vector mode test set for the test suite
I ran into an internal compiler error when dealing with V16SF and V4DF
Some general comments.
- Sending mail to gcc-bugs is really not very useful. gcc-bugs is
primarily used for bugzilla traffic. Anything that isn't bugzilla
traffic is likely to be missed. You are better off sending questions
like this to the gcc list.
- You didn't mention the gcc version. It appears you are looking at old
gcc sources. If you want to do development, or comment on development,
you have to look at current development sources. Since I am not sure
what gcc sources you are looking at, I am not sure how to answer some of
the questions.
- I believe that there are others working on vector testsuites, there
may already be one in current sources.
- Most gcc extensions are implemented first, and then designed later, so
you can't expect them to behave reasonably in corner cases until after a
few years of bug fixing.
- There are a number of other people working on the vector extensions.
Probably none of them saw this message.
- Since there is no user of V4DF and the compiler doesn't implement it
properly, shouldn't the type node generation for it be eliminated?
It is already gone. However, it may have been replaced with other code
that might cause trouble for you depending on what exactly the bug is
that you are reporting. Testcases are usually better than trying to
describe problems.
- Since there is on a single acrchitecture using V16SF (sh), shouldn't
it be moved there?
The type node is gone. It is still in machmode.def, but that seems to
be relatively harmless. Again, there are other changes here.
- Shouldn't, if the compiler doesn't support them anyway, any modes for
which no type nodes are generated be removed from machmode.def? Or
alternatively, should the type node generation directly depend on the
set of available modes?
The modes are needed for RTL operations. It is possible (since about
last November) for targets to define their own modes, so we could
perhaps move things from machmode.def to targets if necessary. It isn't
clear that there is a problem here though.
- Alternatively, if the compiler intends to generically support these
vector modes, shouldn't the above mentioned abort() cases in expmed.c be
dealt with?
If you can make the compiler abort, then yes, something is broken. The
fix depends on what exactly the problem is. For that, a testcase would
be helpful.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com