"exotic" machine modes

Jan Beulich JBeulich@novell.com
Wed May 19 05:12:00 GMT 2004


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
under -O2 and -O3. While I could obviously make those expected failures,
this doesn't seem correct. Instead, I'd rather put under question the
existence of any of the modes for which int_mode_for_mode() returns
BLKmode (which will always trigger the abort()s in
extract_bit_field()/store_bit_field()), namely because of the total
width exceeding that of TImode. The list of these would be V4DI, V8SI,
V8DI, V4DF, V8SF, V8DF, and V16SF (possibly also XC, TC, and CTI). Now,
for all of these except V4DF and V16SF type nodes are not being created
(at least not in the architecture independent part of the tree, making
the types mostly unusable), preventing the internal error by way of
earlier meaningful error messages.
The questions thus are:
- 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?
- Since there is on a single acrchitecture using V16SF (sh), shouldn't
it be moved there?
- 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?
- Alternatively, if the compiler intends to generically support these
vector modes, shouldn't the above mentioned abort() cases in expmed.c be
dealt with?

Thanks, Jan



More information about the Gcc-bugs mailing list