This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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 gas/10637: x86 assembler failed to handle [addr] in Intel mode


On Mon, Sep 14, 2009 at 11:59 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> "H.J. Lu" <hjl.tools@gmail.com> 15.09.09 00:00 >>>
>>On Mon, Sep 14, 2009 at 2:37 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>> Hi,
>>>
>>> In Intel mode, [rax + 0x100] is treated as memory while [0x100] is
>>> treated as immediate value. ?This patch changes [0x100] to memory.
>>> I'd like to hear the reason why [0x100] shouldn't be treated as memory.
>>> If there are no objections, I will check it in tomorrow.
>>>
>>
>>This is a regression against binutils 2.19. We used to generate
>>
>>y.s:3: Warning: Treating `[0xEE000F0]' as memory reference
>>
>>I am checking in my patch. ?I don't think the warning is necessary
>>here.
>
> If you already committed it, please revert it (unless you can give a good
> reason why masm compatibility doesn't matter here). 2.19 wasn't masm
> compatible in that respect (see my previous reply), and the warning was
> to tell people to change their code (it may be considered unfortunate
> that I decided to keep it generating a memory reference here when I
> added the warning - generating an offset would certainly have *forced*
> people to change their code in time).
>

Please tell me which masm treats [] as immediate. I tried one
masm and it doesn't take [] as immediate.

Changing the meaning of [] is a bad idea since it breaks the existing
assembly codes. I need a strong argument to tell my users to change
their codes.

Thanks.


-- 
H.J.


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