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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 43725@debbugs.gnu.org
> Date: Mon, 15 Mar 2021 15:43:07 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The issue is this: our Lisp files are generally encoded in UTF-8.  But
> > there's no guarantee that GCC expects the source to be encoded in
> > UTF-8.  If the text we submit to libgccjit for compilation is in the
> > same encoding as the original .el files, then shouldn't we tell GCC
> > its actual encoding, to make sure non-ASCII text aren't mangled?
> 
> The only generated text we are passing to libgccjit is feed to
> 'gcc_jit_context_new_string_literal'.

What kind of "string literals" go this way?  Are these constant
strings from Lisp, or can some other data types from Lisp end up being
passed like that?

> This text is generated from 'Fprin1_to_string' that we use to
> essentially render in form of text immediate objects.  I thought
> this was disconnected from the encoding of the source file, am I
> wrong?

If the original text is from Lisp strings in the Lisp source file,
then it isn't disconnected.  Those strings could include non-ASCII
characters, and they come out in UTF-8 (well, almost, modulo the raw
bytes etc.).