This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: PATCH: PR target/39911: The 'z' suffix doesn't work with 16bit integer insn


On Mon, Apr 27, 2009 at 5:02 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> H.J. Lu wrote:
>
>>>>> This doesn't solve the problem. You need to add the 'w' suffix for
>>>>> integer
>>>>> instructions with memory operand.
>>>>>
>>>>>
>>>>
>>>> This is how %z always worked and that is excatly the reason why I try to
>>>> fix
>>>> this wrong behaviour.
>>>>
>>>>
>>>
>>> I am testing a patch in
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39911
>>>
>>> Since "%z' never really worked on integer instructions, I made "%Z" for
>>> integer instructions only while providing backward compatibility for
>>> existing
>>> asm statements.
>>>
>>>
>>
>> This is the patch with a testcase. Tested on Linux/Intel64 with both 32/64
>> bits.
>> OK for trunk?
>>
>
> I have done a bit of research and found that:
> - %z is _never_ used with any x87 insn outside gcc sources.
> - there are usages of %z with integer insns [1] and a couple of bugreports
> of %z with integer ops.
>
> Due to this, I don't think that we need to provide backward compatibility
> with _undocumented_ %z for x87 insns.
>
> Attached patch now fixes the PR by introducing "%Z" for all x87 mnemonics,
> clearly separated from "%z" that is/was primarily intended for integer x86
> mnemonics. However, to provide high level of backward compatibility, new %z
> handling falls through to %Z handling, so the majority (HImode and DImode
> conversions with x87 integer insns not included) of x87 operations are still
> handled the way it was before. A warning is emitted when %z is used with FP
> operand, so the code could eventually be fixed.
>
> To fix the fallout from gcc sources itself, generation of x87 mnemonics now
> uses %Z instead of %z.
>
> Instead of ICEing, the compiler now produces an informative message to tell
> what is wrong with %z and %Z modified operand. Since users are using them
> (well %z at least), I think that we can document these two modifiers and put
> them into general use.
>
> 2009-04-27 ?Uros Bizjak ?<ubizjak@gmail.com>
>
> ? PR target/39911
> ? * config/i386/i386.c (print_operand) ['Z']: Handle floating point
> ? and integer modes for x87 operands. ?Do not ICE for unsupported size,
> ? generate error instead. ?Generate error for unsupported operand types.
> ? ['z']: Do not handle HImode memory operands specially. ?Warning
> ? for floating-point operands. ?Fallthru to 'Z' for unsupported operand
> ? types. ?Do not ICE for unsupported size, generate error instead.
> ? (output_387_binary_op): Use %Z to output operands.
> ? (output_fp_compare): Ditto.
> ? (output_387_reg_move): Ditto.
>
> testsuite/ChangeLog:
>
> 2009-04-27 ?Uros Bizjak ?<ubizjak@gmail.com>
> ? ? ? H.J. Lu ?<hongjiu.lu@intel.com>
>
> ? PR target/39911
> ? * gcc.target/i386/pr39911.c: New test.
>
> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}.
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39949

-- 
H.J.


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