[PATCH] ix86: wrap constants

[H.J. Lu]

On Fri, Jun 4, 2021 at 5:34 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 04.06.2021 14:26, H.J. Lu wrote:
> > On Fri, Jun 4, 2021 at 5:14 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> Non-64-bit code should get handled the same with or without BFD64. This
> >> wasn't the case though in a number of situations (and quite likely there
> >> are more that I haven't spotted yet).
> >>
> >> It's not very nice to tie the check in md_apply_fix() to object_64bit,
> >> but afaict at that time we have no record anymore of the mode an insn
> >> was assembled in (it might also have been data). This doesn't look to be
> >> the first inconsistency of this kind, though. In x86_cons() it's even
> >> less clear what the right approach would be: flag_code shouldn't matter
> >> for data emission, but instead we'd need to know from which mode(s) the
> >> data actually gets accessed. On this basis, signed_cons() also gets
> >> adjusted.
> >>
> >> gas/
> >> 2021-06-XX  Jan Beulich  <jbeulich@suse.com>
> >>
> >>         * config/tc-i386.c (extend_to_address): New.
> >>         (x86_cons, i386_finalize_immediate, md_apply_fix): Use it.
> >>         (signed_cons): Use object_64bit.
> >>         * testsuite/gas/i386/wrap32.s, testsuite/gas/i386/wrap32-data.d,
> >>         testsuite/gas/i386/wrap32-text.d: New.
> >>         * testsuite/gas/i386/i386.exp: Run new tests.
> >>
> >> --- a/gas/config/tc-i386.c
> >> +++ b/gas/config/tc-i386.c
> >> @@ -2457,6 +2457,19 @@ fits_in_unsigned_long (addressT num ATTR
> >>  #endif
> >>  }                              /* fits_in_unsigned_long() */
> >>
> >> +static INLINE valueT extend_to_address (addressT num)
> >> +{
> >> +#ifdef BFD64
> >> +  if (fits_in_unsigned_long(num))
> >> +    return (num ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
> >> +
> >> +  if (!fits_in_signed_long (num))
> >> +    return num & 0xffffffff;
> >> +#endif
> >
> > Shouldn't this check apply only to 32-bit objects?
>
> It already does (as far as it should; the check should really
> apply to non-64-bit code only) - callers use either !object_64bit
> up front, or "flag_code != CODE_64BIT". As per what the description
> says, the latter is really how we'd like it to be (because for
> 32-bit code it shouldn't matter what container it lives in), but
> - in x86_cons() applicability of flag_code is at best questionable,
> - in md_apply_fix() we don't have that information available.
>

Can you rename extend_to_address to something like
extend_to_32bit_address?  OK with that change.

Thanks.

-- 
H.J.