Re: PATCH: PR target/39590: inline asm %z on amd64 says "ll" instead of "q"

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Apr 22, 2009 at 11:55 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> H.J. Lu wrote:
>>
>> On Wed, Apr 22, 2009 at 11:46 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>
>>>
>>> H.J. Lu wrote:
>>>
>>>
>>>>>>>
>>>>>>> FWIW, this change will break existing asm statement with "fild%z".
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Only on Solaris -- but you cannot eat both pieces of the cake, all we
>>>>>> can do is document this on the release notes. ?I don't think the
>>>>>> likelihood of people using fild%z in asm statements is very high,
>>>>>> while
>>>>>> the PR reporter's case is at least plausible.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> If it is the case, we can just output 'q' for %z. People can use
>>>>> GNU assembler on Solaris. I also have contacted appropriate
>>>>> Solaris people about this issue.
>>>>>
>>>>>
>>>>>
>>>>
>>>> I was told that the current Solaris assembler supports "fildq".
>>>> Maybe we can use my original patch.
>>>>
>>>>
>>>
>>> The problem with the original patch was the dependence of movq on fildq
>>> support. I think that the best solution is to split these two, so fildq
>>> detection affects only generation of fildq (see similar filds handling).
>>> My
>>> original patch was without fildq/fistpq detection, but it was IMO a good
>>> idea to generate "q" instead of "ll" for DImode access, as "q" suffix is
>>> generated for all other (sane [1]) mnemonics.
>>>
>>>
>>
>> We can add "fildq" to 64bit assembler requirement and always generate
>> `q' for "%z".
>>
>
> Current install.texi requires binutils 2.13.1 for x86 targets and fildq was
> introduced in 2.15. This requirement would force usage of binutils 2.15, so
> we either need to change required version or have fildq detection.
>

fildq was added by:

Mon Aug 10 23:22:33 1992  Ken Raeburn  (raeburn@cygnus.com)

        * sparc.h: Moved tables to BFD library.

        * i386.h (i386_optab): Add fildq, fistpq aliases used by gcc.

I think it is safe to request a GNU assembler newer than 1992 for gcc 4.5.0 :-).


-- 
H.J.