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_s
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 out
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
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
---
li
On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we should not try to simplify ISHFTC if the SIZE argument
> is known to be outside the allowed range. It's better to
> generate an error by terminating the simplification.
>
> Regtested on x86_64-pc-linux-
Dear all,
I'm submitting the attached patch on behalf of Steve.
It fixes an ICE that occurs on an obscure use of a
statement function as argument to that function.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From f717054e7d656588650f6d4fd5a03840c6dc9a9c Mon Sep 17 00:00:0
Dear all,
we should not try to simplify ISHFTC if the SIZE argument
is known to be outside the allowed range. It's better to
generate an error by terminating the simplification.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From ae4438537fbc2ed04f3b0fb32d4e02b0ed6977a1 Mon
Hi Katherine,
Is there some kind of "getting started" guide?
There's https://gcc.gnu.org/wiki/GFortranHacking which has some
pointers. It could also use a bit of an update (file names are now
.cc instead of .c :-)
Best regards
Thomas
On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote:
> On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
> > I was thinking I might try to contribute when I retire, though that may be
> > in a year or two. But it's been a very long time since I dove into a large
> > softwa
On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
I was thinking I might try to contribute when I retire, though that may be in a year or
two. But it's been a very long time since I dove into a large software project and it's
intimidating. I do know C (really C++, I haven't
On 12/8/22 9:25 AM, Tobias Burnus wrote:
Hi,
On 08.12.22 17:27, Steve Kargl via Fortran wrote:
On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
Other than Benson, I have received no sign of any interest from
gfortran
developers to adopt a teaming/collaboration platform. I
Hi Julian,
On 10.12.22 13:10, Julian Brown wrote:
On Thu, 8 Dec 2022 13:04:20 +0100
Tobias Burnus wrote:
All in all, I am fine with the patch - but I spotted some issues.
...
I believe this patch covers all the above cases (hopefully
appropriately generalised), at least for Fortran. I haven'
On Thu, 8 Dec 2022 13:04:20 +0100
Tobias Burnus wrote:
> All in all, I am fine with the patch - but I spotted some issues.
>
> First, I think you need to set for some error cases mark = 0 to avoid
> duplicated errors. Namely:
>
>! Outputs the error twice ('Symbol ‘y’ present on multiple
> c
13 matches
Mail list logo
