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: [ping][PATCH] MIPS/GAS: LUI operand handling bug fixes


"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Thu, 1 Nov 2012, Richard Sandiford wrote:
>> >  Would you please find a spare moment to have a look at the change below?  
>> > Thanks.
>> 
>> It looks oddly different from the other cases.  We handle:
>> 
>> 	addiu	$4,$4,foo+1
>> 	.eqv	foo,2
>> 
>> correctly, so I don't see why it must be an error for LUI.
>
>  Obviously silently emitting the operand as zero is worse yet.

Sure, wasn't disputing that.

>> Not that having the above work is particularly important to me.
>> It's just the inconsistency that feels wrong.
>
>  I haven't noticed the peculiarity, sorry about that.  I'll see how to 
> make the change consistent with how other machine instructions are handled 
> (as opposed to assembly macros).  Thanks for your suggestion.
>
>  I think this begs for the overflow checks I mentioned the other day too, 
> a piece like:
>
> 	addiu	$4,$4,foo+1
> 	.eqv	foo,0x12345678
>
> should IMHO fail -- do you agree?  I.e. use %lo if this is supposed not to 
> overflow:
>
> 	addiu	$4,$4,%lo(foo+1)
> 	.eqv	foo,0x12345678

Yeah, I wondered about that too, but I don't think we should change it.
If we were starting from scratch, then I agree that it would make sense
to raise the error, but changing it now (after 20ys+ history) seems
as likely to harm as help.  Let's just fix the bogus LUI output.

Richard


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