On 07/12/20 12:36 -0800, Keith Packard wrote:
>Jonathan Wakely <jwakely@redhat.com> writes:
>
>> GCC changelog files are autogenerated now, so patches should not touch
>> them. Just include the ChangeLog entry in the Git commit log (which
>> will usually end up being quoted in the patch and/or the email body of
>> the mail to gcc-patches).
>
>Awesome.
>
>> I think the right way to do this (or at least, the way that was
>> intended when basic_file_stdio.cc was added) is to provide a new file
>> and change GLIBCXX_ENABLE_CSTDIO in acinclude.m4 to use that new file.
>>
>> The two biggest downsides of that are that it duplicates a lot of the
>> file (because the diffs for your changes are small) and that the
>> correct name for your new file is already taken!
>
>I can definitely see a reason to use a separate file when implementing
>the basic_file interface on top of something other than stdio, but
>this patch doesn't do that -- it only changes the interaction between
>basic_file and stdio in a few places.
>
>I think it makes the best long-term sense to leave everything in
>basic_file_stdio.cc and avoid having the two implementations diverge in
>the future.
>
>> However, it's rather late in the GCC 11 process to make a change like
>> that (even though it's really just renaming some files). Would you be
>> OK waiting until after GCC 11 is released (in 4-5 months) to do it
>> "properly"? Is this blocking something that would require doing it
>> sooner?
>
>This patch enables the use of C++ with picolibc, a libc designed for 32-
>and 64- bit embedded systems.
>
>Right now, I'm working on getting picolibc support integrated into
>Zephyr, which uses toolchains build by crosstool-ng. I've gotten
>picolibc support merged to crosstool-ng, but the Zephyr developers are
>interested in having a single toolchain support three different libc
>implementations (newlib, newlib-nano and picolibc), but that's blocked
>on having C++ support available in all three libraries.
>
>So, you're at the bottom of my current dependency graph :-)
>
>I don't particularly need this released in gcc, but I would like to
>get patches reviewed and the general approach agreed on so that I can
>feel more confident in preparing patches to be applied to gcc in
>crosstool-ng itself.
>
>Once that's done, I'll also be able to release new Debian packages of
>GCC for embedded ARM and RISC-V and have those include suitable patches
>so that we can support embedded C++ development there too.

OK. In principle, changes to avoid using the POSIX APIs are definitely
fine. I would like to combine your new configure switch with the
existing --enable-cstdio one though.

How about the attached change for acinclude.m4 which would allow you
to do --enable-cstdio=stdio_pure? (It also adds "stdio_posix" as a
more accurate alternative spelling of the current "stdio" option.)