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

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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: Thu, 18 Feb 2021 20:53:05 +0000
>> 
>> >> comp.c:1174:22: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op]
>> >>  1174 |   if (val > LONG_MAX || val < LONG_MIN)
>> >>       |                      ^~
>> >> 
>> >> Not sure what's the best way to silence it or if we want to revert to
>> >> the previous formulation.
>> 
>> Hi Eli,
>> 
>> sorry just to make sure I understand the suggestions:
>> 
>> > You can either condition that by WIDE_EMACS_INT,
>> 
>> Put it under #ifdef I guess.
>> 
>> > or add a comparison > between LONG_MAX and INT_MAX.
>> 
>> Not sure I understand how you'd write this.
>
> Maybe it will be easier to do something like this instead:
>
>   #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.

At this point I'm starting to think that the original formulation is
probably the lesser of evils.

> Btw, why does the 'long long' variant say "unsigned", while the 'long'
> variant doesn't?


'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.

  Andrea