bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43725: 28.0.50; Include feature/native-comp into master


From: Andrea Corallo
Subject: bug#43725: 28.0.50; Include feature/native-comp into master
Date: Fri, 19 Feb 2021 22:03:32 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: bug-gnu-emacs@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>         43725@debbugs.gnu.org
>> Date: Fri, 19 Feb 2021 11:13:14 +0000
>>
>> >   #if EMACS_INT_MAX > LONG_MAX
>> >     return emit_rvalue_from_unsigned_long_long (...
>> >   #else
>> >     return gcc_jit_context_new_rvalue_from_long (...
>> >   #endif
>> >
>> > Does that work well?
>>
>> Unfortunately this is a compile time (for the native compiler)
>> decision.  If val fits into a long we want to emit simply that.
>
> OK, then how about my original proposal, viz.:
>
>   if (EMACS_INT_MAX > LONG_MAX)
>     {
>       if (val > LONG_MAX || val < LONG_MIN)
>         ...
>       else
>         ...
>     }
>
> You could also #ifdef this conditioned on WINDOWSNT, since MS-Windows
> is the only platform where this matters.

Okay 14e6268d14 is arranging things as follow:

 #ifdef WIDE_EMACS_INT
   if (val > LONG_MAX || val < LONG_MIN)
     return emit_rvalue_from_unsigned_long_long (comp.emacs_uint_type, val);
 #endif
   return gcc_jit_context_new_rvalue_from_long (comp.ctxt,
                                                comp.emacs_uint_type,
                                                val);


>> At this point I'm starting to think that the original formulation is
>> probably the lesser of evils.
>
> Believe me, it isn't.  For starters, it is not clear what it does.
>
>> 'emit_rvalue_from_unsigned_long_long' was added by me as libgccjit so
>> far has no long long support.  As this is shifting the numeric argument
>> to emit the code that re-create the long long equivalent using an
>> unsigned was the natural choice to avoid UB.
>>
>> Admittedly we could just cast inside
>> 'emit_rvalue_from_unsigned_long_long' and rename it into
>> 'emit_rvalue_from_long_long' but I'm not sure is that important.
>
> Either that, or some comment would be good enough.

I realized we already had also the signed variant so with 92fe7a91f4 I
removed the unsigned one and we always use 'emit_rvalue_from_long_long'
now.

  Andrea





reply via email to

[Prev in Thread] Current Thread [Next in Thread]