Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master

[Georg-Johann Lay]

Am 09.12.22 um 22:14 schrieb Vladimir Makarov:


On 2022-12-09 14:23, Georg-Johann Lay wrote:

There is the following code size regression, filed as

https://gcc.gnu.org/PR90706



I am sorry, I feel your frustration. I was not aware of this PR. 
Unfortunately, the PR was marked as P4 and I have too many open PRs and 
should prioritize them.


I've just started to work on this issue.  It is hard for me to say when 
it will be fixed.  I'll give an update on the next week.


Hi Vladimir,

Thank you so much.

As far as I understand, avr is a ternary target and hence PRs for avr 
will have priority P4 or P5?


Johann



Simple test cases are, for example

#define PORT (*((unsigned char volatile*) 0x24))

unsigned short var16;

void func (void)
{
    if (2048000ul * var16 > 120ul)
    PORT |= 1;
}

When I compile it with

$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o

the code size increases from 36 bytes (v8) to 88 bytes (v13).

Apart from that, register pressure is much higher because a frame 
pointer is set up for no reason, and the values go through stack slots 
for no reason.


Even test cases which don't require any code like

long func2 (void)
{
    long var32;
    __asm ("; some code %0" : "=r" (var32));
    return var32;
}

increase in register pressure (x2), stack usage (from 0 to 6 bytes) 
and code size from 2 bytes (v8) to 34 bytes (v13).


Some projects like QMK "solved" the problem by declaring GCC > v8 to 
be "incompatible" with their project, see

https://github.com/qmk/qmk_firmware/issues/6719

In own projects I observed the problem, too, and the only solution is 
to use v8 or older.  Options like -fcaller-saves or -fira-algorithm= 
have no effect.


To configure, I used --target=avr --disable-nls --with-dwarf2 
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared, 
so nothing special.


The problem is present in v9, v10, v11, v12 and master (future v13), 
so sitting around for quite a while, so maybe it's not fixed because 
RA maintainers are not aware of the problem.

Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master

[Richard Biener via Gcc]

> Am 10.12.2022 um 13:15 schrieb Georg-Johann Lay :
> 
> 
> 
>> Am 09.12.22 um 22:14 schrieb Vladimir Makarov:
>>> On 2022-12-09 14:23, Georg-Johann Lay wrote:
>>> There is the following code size regression, filed as
>>> 
>>> https://gcc.gnu.org/PR90706
>>> 
>> I am sorry, I feel your frustration. I was not aware of this PR. 
>> Unfortunately, the PR was marked as P4 and I have too many open PRs and 
>> should prioritize them.
>> I've just started to work on this issue.  It is hard for me to say when it 
>> will be fixed.  I'll give an update on the next week.
> 
> Hi Vladimir,
> 
> Thank you so much.
> 
> As far as I understand, avr is a ternary target and hence PRs for avr will 
> have priority P4 or P5?

Yes, since AVR is not primary or secondary regressions specific to AVR are P4 
or lower.
If the same issue can be observed on a target that is secondary or primary that 
would change this aspect.

Richard 

> Johann
> 
> 
>>> Simple test cases are, for example
>>> 
>>> #define PORT (*((unsigned char volatile*) 0x24))
>>> 
>>> unsigned short var16;
>>> 
>>> void func (void)
>>> {
>>> if (2048000ul * var16 > 120ul)
>>> PORT |= 1;
>>> }
>>> 
>>> When I compile it with
>>> 
>>> $ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
>>> 
>>> the code size increases from 36 bytes (v8) to 88 bytes (v13).
>>> 
>>> Apart from that, register pressure is much higher because a frame pointer 
>>> is set up for no reason, and the values go through stack slots for no 
>>> reason.
>>> 
>>> Even test cases which don't require any code like
>>> 
>>> long func2 (void)
>>> {
>>> long var32;
>>> __asm ("; some code %0" : "=r" (var32));
>>> return var32;
>>> }
>>> 
>>> increase in register pressure (x2), stack usage (from 0 to 6 bytes) and 
>>> code size from 2 bytes (v8) to 34 bytes (v13).
>>> 
>>> Some projects like QMK "solved" the problem by declaring GCC > v8 to be 
>>> "incompatible" with their project, see
>>> https://github.com/qmk/qmk_firmware/issues/6719
>>> 
>>> In own projects I observed the problem, too, and the only solution is to 
>>> use v8 or older.  Options like -fcaller-saves or -fira-algorithm= have no 
>>> effect.
>>> 
>>> To configure, I used --target=avr --disable-nls --with-dwarf2 
>>> --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared, so 
>>> nothing special.
>>> 
>>> The problem is present in v9, v10, v11, v12 and master (future v13), so 
>>> sitting around for quite a while, so maybe it's not fixed because RA 
>>> maintainers are not aware of the problem.

Bug with GCC's handling of lifetimes of implicit-lifetime types

[Gavin Ray via Gcc]

This came up when I was asking around about what the proper way was to:

- Allocate aligned storage for a buffer pool/page cache
- Then create pointers to "Page" structs inside of the storage memory area

I thought something like this might do:

struct buffer_pool
{
  alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE];
  page* pages = new (storage) page[NUM_PAGES];
}

Someone told me that this was a valid solution but not to do it, because it
wouldn't function properly on GCC
They gave this as a reproduction:

https://godbolt.org/z/EhzM37Gzh

I'm not experienced enough with C++ to grok the connection between this
repro and my code, but I figured
I'd post it on the mailing list in case it was useful for others/might get
fixed in the future =)

They said it had to do with "handling of lifetimes of implicit-lifetime
types"

Re: Bug with GCC's handling of lifetimes of implicit-lifetime types

[Jonathan Wakely via Gcc]

On Sat, 10 Dec 2022 at 17:42, Gavin Ray via Gcc  wrote:
>
> This came up when I was asking around about what the proper way was to:
>
> - Allocate aligned storage for a buffer pool/page cache
> - Then create pointers to "Page" structs inside of the storage memory area
>
> I thought something like this might do:
>
> struct buffer_pool
> {
>   alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE];
>   page* pages = new (storage) page[NUM_PAGES];
> }
>
> Someone told me that this was a valid solution but not to do it, because it
> wouldn't function properly on GCC
> They gave this as a reproduction:
>
> https://godbolt.org/z/EhzM37Gzh
>
> I'm not experienced enough with C++ to grok the connection between this
> repro and my code,

Me neither. I don't think there is any connection, because I don't
think the repro shows what they think it shows.

> but I figured
> I'd post it on the mailing list in case it was useful for others/might get
> fixed in the future =)
>
> They said it had to do with "handling of lifetimes of implicit-lifetime
> types"

I don't think that code is a valid implementation of
start_lifetime_as. Without a proper implementation of
start_lifetime_as (which GCC doesn't provide yet), GCC does not allow
you to read the bytes of a float as an int, and doesn't give you the
bytes of 1.0f, it gives you 0.

https://godbolt.org/z/dvncY9Pea works for GCC. But this has nothing to
do your code above, as far as I can see.

Re: Bug with GCC's handling of lifetimes of implicit-lifetime types

[Andrew Pinski via Gcc]

On Sat, Dec 10, 2022 at 10:36 AM Jonathan Wakely via Gcc
 wrote:
>
> On Sat, 10 Dec 2022 at 17:42, Gavin Ray via Gcc  wrote:
> >
> > This came up when I was asking around about what the proper way was to:
> >
> > - Allocate aligned storage for a buffer pool/page cache
> > - Then create pointers to "Page" structs inside of the storage memory area
> >
> > I thought something like this might do:
> >
> > struct buffer_pool
> > {
> >   alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE];
> >   page* pages = new (storage) page[NUM_PAGES];
> > }
> >
> > Someone told me that this was a valid solution but not to do it, because it
> > wouldn't function properly on GCC
> > They gave this as a reproduction:
> >
> > https://godbolt.org/z/EhzM37Gzh
> >
> > I'm not experienced enough with C++ to grok the connection between this
> > repro and my code,
>
> Me neither. I don't think there is any connection, because I don't
> think the repro shows what they think it shows.
>
> > but I figured
> > I'd post it on the mailing list in case it was useful for others/might get
> > fixed in the future =)
> >
> > They said it had to do with "handling of lifetimes of implicit-lifetime
> > types"
>
> I don't think that code is a valid implementation of
> start_lifetime_as. Without a proper implementation of
> start_lifetime_as (which GCC doesn't provide yet), GCC does not allow
> you to read the bytes of a float as an int, and doesn't give you the
> bytes of 1.0f, it gives you 0.
>
> https://godbolt.org/z/dvncY9Pea works for GCC. But this has nothing to
> do your code above, as far as I can see.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115#c10 for what
is going wrong.
Basically GCC does not have a way to express this in the IR currently
and there are proposals there on how to do it.

Thanks,
Andrew Pinski

Re: Bug with GCC's handling of lifetimes of implicit-lifetime types

[Gavin Ray via Gcc]

Ahh alright, thanks Jonathan & Andrew, appreciate the replies

@Jonathan
> ... "Without a proper implementation of start_lifetime_as (which GCC
doesn't provide yet)"

I mailed the author of that proposal yesterday after learning about it
(it's very useful!) and they told me as much
Had written them to ask about a naive implementation I tried to see if I
understood it correctly:
- P2590R2: "Explicit lifetime management" (start_lifetime_as)
implementation (github.com)



>
>
>
> *"Your code copies bytes around. The compiler *might* optimise that away
> but I'mnot sure. The idea of start_lifetime_as is that it would compile
> down to noinstructions - it would always be a no-op at runtime. My
> understanding is thatit cannot be implemented by the user in C++, the
> implementation would have to bea "magic" function using compiler
> intrinsics."*


About the memmove thing, based on a Godbolt link I found from Google -- I
think it's relying on UB to initialize storage + lifetime?
- Compiler Explorer (godbolt.org) 

But I don't pretend to understand the technicalities of the above, ha.

@Andrew

Would you be willing to attempt to explain the linked issue to someone not
familiar with the details of C++'s object storage + lifetime model?
Seems like an interesting thing but I don't have the technical
background/context to understand the full discussion happening there.






On Sat, Dec 10, 2022 at 1:44 PM Andrew Pinski  wrote:

> On Sat, Dec 10, 2022 at 10:36 AM Jonathan Wakely via Gcc
>  wrote:
> >
> > On Sat, 10 Dec 2022 at 17:42, Gavin Ray via Gcc  wrote:
> > >
> > > This came up when I was asking around about what the proper way was to:
> > >
> > > - Allocate aligned storage for a buffer pool/page cache
> > > - Then create pointers to "Page" structs inside of the storage memory
> area
> > >
> > > I thought something like this might do:
> > >
> > > struct buffer_pool
> > > {
> > >   alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE];
> > >   page* pages = new (storage) page[NUM_PAGES];
> > > }
> > >
> > > Someone told me that this was a valid solution but not to do it,
> because it
> > > wouldn't function properly on GCC
> > > They gave this as a reproduction:
> > >
> > > https://godbolt.org/z/EhzM37Gzh
> > >
> > > I'm not experienced enough with C++ to grok the connection between this
> > > repro and my code,
> >
> > Me neither. I don't think there is any connection, because I don't
> > think the repro shows what they think it shows.
> >
> > > but I figured
> > > I'd post it on the mailing list in case it was useful for others/might
> get
> > > fixed in the future =)
> > >
> > > They said it had to do with "handling of lifetimes of implicit-lifetime
> > > types"
> >
> > I don't think that code is a valid implementation of
> > start_lifetime_as. Without a proper implementation of
> > start_lifetime_as (which GCC doesn't provide yet), GCC does not allow
> > you to read the bytes of a float as an int, and doesn't give you the
> > bytes of 1.0f, it gives you 0.
> >
> > https://godbolt.org/z/dvncY9Pea works for GCC. But this has nothing to
> > do your code above, as far as I can see.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115#c10 for what
> is going wrong.
> Basically GCC does not have a way to express this in the IR currently
> and there are proposals there on how to do it.
>
> Thanks,
> Andrew Pinski
>

[PATCH v4 1/3] libcpp: reject codepoints above 0x10FFFF

[Ben Boeckel via Gcc]

Unicode does not support such values because they are unrepresentable in
UTF-16.

libcpp/

* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such values.

Signed-off-by: Ben Boeckel 
---
 libcpp/charset.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index 12a398e7527..324b5b19136 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -158,6 +158,10 @@ struct _cpp_strbuf
encoded as any of DF 80, E0 9F 80, F0 80 9F 80, F8 80 80 9F 80, or
FC 80 80 80 9F 80.  Only the first is valid.
 
+   Additionally, Unicode declares that all codepoints above 0010 are
+   invalid because they cannot be represented in UTF-16. As such, all 5- and
+   6-byte encodings are invalid.
+
An implementation note: the transformation from UTF-16 to UTF-8, or
vice versa, is easiest done by using UTF-32 as an intermediary.  */
 
@@ -216,7 +220,7 @@ one_utf8_to_cppchar (const uchar **inbufp, size_t 
*inbytesleftp,
   if (c <= 0x3FF && nbytes > 5) return EILSEQ;
 
   /* Make sure the character is valid.  */
-  if (c > 0x7FFF || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ;
+  if (c > 0x10 || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ;
 
   *cp = c;
   *inbufp = inbuf;
@@ -320,7 +324,7 @@ one_utf32_to_utf8 (iconv_t bigend, const uchar **inbufp, 
size_t *inbytesleftp,
   s += inbuf[bigend ? 2 : 1] << 8;
   s += inbuf[bigend ? 3 : 0];
 
-  if (s >= 0x7FFF || (s >= 0xD800 && s <= 0xDFFF))
+  if (s > 0x10 || (s >= 0xD800 && s <= 0xDFFF))
 return EILSEQ;
 
   rval = one_cppchar_to_utf8 (s, outbufp, outbytesleftp);
-- 
2.38.1

[PATCH v4 0/3] RFC: P1689R5 support

[Ben Boeckel via Gcc]

Hi,

This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ensure that `import
some_module;` can be satisfied in time by making sure that the TU with
`export import some_module;` is compiled first.

[P1689R5]: https://isocpp.org/files/papers/P1689R5.html

I'd like feedback on the approach taken here with respect to the
user-visible flags. I'll also note that header units are not supported
at this time because the current `-E` behavior with respect to `import
;` is to search for an appropriate `.gcm` file which is not
something such a "scan" can support. A new mode will likely need to be
created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
where headers are looked up "normally" and processed only as much as
scanning requires.

For the record, Clang has patches with similar flags and behavior by
Chuanqi Xu here:

https://reviews.llvm.org/D134269

with the same flags.

Thanks,

--Ben

---
v3 -> v4:

- add missing spaces between function names and arguments

v2 -> v3:

- changelog entries moved to commit messages
- documentation updated/added in the UTF-8 routine editing

v1 -> v2:

- removal of the `deps_write(extra)` parameter to option-checking where
  ndeeded
- default parameter of `cpp_finish(fdeps_stream = NULL)`
- unification of libcpp UTF-8 validity functions from v1
- test cases for flag parsing states (depflags-*) and p1689 output
  (p1689-*)

Ben Boeckel (3):
  libcpp: reject codepoints above 0x10
  libcpp: add a function to determine UTF-8 validity of a C string
  p1689r5: initial support

 gcc/c-family/c-opts.cc|  40 +++-
 gcc/c-family/c.opt|  12 +
 gcc/cp/module.cc  |   3 +-
 gcc/doc/invoke.texi   |  15 ++
 gcc/testsuite/g++.dg/modules/depflags-f-MD.C  |   2 +
 gcc/testsuite/g++.dg/modules/depflags-f.C |   1 +
 gcc/testsuite/g++.dg/modules/depflags-fi.C|   3 +
 gcc/testsuite/g++.dg/modules/depflags-fj-MD.C |   3 +
 gcc/testsuite/g++.dg/modules/depflags-fj.C|   4 +
 .../g++.dg/modules/depflags-fjo-MD.C  |   4 +
 gcc/testsuite/g++.dg/modules/depflags-fjo.C   |   5 +
 gcc/testsuite/g++.dg/modules/depflags-fo-MD.C |   3 +
 gcc/testsuite/g++.dg/modules/depflags-fo.C|   4 +
 gcc/testsuite/g++.dg/modules/depflags-j-MD.C  |   2 +
 gcc/testsuite/g++.dg/modules/depflags-j.C |   3 +
 gcc/testsuite/g++.dg/modules/depflags-jo-MD.C |   3 +
 gcc/testsuite/g++.dg/modules/depflags-jo.C|   4 +
 gcc/testsuite/g++.dg/modules/depflags-o-MD.C  |   2 +
 gcc/testsuite/g++.dg/modules/depflags-o.C |   3 +
 gcc/testsuite/g++.dg/modules/modules.exp  |   1 +
 gcc/testsuite/g++.dg/modules/p1689-1.C|  18 ++
 gcc/testsuite/g++.dg/modules/p1689-1.exp.json |  27 +++
 gcc/testsuite/g++.dg/modules/p1689-2.C|  16 ++
 gcc/testsuite/g++.dg/modules/p1689-2.exp.json |  16 ++
 gcc/testsuite/g++.dg/modules/p1689-3.C|  14 ++
 gcc/testsuite/g++.dg/modules/p1689-3.exp.json |  16 ++
 gcc/testsuite/g++.dg/modules/p1689-4.C|  14 ++
 gcc/testsuite/g++.dg/modules/p1689-4.exp.json |  14 ++
 gcc/testsuite/g++.dg/modules/p1689-5.C|  14 ++
 gcc/testsuite/g++.dg/modules/p1689-5.exp.json |  14 ++
 gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++
 gcc/testsuite/lib/modules.exp |  71 ++
 libcpp/charset.cc |  28 ++-
 libcpp/include/cpplib.h   |  12 +-
 libcpp/include/mkdeps.h   |  17 +-
 libcpp/init.cc|  13 +-
 libcpp/internal.h |   2 +
 libcpp/mkdeps.cc  | 149 +++-
 38 files changed, 773 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-f-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-f.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fi.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fj-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fj.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fjo-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fjo.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fo-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-fo.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-j-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-j.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-jo-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-jo.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-o-MD.C
 create mode 100644 gcc/testsuite/g++.dg/modules/depflags-o.C
 create mode 100644 gcc/testsuite/g++.dg/modules/p1689-1.C
 create mode 100644 gcc/te

[PATCH v4 2/3] libcpp: add a function to determine UTF-8 validity of a C string

[Ben Boeckel via Gcc]

This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.

libcpp/

* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
* internal.h: Add prototype for `_cpp_valid_utf8_str`.

Signed-off-by: Ben Boeckel 
---
 libcpp/charset.cc | 20 
 libcpp/internal.h |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index 324b5b19136..422cb52595c 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -1868,6 +1868,26 @@ _cpp_valid_utf8 (cpp_reader *pfile,
   return true;
 }
 
+/*  Detect whether a C-string is a valid UTF-8-encoded set of bytes. Returns
+`false` if any contained byte sequence encodes an invalid Unicode codepoint
+or is not a valid UTF-8 sequence. Returns `true` otherwise. */
+
+extern bool
+_cpp_valid_utf8_str (const char *name)
+{
+  const uchar* in = (const uchar*)name;
+  size_t len = strlen (name);
+  cppchar_t cp;
+
+  while (*in)
+{
+  if (one_utf8_to_cppchar (&in, &len, &cp))
+   return false;
+}
+
+  return true;
+}
+
 /* Subroutine of convert_hex and convert_oct.  N is the representation
in the execution character set of a numeric escape; write it into the
string buffer TBUF and update the end-of-string pointer therein.  WIDE
diff --git a/libcpp/internal.h b/libcpp/internal.h
index badfd1b40da..4f2dd4a2f5c 100644
--- a/libcpp/internal.h
+++ b/libcpp/internal.h
@@ -834,6 +834,8 @@ extern bool _cpp_valid_utf8 (cpp_reader *pfile,
 struct normalize_state *nst,
 cppchar_t *cp);
 
+extern bool _cpp_valid_utf8_str (const char *str);
+
 extern void _cpp_destroy_iconv (cpp_reader *);
 extern unsigned char *_cpp_convert_input (cpp_reader *, const char *,
  unsigned char *, size_t, size_t,
-- 
2.38.1

[PATCH v4 3/3] p1689r5: initial support

[Ben Boeckel via Gcc]

This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.

Support is communicated through the following three new flags:

- `-fdeps-format=` specifies the format for the output. Currently named
  `p1689r5`.

- `-fdeps-file=` specifies the path to the file to write the format to.

- `-fdep-output=` specifies the `.o` that will be written for the TU
  that is scanned. This is required so that the build system can
  correlate the dependency output with the actual compilation that will
  occur.

CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0)
using an experimental feature selection (to allow for future usage
evolution without committing to how it works today). While it remains
experimental, docs may be found in CMake's documentation for
experimental features.

Future work may include using this format for Fortran module
dependencies as well, however this is still pending work.

[P1689R5]: https://isocpp.org/files/papers/P1689R5.html
[cmake-experimental]: 
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst

TODO:

- header-unit information fields

Header units (including the standard library headers) are 100%
unsupported right now because the `-E` mechanism wants to import their
BMIs. A new mode (i.e., something more workable than existing `-E`
behavior) that mocks up header units as if they were imported purely
from their path and content would be required.

- non-utf8 paths

The current standard says that paths that are not unambiguously
represented using UTF-8 are not supported (because these cases are rare
and the extra complication is not worth it at this time). Future
versions of the format might have ways of encoding non-UTF-8 paths. For
now, this patch just doesn't support non-UTF-8 paths (ignoring the
"unambiguously represetable in UTF-8" case).

- figure out why junk gets placed at the end of the file

Sometimes it seems like the file gets a lot of `NUL` bytes appended to
it. It happens rarely and seems to be the result of some
`ftruncate`-style call which results in extra padding in the contents.
Noting it here as an observation at least.

libcpp/

* include/cpplib.h: Add cpp_deps_format enum.
(cpp_options): Add format field
(cpp_finish): Add dependency stream parameter.
* include/mkdeps.h (deps_add_module_target): Add new preprocessor
parameter used for C++ module tracking.
* init.cc (cpp_finish): Add new preprocessor parameter used for C++
module tracking.
* mkdeps.cc (mkdeps): Implement P1689R5 output.

gcc/

* doc/invoke.texi: Document -fdeps-format=, -fdep-file=, and
-fdep-output= flags.

gcc/c-family/

* c-opts.cc (c_common_handle_option): Add fdeps_file variable and
-fdeps-format=, -fdep-file=, and -fdep-output= parsing.
* c.opt: Add -fdeps-format=, -fdep-file=, and -fdep-output= flags.

gcc/cp/

* module.cc (preprocessed_module): Pass whether the module is
exported to dependency tracking.

gcc/testsuite/

* g++.dg/modules/depflags-f-MD.C: New test.
* g++.dg/modules/depflags-f.C: New test.
* g++.dg/modules/depflags-fi.C: New test.
* g++.dg/modules/depflags-fj-MD.C: New test.
* g++.dg/modules/depflags-fj.C: New test.
* g++.dg/modules/depflags-fjo-MD.C: New test.
* g++.dg/modules/depflags-fjo.C: New test.
* g++.dg/modules/depflags-fo-MD.C: New test.
* g++.dg/modules/depflags-fo.C: New test.
* g++.dg/modules/depflags-j-MD.C: New test.
* g++.dg/modules/depflags-j.C: New test.
* g++.dg/modules/depflags-jo-MD.C: New test.
* g++.dg/modules/depflags-jo.C: New test.
* g++.dg/modules/depflags-o-MD.C: New test.
* g++.dg/modules/depflags-o.C: New test.
* g++.dg/modules/p1689-1.C: New test.
* g++.dg/modules/p1689-1.exp.json: New test expectation.
* g++.dg/modules/p1689-2.C: New test.
* g++.dg/modules/p1689-2.exp.json: New test expectation.
* g++.dg/modules/p1689-3.C: New test.
* g++.dg/modules/p1689-3.exp.json: New test expectation.
* g++.dg/modules/p1689-4.C: New test.
* g++.dg/modules/p1689-4.exp.json: New test expectation.
* g++.dg/modules/p1689-5.C: New test.
* g++.dg/modules/p1689-5.exp.json: New test expectation.
* g++.dg/modules/modules.exp: Load new P1689 library routines.
* g++.dg/modules/test-p1689.py: New tool for validating P1689 output.
* lib/modules.exp: Support for validating P1689 outputs.

Signed-off-by: Ben Boeckel 
---
 gcc/c-family/c-opts.cc|  40 +++-
 gcc/c-family/c.opt|  12 +
 gcc/cp/module.cc  |   3 +-
 gcc/doc/invoke.texi   |  15 ++
 gcc/testsuite/g++.dg/modules/depflags-f

gcc-12-20221210 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-12-20221210.tar.xz   Complete GCC

  SHA256=7c06a6718393f4d50936dbe90950b35920efb108a09c99c4bb200c0c68a26e4f
  SHA1=f6857d2bc834df4cae2b6b5b2b5e6c2902fd359d

Diffs from 12-20221203 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.