Re: [PATCH v5 1/5] libcpp: reject codepoints above 0x10FFFF
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 codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such values.
It seems that this causes a bunch of testsuite failures from tests that
expect this limit to be checked elsewhere with a different diagnostic,
so I think the easiest thing is to fold this into _cpp_valid_utf8_str
instead, i.e.:
Make sense?
JasonFrom 296e9d1e16533979d12bd98db2937e396a0796f3 Mon Sep 17 00:00:00 2001
From: Ben Boeckel
Date: Sat, 10 Dec 2022 17:20:49 -0500
Subject: [PATCH] libcpp: add a function to determine UTF-8 validity of a C
string
To: gcc-patc...@gcc.gnu.org
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/internal.h | 2 ++
libcpp/charset.cc | 24
2 files changed, 26 insertions(+)
diff --git a/libcpp/internal.h b/libcpp/internal.h
index 9724676a8cd..48520901b2d 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,
diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index 3c47d4f868b..42a1b596c06 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -1864,6 +1864,30 @@ _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;
+
+ /* one_utf8_to_cppchar doesn't check this limit. */
+ if (cp > UCS_LIMIT)
+ 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
--
2.31.1
Re: Support for NOINLINE attribute
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
Thanks,
Harald
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
Hi Rimvydas,
Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
Von: "Rimvydas Jasinskas"
An: "Harald Anlauf"
Cc: "fortran"
Betreff: Re: Support for NOINLINE attribute
On Sat, Feb 11, 2023 at 11:26 PM Harald Anlauf wrote:
I am also not a native speaker, like many others contributing, but let
me quote the relevant orignal paragraph:
"The @code{noreturn} keyword tells the compiler to assume that
@code{fatal} cannot return. It can then optimize without regard to what
would happen if @code{fatal} ever did return. This makes slightly
better code. More importantly, it helps avoid spurious warnings of
uninitialized variables."
My reading of this original paragraph differs very much from the
intention I get from the shortened version. Would you please reread?
Same, from extend.texi, see gcc/testsuite/gfortran.dg/noreturn-3.f90
It is about marking dead conditional branches, so that the compiler
can prove proper initialization (no -Wmaybe-uninitialized given). It
should behave the same as in C frontend.
True. And that's the whole point (IMHO), not silencing the compiler.
Hmm both look the same to me, the silencing of false positive
diagnostics is already implied by spurious. To simplify I have
changed it in v2 to just:
"add a hint that a given function cannot return" documentation could
be expanded later.
But shouldn't we rather follow what the C family of compilers in the
first place does for a particular target? Most relevant libraries
for Fortran code are either C/C++ or Fortran anyway, including any
of the common MPI implementations, so should we care about Ada?
I agree with you. I have removed SUPPORTS_WEAK check and fixed
indentation in v2.
Regtested cleany on x86_64-pc-linux-gnu.
Regards,
Rimvydas
this version of the patch looks good to me, so it is basically OK
to commit.
There is one thing I cannot test, which is the handling of weak symbols
on other platforms. A quick glance at the C testcases suggests that
someone with access to either an NVPTX or MingGW target might tell
whether that particular target should be excluded. So I'd like to wait
for 24 hours for others to comment on this.
I see that you've signed-off your patch. Do you have commit rights?
Otherwise I'll commit for you. (I've CC'ed to gcc-patches@ for this
purpose.)
Thanks for the patch!
Harald
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 1/25/23 13:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
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)
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
index ebd30f63d81..dbd1b721616 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -18966,6 +18966,8 @@ module_state::do_import (cpp_reader *reader, bool
outermost)
dump () && dump ("CMI is %s", file);
if (note_module_cmi_yes || inform_cmi_p)
inform (loc, "reading CMI %qs", file);
+ /* Add the CMI file to the dependency tracking. */
+ deps_add_dep (cpp_get_deps (reader), file);
fd = open (file, O_RDONLY | O_CLOEXEC | O_BINARY);
e = errno;
}
[PATCH, committed] Fortran: error recovery after invalid use of CLASS variable [PR103475]
Dear all,
the attached simple and obvious patch fixes a NULL pointer dereference
on an invalid use of a CLASS variable.
Committed to mainline after regtesting on x86_64-pc-linux-gnu as
https://gcc.gnu.org/g:2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a
Thanks,
Harald
From 2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 13 Feb 2023 22:02:44 +0100
Subject: [PATCH] Fortran: error recovery after invalid use of CLASS variable
[PR103475]
gcc/fortran/ChangeLog:
PR fortran/103475
* primary.cc (gfc_expr_attr): Avoid NULL pointer dereference for
invalid use of CLASS variable.
gcc/testsuite/ChangeLog:
PR fortran/103475
* gfortran.dg/pr103475.f90: New test.
---
gcc/fortran/primary.cc | 2 +-
gcc/testsuite/gfortran.dg/pr103475.f90 | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr103475.f90
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 28ce5fea865..1bea17d44fe 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -2770,7 +2770,7 @@ gfc_expr_attr (gfc_expr *e)
{
gfc_symbol *sym = e->value.function.esym->result;
attr = sym->attr;
- if (sym->ts.type == BT_CLASS)
+ if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
{
attr.dimension = CLASS_DATA (sym)->attr.dimension;
attr.pointer = CLASS_DATA (sym)->attr.class_pointer;
diff --git a/gcc/testsuite/gfortran.dg/pr103475.f90 b/gcc/testsuite/gfortran.dg/pr103475.f90
new file mode 100644
index 000..6cce5e8ebf7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103475.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-O2 -Wall" }
+! PR fortran/103475 - ICE in gfc_expr_attr
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ end type
+ class(t) :: x ! { dg-error "must be dummy, allocatable or pointer" }
+ y = x() ! { dg-error "Cannot convert invalid class" }
+end
--
2.35.3
