This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bogus .quad in i386/att.h


> > > > ..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.
Hmm, too bad :(
Can you send me the testcase?
> 
> 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?
Quite possibly. Sadly I can't undefine ASM_OUTPUT_DOUBLE_INT for 32bit
target, so we need to come with way to output it properly, most probably
by splitting the integer to two longs when 32bit target is present.

I am offline for a week. Would be OK to prepare patch sometime next week?
Honza
> 
> RJL


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]