gcc-10-20230531 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20230531 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20230531/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision a659b9915cdf6472992a1c2a572c4680c71f9d68

You'll find:

 gcc-10-20230531.tar.xz   Complete GCC

  SHA256=89ce76faf72c0c96b7e22f12dbb078642a7b974bb83d532af80d6754cebc43c9
  SHA1=aec6007a9f0d6f20a8f633f847abff56631c10e0

Diffs from 10-20230524 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: LSP based on GCC

[Alexandre Oliva via Gcc]

On May 30, 2023, Paul Smith  wrote:

> On Mon, 2023-05-29 at 17:16 -0300, Alexandre Oliva via Gcc wrote:
>> On May 17, 2023, Arsen Arsenović  wrote:
>> 
>> > ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to
>> > implement various bits of LSP functionality, such as handling
>> > multiple TUs.
>> 
>> I recall advancing that suggestion, reasoning that GDB was capable of
>> combining information from multiple translation units and of
>> reloading debug information, which GCC doesn't.

> I'm not sure this will work well.  The information LSP servers need is
> quite a bit more detailed (I believe) than what is found in the object
> file debug sections.

It was well understood that augmenting debug information for LSP
purposes would likely be needed, and that GDB's ability to combine debug
information from multiple units would be advantageous to this end as
well.

An mode similar to thin LTO, that outputs internal representation along
with debug information, rather than compiling all the way to machine
code, was also in my mind.  That's similar to the indexing you mention.

> LSP servers are not intended to be limited to dealing with the code
> that has already been compiled: not only do you want to be able to edit
> code before it's been compiled, but you want to be able to query new
> code as it's written in the editor, before it's even saved to disk.

ISTM there's some miscommunication here.  Using the compiler's parser
and debug information generator to index a project is no more
"compilation" than using the linker's ability to integrate multiple
translation units and the debugger's ability to take debug information
from them all to aid editing and other LSP activities amounts to
"debugging", it's just using each project's strengths to achieve the
desired goal.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Outdated paragraph in ABOUT-GCC-NLS

[peter0x44 via Gcc]

There is this paragraph in ABOUT-GCC_NLS:

By and large, only diagnostic messages have been internationalized.
Some work remains in other areas; for example, GCC does not yet allow
non-ASCII letters in identifiers.

It seems like this hasn't been true since GCC 10. I can see in release 
notes:


https://gcc.gnu.org/gcc-10/changes.html

Extended characters in identifiers may now be specified directly in the 
input encoding (UTF-8, by default), in addition to the UCN syntax 
(\u or \U) that is already supported:


static const int π = 3;
int get_naïve_pi() {
  return π;
}

I think this either needs to be updated or removed completely?