Re: [PATCH v8 0/4] P1689R5 support

2023-09-19 Thread Jason Merrill via Gcc

On 9/1/23 09:04, Ben Boeckel wrote:

Hi,

This patch series 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 any
TU with `export import some_module;` is compiled first.

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

I've also added patches to include imported module CMI files and the
module mapper file as dependencies of the compilation. I briefly looked
into adding dependencies on response files as well, but that appeared to
need some code contortions to have a `class mkdeps` available before
parsing the command line or to keep the information around until one was
made.

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.

FWIW, Clang as taken an alternate approach with its `clang-scan-deps`
tool rather than using the compiler directly.

Thanks,

--Ben

---
v7 -> v8:

- rename `DEPS_FMT_` enum variants to `FDEPS_FMT_` to match the
   associated flag
- memory leak fix in the `join` specfunc implementation (also better
   comments), both from Jason
- formatting fix in `mkdeps.cc` for `write_make_modules_deps` assignment
- comments on new functions for P1689R5 implementation


Pushed, thanks!

Jason



Attempt to fix g++.dg tests failures in gnu-versioned-namespace mode

2023-09-19 Thread François Dumont via Gcc
I've configured libstdc++ with --enable-symvers=gnu-versioned-namespace 
and run make check-c++.


A number of failures are like this one:

/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: 
In function 'coro1 f()':
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C:9:1: 
error: 'operator new' is provided by 
'std::__8::__n4861::__coroutine_traits_impl::promise_type' 
{aka 'co
ro1::promise_type'} but is not usable with the function signature 'coro1 
f()'

compiler exited with status 1
FAIL: g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C  (test for 
errors, line 9)
FAIL: g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C (test for excess 
errors)

Excess errors:
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C:9:1: 
error: 'operator new' is provided by 
'std::__n4861::__coroutine_traits_impl::promise_type' {aka 
'coro1::promise_type'} but is not usable with the function signature 
'coro1 f()'


The '__8' is messing with expected output.

So I've added:

    # Ignore optional version namespace from libstdc++.
    regsub -all "std::__8::" $text "std::" text

in testsuite/lib/prune.exp prune_gcc_output.

But it had no impact, same failures.

What am I missing ?

Thanks,

François