i386 vs. .quad

i386 vs. .quad

[Robert Lipe]

We've had this conversation before, and the onus fell on me to prove
that ASM_QUAD was actually used in an IA32 (x86-64-not) build.  This
has broken my target as well as several others and has been reported a
couple of times.  It shows up in a bootstrap on the trunk as of today:

/play/tmp/trunk/gcc/xgcc -B/play/tmp/trunk/gcc/ -B/usr/local/i686-pc-sco3.2v5.0.
6/bin/ -B/usr/local/i686-pc-sco3.2v5.0.6/lib/ -isystem /usr/local/i686-pc-sco3.2
v5.0.6/include -fgnu-runtime -c -I. -I/play/gcc-trunk/libobjc -g -O2 -DIN_GCC -D
IN_TARGET_LIBS -I/play/gcc-trunk/libobjc/objc -I/play/gcc-trunk/libobjc/../gcc -
I/play/gcc-trunk/libobjc/../gcc/config -I../../gcc -I/play/gcc-trunk/libobjc/../
include /play/gcc-trunk/libobjc/Object.m -o Object.o
/usr/tmp//cc518zSw.s:2466:unknown directive: .quad

The assembler fragment looks like:

        .align 32
        .type   _OBJC_SELECTOR_TABLE,@object
        .size   _OBJC_SELECTOR_TABLE,168
_OBJC_SELECTOR_TABLE:
        .long   _OBJC_METH_VAR_NAME_21
        .long   _OBJC_METH_VAR_TYPE_17
        .long   _OBJC_METH_VAR_NAME_60
        .long   _OBJC_METH_VAR_TYPE_17
	[ munch ] 
       .long   _OBJC_METH_VAR_TYPE_32
        .long   _OBJC_METH_VAR_NAME_27
        .long   _OBJC_METH_VAR_TYPE_32
        .quad           0
        .align 4
        .type   _OBJC_MODULES,@object
        .size   _OBJC_MODULES,16
_OBJC_MODULES:
        .long   8
        .long   16


Jan, can you please make the behaviour of ASM_QUAD match that of the
comments and be sure that it's NOT used in a 32-bit build?  IMO, it
does not belong in att.h and it does not belong in sco5.h.  It's a gas
feature and belongs in a gas-specific place.

Thank you,
RJL

Re: i386 vs. .quad

[Jan Hubicka]

> Jan, can you please make the behaviour of ASM_QUAD match that of the
> comments and be sure that it's NOT used in a 32-bit build?  IMO, it
I am working on it. Unfortunatelly pushing the ASM_OUTPUT macros to target
structures turned out to be more involved than I've expected so I am re-trying
this time push just subset of these macros not all as I've wanted originally.
> does not belong in att.h and it does not belong in sco5.h.  It's a gas
> feature and belongs in a gas-specific place.
Isn't there some AT&T standarized pseudo-op for that?

Honza
> 
> Thank you,
> RJL

Re: i386 vs. .quad

[Robert Lipe]

> > Jan, can you please make the behaviour of ASM_QUAD match that of the
> > comments and be sure that it's NOT used in a 32-bit build?  IMO, it
> I am working on it. Unfortunatelly pushing the ASM_OUTPUT macros to target

Thanx.

> > does not belong in att.h and it does not belong in sco5.h.  It's a gas
> > feature and belongs in a gas-specific place.
> Isn't there some AT&T standarized pseudo-op for that?

Not that I know of; why would there be?   Since this predates C99 with
'long long', it's really sort of useless for an assembler for a 32 bit
part to have such a concept.

RJL