.

The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:fe54b57728c09ab0389e2bb3f079d5210566199d

commit r14-6569-gfe54b57728c09ab0389e2bb3f079d5210566199d
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Dec 14 23:23:34 2023 +0000

    libstdc++: Implement C++23 <print> header [PR107760]
    
    This adds the C++23 std::print functions, which use std::format to write
    to a FILE stream or std::ostream (defaulting to stdout).
    
    The new extern symbols are in the libstdc++exp.a archive, so we aren't
    committing to stable symbols in the DSO yet. There's a UTF-8 validating
    and transcoding function added by this change. That can certainly be
    optimized, but it's internal to libstdc++exp.a so can be tweaked later
    at leisure.
    
    Currently the external symbols work for all targets, but are only
    actually used for Windows, where it's necessary to transcode to UTF-16
    to write to the console.  The standard seems to encourage us to also
    diagnose invalid UTF-8 for non-Windows targets when writing to a
    terminal (and only when writing to a terminal), but I'm reliably
    informed that that wasn't the intent of the wording. Checking for
    invalid UTF-8 sequences only needs to happen for Windows, which is good
    as checking for a terminal requires a call to isatty, and on Linux that
    uses an ioctl syscall, which would make std::print ten times slower!
    
    Testing the std::print behaviour is difficult if it depends on whether
    the output stream is connected to a Windows console or not, as we can't
    (as far as I know) do that non-interactively in DejaGNU. One of the new
    tests uses the internal __write_to_terminal function directly. That
    allows us to verify its UTF-8 error handling on POSIX targets, even
    though that's not actually used by std::print. For Windows, that
    __write_to_terminal function transcodes to UTF-16 but then uses
    WriteConsoleW which fails unless it really is writing to the console.
    That means the 27_io/print/2.cc test FAILs on Windows. The UTF-16
    transcoding has been manually tested using mingw-w64 and Wine, and
    appears to work.
    
    libstdc++-v3/ChangeLog:
    
            PR libstdc++/107760
            * include/Makefile.am: Add new header.
            * include/Makefile.in: Regenerate.
            * include/bits/version.def (__cpp_lib_print): Define.
            * include/bits/version.h: Regenerate.
            * include/std/format (__literal_encoding_is_utf8): New function.
            (_Seq_sink::view()): New member function.
            * include/std/ostream (vprintf_nonunicode, vprintf_unicode)
            (print, println): New functions.
            * include/std/print: New file.
            * src/c++23/Makefile.am: Add new source file.
            * src/c++23/Makefile.in: Regenerate.
            * src/c++23/print.cc: New file.
            * testsuite/27_io/basic_ostream/print/1.cc: New test.
            * testsuite/27_io/print/1.cc: New test.
            * testsuite/27_io/print/2.cc: New test.

Done for GCC 14