From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Lipe To: Jan Hubicka Cc: Bo Thorsen , "Billinghurst, David (CRTS)" , gcc@gcc.gnu.org Subject: Re: bogus .quad in i386/att.h Date: Wed, 10 Oct 2001 12:22:00 -0000 Message-id: <20011010142459.R21266@rjlhome.caldera.com> References: <8D00C32549556B4E977F81DBC24E985D40FFAA@crtsmail1.technol_exch.corp.riotinto.org> <01100911481107.00797@idefix> <20011010210045.B27461@atrey.karlin.mff.cuni.cz> X-SW-Source: 2001-10/msg00677.html > > > ..quad is definitely not something supported by the AT&T-derived > > > assemblers. Maybe it's a GAS thing and should be in gas.h. Maybe > > > it's > > The idea was that we need some ASM_QUAD definition in order to > compile w/o extra ifdef garbage around. And in general, I support that goal. > The ASM_QUAD will be used only for 64bit compilation att.h looked But this assertion is incorrect. Right now I have too many trees ripped up to be able to tell you definitively _what_ it's used for, but my pet targets, which are definitely not x86-64 cognizant, were getting nailed by occurrences of '.quad' in the assembler output during testsuite runs. Perhaps it's becuase you now defined ASM_OUTPUT_DOUBLE_INT so varasm.c:assemble_integer is using it behind your back to write things even when not TARGET_64BIT? RJL