This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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