On Sun, May 11, 2025 at 10:34:11 +0200, Thomas Koenig via Gcc wrote:
> 2) Dump to standard output and check for the presence of certain
> regexps, ignoring anything else. Again, this is something I don't
> know how to do.
This is…fraught with peril and fiddliness. If the test can stomach some
C++
On Tue, Mar 04, 2025 at 07:53:51 +, vspefs wrote:
> By the way, what's stop us from having compiler options like
> `g++ -Rgcm.cache -Rsomewhere/else/gcm.cache` to specify CMI repo path, like
> `-I`
> for include paths? It could be useful for projects with complex folder
> structure, as build t
Hi,
I'm Ben and implemented modules support in CMake, authored P1689 itself,
its support in GCC, and helped wrangle its support into clang and MSVC.
I encourage you to read this paper:
https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html
which describes the strategy CMake
On Sat, Mar 01, 2025 at 20:01:21 +, vspefs wrote:
> Supporting C++ modules is easy, but I don't think "properly" is possible for
> any
> build system under current circumstances. Industrial consensus needed for many
> subjects:
I believe CMake is the furthest in this regard (though I haven't
On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
> I read a few mails from the autoconf thread. I'll try to read all now.
> However,
> a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
> Autotools now? The whole Autotools build system seems to be on a very slow
>
On Fri, Feb 28, 2025 at 07:59:00 -0800, NightStrike via Gcc wrote:
> Could your approach simultaneously be used to have better dependency
> information for Fortran modules? I feel like there’s at least some overlap
> there.
P1689 is also intended to be suitable for Fortran (CMake uses it for its
F
On Fri, Feb 28, 2025 at 13:54:45 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > > In POSIX make, including GNU Make, if a command doesn't modify the
> > > modification time of the target then that target is not considere
On Fri, Feb 28, 2025 at 13:07:04 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 18:05 +0100, Ben Boeckel via Gcc wrote:
> > Note that one thing that is missing is ninja's `restat = 1` feature.
> > This "restats" the output for the associated rule (probably spelled
On Sun, Feb 16, 2025 at 22:59:45 +0100, Ben Boeckel wrote:
> But we are finally at a point where named modules can be experimented
> with. The timeline has been (roughly):
>
> - 2019 Feb: pushing to get dependency scanning possible (I have patches
> to CMake and GCC to proof-of
Ugh, sorry. the lack of Subject/References broke threading and I missed
this continuation.
On Wed, Feb 12, 2025 at 22:46:23 +, Frederick Virchanza Gotham via Gcc
wrote:
> I think it might be a possibility given how compiler vendors (and also
> vendors of tools like CMake) aren't really gettin
On Wed, Feb 12, 2025 at 09:51:36 +, Frederick Virchanza Gotham via Gcc
wrote:
> This would be an alternative to modules (seeing as how modules might
> become deprecated in the future).
If this is the case, no one has informed the stakeholders in the C++
committee (SG2, EWG, SG15, likely many
On Mon, Jan 13, 2025 at 01:27:17 +, Hao Liu via Gcc wrote:
> I'm new to GCC community, and try to contribute some patches.
> I am having trouble setting git send-email with Outlook on Linux. Does
> anyone have any successful experiences to share?
I don't believe Outlook is well-suited for send
On Tue, Oct 01, 2024 at 18:06:35 +0200, Richard Biener via Gcc wrote:
> Analyze where the compile time is spent and where memory is spent.
> Identify unfitting data structures and algorithms causing the issue.
> Replace with better ones. That’s what I do for these kind of issues
> in the middle en
On Fri, Sep 06, 2024 at 09:30:26 -0400, David Malcolm wrote:
> On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote:
> > Does this have (additional) implications for caching tools and
> > modules?
> > They cache diagnostic output, but if these other paths showing u
On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote:
> Hello,
>
> I'm looking at #pragma once behavior among the major C/C++ compilers as
> part of a proposal paper for standardizing #pragma once. (This is
> apparently a very controversial topic)
>
> To put my question up-front: Would GCC
On Tue, Sep 03, 2024 at 16:53:43 +0100, Iain Sandoe wrote:
> I think that might be a misunderstanding on the part of the author;
> AFAIU both GCC and MSVC _do_ require access to the sources at BMI
> consume-time to give decent diagnostics. I think that there might be
> confusion because the compi
On Fri, Aug 09, 2024 at 11:48:44 +0200, Alejandro Colomar via Gcc wrote:
> On Fri, Aug 09, 2024 at 10:31:55AM GMT, Martin Uecker wrote:
> > BTW: Double evaluation is not only a problem for semantics, but also because
> > it can cause long compile times, cf. the 45 MB macro expansion example
> > in
On Fri, Jul 05, 2024 at 22:15:44 +0200, Emanuele Torre via Gcc wrote:
> That is 6.7.3.1p3:
>
>
>
> In what follows, a pointer expression E is said to be based on object P
> if (at some sequence point in the execution of B prior to the
> evaluation of E) modifying P to point to a copy of
On Tue, May 07, 2024 at 16:17:24 +, Joseph Myers via Gcc wrote:
> I'd say we have two kinds of patch submission (= two kinds of pull request
> in a pull request workflow) to consider in the toolchain, and it's
> important that a PR-based system supports both of them well (and supports
> a su
On Sun, May 05, 2024 at 08:22:12 +0300, Benson Muite wrote:
> On 04/05/2024 22.56, Ben Boeckel via Overseers wrote:
> > As a fellow FOSS maintainer I definitely appreciate the benefit of being
> > email-based (`mutt` is far better at wrangling notifications from
> > ump
On Wed, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote:
> On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
> > Do you (or others) have any thoughts about GitLab FOSS?
>
> The gitlab "community edition" still feels not very much "community".
> We could run our own instance, but i
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> Hi,
>
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"
>(timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys;
On Mon, Oct 09, 2023 at 19:46:37 -0400, Paul Koning wrote:
>
>
> > On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc wrote:
> >
> > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> >> I'm seeing these tracebacks for several cases across t
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"
>(timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert s
On Thu, Oct 05, 2023 at 12:59:21 +0100, Sergei Trofimovich via Gcc wrote:
> Sounds good. Do you have any preference over specific syntax? My
> suggestions would be:
>
> 1. `-fmacro-prefix-map=file-name`: if `file-name` there is not in `key=val`
>format then treat it as file
> 2. `-fmacro-prefi
On Wed, Oct 04, 2023 at 22:19:32 +0100, Sergei Trofimovich via Gcc wrote:
> The prototype that creates equivalent of the following commands does
> work for smaller packages:
>
>
> -fmacro-prefix-map=/nix/store/y8wfrgk7br5rfz4221lfb9v8w3n0cnyd-glibc-2.37-8-dev=/nix/store/ee
On Tue, Sep 19, 2023 at 17:33:34 -0400, Jason Merrill wrote:
> Pushed, thanks!
Thanks!
Is there a process I can use to backport this to GCC 13?
--Ben
-5.exp.ddi: 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
---
gc
`:|` syntax output
when generating modules.
Signed-off-by: Ben Boeckel
---
gcc/cp/mapper-client.cc | 5 +
gcc/cp/mapper-client.h| 1 +
gcc/cp/module.cc | 18 -
.../g++.dg/modules/depreport-2.modmap
/modules/test-depfile.py: New tool for validating depfile
information.
* lib/modules.exp: Support for validating depfile contents.
Signed-off-by: Ben Boeckel
---
gcc/cp/module.cc | 3 +
gcc/testsuite/g++.dg/modules/depreport-1_a.C | 10 +
gcc/testsuite/g
n all
arguments.
Signed-off-by: Ben Boeckel
---
gcc/gcc.cc | 23 +++
1 file changed, 23 insertions(+)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index fdfac0b4fe4..4c4e81dee50 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -447,6 +447,7 @@ static const char *greater_than_spec_func
moval 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 (4):
spec: add
On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote:
> I suppose for bootstrapping we could disable ISL during stage1 since
> it enables an optional feature only. Other than that GCC only
> requires a C++11 compiler for building, so ISL breaks that constraint
> with requiring C++17.
Note
Hi,
I tried adding isl 0.26 to a 13.2 GCC build using Iain's macOS aarch64
patches:
https://github.com/iains/gcc-13-branch
It seems that the bootstrap's `CXX='g++ -std=c++11'` confuses isl's
build where C++17 is expected to work by disabling C++17 behind its
back. Should GCC not add this fla
On Thu, Jul 27, 2023 at 18:13:48 -0700, Jason Merrill wrote:
> On 7/23/23 20:26, Ben Boeckel wrote:
> > Sure, *CMake* knows them, but the *build tool* needs to be told
> > (typically `make` or `ninja`) because it is what is actually executing
> > the build graph. The way th
On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote:
> It occurs to me that the model I am envisioning is similar to CMake's object
> libraries. Object libraries are a convenient name for a bunch of object
> files.
> IIUC they're linked by naming the individual object files (or I think
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
> On 7/19/23 20:47, Ben Boeckel wrote:
> > But it is inhibiting distributed builds because the distributing tool
> > would need to know:
> >
> > - what CMIs are actually imported (here, "read the module
an be sent.
And relocatable is probably fine. How does it interact with reproducible
builds? Or are GCC CMIs not really something anyone should consider for
installation (even as a "here, maybe this can help consumers"
mechanism)?
> On 7/18/23 20:01, Ben Boeckel wrote:
> > Ma
On Tue, Jul 18, 2023 at 16:52:44 -0400, Jason Merrill wrote:
> On 6/25/23 12:36, Ben Boeckel wrote:
> > On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
> >> On 6/22/23 22:45, Ben Boeckel wrote:
> >>> On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill
`:|` syntax output
when generating modules.
Signed-off-by: Ben Boeckel
---
gcc/cp/mapper-client.cc | 5 +
gcc/cp/mapper-client.h| 1 +
gcc/cp/module.cc | 18 -
.../g++.dg/modules/depreport-2.modmap
-5.exp.ddi: 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
---
gc
/modules/test-depfile.py: New tool for validating depfile
information.
* lib/modules.exp: Support for validating depfile contents.
Signed-off-by: Ben Boeckel
---
gcc/cp/module.cc | 3 +
gcc/testsuite/g++.dg/modules/depreport-1_a.C | 10 +
gcc/testsuite/g
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 (4):
spec: add a spec function to join
n all
arguments.
Signed-off-by: Ben Boeckel
---
gcc/gcc.cc | 15 +++
1 file changed, 15 insertions(+)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index fdfac0b4fe4..44433b80d61 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -447,6 +447,7 @@ static const char *greater_than_spec_func (int, const
On Fri, Jun 23, 2023 at 14:31:17 -0400, Jason Merrill wrote:
> On 6/20/23 15:46, Ben Boeckel wrote:
> > On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> >> On 1/25/23 13:06, Ben Boeckel wrote:
>
> >>> Header units (including the standard library he
On Fri, Jun 23, 2023 at 10:44:11 -0400, Jason Merrill wrote:
> On 1/25/23 16:06, Ben Boeckel wrote:
> > It affects the build, and if used as a static file, can reliably be
> > tracked using the `-MF` mechanism.
>
> Hmm, this seems a bit like making all .o depend on the Makef
On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
> On 6/22/23 22:45, Ben Boeckel wrote:
> > On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
> >> On 1/25/23 16:06, Ben Boeckel wrote:
> >>> They affect the build, so report them via `-MF` mechan
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
> On 1/25/23 16:06, Ben Boeckel wrote:
> > They affect the build, so report them via `-MF` mechanisms.
>
> Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is neute
libcpp/
* charset.cc: Allow `UCS_LIMIT` in UTF-8 strings.
Reported-by: Damien Guibouret
Fixes: c1dbaa6656a (libcpp: reject codepoints above 0x10, 2023-06-06)
Signed-off-by: Ben Boeckel
---
libcpp/charset.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libcpp
On Tue, Jun 20, 2023 at 21:16:40 +0200, Damien Guibouret wrote:
> I think the comparison should be ">" instead of ">=" as 0x10 seems a
> valid value (Unicode says value above 0x10 is invalid).
> Other tests around same value in this file are using ">".
Ah, good catch. I'll make a separate
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> On 1/25/23 13:06, Ben Boeckel wrote:
> > - header-unit information fields
> >
> > Header units (including the standard library headers) are 100%
> > unsupported right now because the `-E` mechanism wants
On Mon, Jun 19, 2023 at 17:33:58 -0400, Jason Merrill wrote:
> On 5/12/23 10:24, Ben Boeckel wrote:
> > `file` can be omitted (the `output_stream` will be used then). I *think*
> > I see that adding:
> >
> > %{fdeps_file:-fdeps-file=%{!o:%b.ddi}%{o*:%.ddi%*}}
On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote:
> I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g.
>
> FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors)
> Excess errors:
> /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.C:9:1: internal
> compiler err
On Fri, Jun 16, 2023 at 15:48:59 -0400, Ben Boeckel wrote:
> On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote:
> > This patch series causes ICEs on arm-linux-gnueabihf. Would you
> > please investigate? Please let me know if you need any in reproducing
> > these.
On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote:
> This patch series causes ICEs on arm-linux-gnueabihf. Would you
> please investigate? Please let me know if you need any in reproducing
> these.
Finally back at it. I tried on aarch64, but wasn't able to reproduce the
errors (alas,
On Thu, Jun 08, 2023 at 04:06:24 +, waffl3x via Gcc wrote:
> I would like to boldly suggest implementing P0847 should be targeted at
> GCC14. In my anecdotal experiences, this feature is very important to
> people, and very important to myself, I believe it should be a priority.
>
> I am not s
(make_mapper, get_mapper): Pass the dependency
tracking class down.
Signed-off-by: Ben Boeckel
---
gcc/cp/mapper-client.cc | 4
gcc/cp/mapper-client.h | 1 +
gcc/cp/module.cc| 18 +-
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/gcc/cp/mapper
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
---
gc
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
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Signed-off-by: Ben Boeckel
---
gcc/cp/module.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
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 (4):
libcpp: reje
On Thu, May 18, 2023 at 09:25:04 -0400, Paul Smith wrote:
> On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote:
> > FWIW, this is only going to get worse with C++ modules.
>
> There's no reason it should. Of course the right answer is to tell
> people to fix their bu
On Wed, May 17, 2023 at 15:48:09 -0400, Paul Smith wrote:
> More frustratingly, Clang has made some poor decisions around
> "compatibility": they tried to leverage the GNU ecosystem by emulating
> GCC features and arguments but sometimes break things. The most
Alas, the cost of trying to make a c
On Mon, Feb 13, 2023 at 13:33:50 -0500, Jason Merrill wrote:
> Both this and the mapper dependency patch seem to cause most of the
> modules testcases to crash; please remember to run the regression tests
> (https://gcc.gnu.org/contribute.html#testing)
Fixed for v6. `cpp_get_deps` can return `NU
On Mon, Feb 13, 2023 at 10:53:17 -0500, Jason Merrill wrote:
> On 1/25/23 13:06, Ben Boeckel wrote:
> > Unicode does not support such values because they are unrepresentable in
> > UTF-16.
> >
> > libcpp/
> >
> > * charset.cc: Reject encodings of co
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> I notice that the actual flags are all -fdep-*, though some of them are
> -fdeps-* here, and the internal variables all seem to be fdeps_*. I
> lean toward harmonizing on "deps", I think.
Done.
> I don't love the three separate opt
On Fri, Feb 03, 2023 at 09:10:21 +, Jonathan Wakely wrote:
> On Fri, 3 Feb 2023 at 08:58, Jonathan Wakely wrote:
> > On Fri, 3 Feb 2023, 04:09 Andrew Pinski via Gcc, wrote:
> >> On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
> >> wrote:
> >> >
On Thu, Feb 02, 2023 at 21:24:12 +0100, Harald Anlauf wrote:
> Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisi
On Wed, Jan 25, 2023 at 16:06:31 -0500, Ben Boeckel wrote:
> 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
> n
(make_mapper, get_mapper): Pass the dependency
tracking class down.
Signed-off-by: Ben Boeckel
---
gcc/cp/mapper-client.cc | 4
gcc/cp/mapper-client.h | 1 +
gcc/cp/module.cc| 18 +-
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/gcc/cp/mapper
ctation.
* 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
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Signed-off-by: Ben Boeckel
---
gcc/cp/module.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
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
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 f7ae12ea5a2..616be9d02ee 100644
--- a/libcpp/charset.cc
+++ b/libcpp/c
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 s
On Wed, Dec 21, 2022 at 19:33:48 +0100, Alejandro Colomar via Gcc wrote:
> I've long had this wish: an option similar to -std, but which would not
> specify
> the standard. Rather, mark a requirement that the standard be at least a
> version.
>
> This would be especially useful for libraries,
ctation.
* 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
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/c
tream = 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
p1689
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
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix
> real-world bugs that would be caused if Clang becomes overly pedantic by
> default here. And the probability of introducing real-world bugs is
> essentially zero.
FWIW,
ctation.
* 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
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..e130bc01f48 100644
--- a/libcpp/charset.cc
+++ b/libcpp/c
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
t 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-fami
On Tue, Nov 01, 2022 at 08:57:37 -0600, Tom Tromey wrote:
> >>>>> "Ben" == Ben Boeckel via Gcc-patches writes:
>
> Ben> - `-fdeps-file=` specifies the path to the file to write the format to.
>
> I don't know how this output is intended t
On Thu, Oct 27, 2022 at 19:16:44 -0400, Ben Boeckel wrote:
> diff --git a/gcc/testsuite/g++.dg/modules/modules.exp
> b/gcc/testsuite/g++.dg/modules/modules.exp
> index afb323d0efd..7fe8825144f 100644
> --- a/gcc/testsuite/g++.dg/modules/modules.exp
> +++ b/gcc/testsuite/g++.dg/modu
On Fri, Oct 28, 2022 at 08:59:16 -0400, David Malcolm wrote:
> On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> > This simplifies the interface for other UTF-8 validity detections
> > when a
> > simple "yes" or "no" answer is suffic
Unicode does not support such values because they are unrepresentable in
UTF-16.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index 18d5bcceaf0
ed 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.
Signed-off-by: Ben Boeckel
---
gcc/ChangeLog | 5 +
gcc/c-family/ChangeLog
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 18 ++
libcpp/internal.h | 2 ++
3 files changed, 26 inserti
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 a
On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote:
> Oops, I was thinking this was in gcc as well. In libcpp there's
> _cpp_valid_utf8 (which calls one_utf8_to_cppchar).
This routine has a lot more logic (including UCN decoding) and the
`one_utf8_to_cppchar` also supports out-of-bounds
On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote:
> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> > David Malcolm would probably know best about JSON wrangling.
>
> Unfortunately our JSON output doesn't make any guarantees about the
> ordering of keys within an object, so th
On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote:
> On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> > Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc?
>
> I can look at factoring that out. I'll have to decode its logic to se
On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> On 10/4/22 11:12, Ben Boeckel wrote:
> > 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` file
On Tue, Oct 04, 2022 at 21:12:03 +0200, Harald Anlauf wrote:
> Am 04.10.22 um 17:12 schrieb Ben Boeckel:
> > 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` file
e:
https://reviews.llvm.org/D134269
with the same flags (though using my old `trtbd` spelling for the
format name).
Thanks,
--Ben
Ben Boeckel (1):
p1689r5: initial support
gcc/ChangeLog | 9 ++
gcc/c-family/ChangeLog | 6 +
gcc/c-family/c-opts.cc | 40 ++-
ed 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.
Signed-off-by: Ben Boeckel
---
gcc/ChangeLog | 9 ++
gcc/c-family/ChangeLog | 6 +
gcc/c-family/c-opts.cc
e:
https://reviews.llvm.org/D134269
with the same flags (though using my old `trtbd` spelling for the
format name).
Thanks,
--Ben
Ben Boeckel (1):
p1689r5: initial support
gcc/ChangeLog | 9 ++
gcc/c-family/ChangeLog | 6 +
gcc/c-family/c-opts.cc | 40 ++-
1 - 100 of 110 matches
Mail list logo
