On 14/07/12 04:21, Mike Stump wrote: > On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote: >> On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd <froy...@mozilla.com> wrote: >>> On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote: >>>> I just checked all in tree gcc targets, and none claim OImode support. >>> >>> ./s390/s390-modes.def:23:INT_MODE (OI, 32); >>> ./spu/spu-modes.def:29:INT_MODE (OI, 32); >>> ./ia64/ia64-modes.def:68:INT_MODE (OI, 32); >>> ./i386/i386-modes.def:88:INT_MODE (OI, 32); >>> ./arm/arm-modes.def:82:INT_MODE (OI, 32); >>> >>> At least for ARM, OImode gets used for Neon intrinsics. Can't speak for >>> the other ports, though. >> >> On x86_64-unknown-linux-gnu: >> >> $ cat t.c >> int __attribute__((__mode__(DI))) di; >> int __attribute__((__mode__(TI))) ti; >> int __attribute__((__mode__(OI))) oi; >> >> $ ./xgcc -B. t.c >> t.c:3:1: error: unable to emulate ‘OI’ >> int __attribute__((__mode__(OI))) oi; >> ^ >> >> This is trunk r189365. > > Yup, exactly as I expected. The arm folks I suspect will discover the same. >
OImode on ARM only exists to support vector copying operations and the other guff that the compiler can't handle internally without it. It is /not/ intended to be available as a type to the user, in particular, it is not intended to be available for arithmetic. The same is also true of TI mode and any other xImode larger than DImode. R.
