Re: [PATCH v2 1/3] libcpp: reject codepoints above 0x10FFFF
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote: > Unicode does not support such values because they are unrepresentable > in > UTF-16. Wikipedia pointed me to RFC 3629, which was when UTF-8 introduced this restriction, whereas libcpp was implementing the higher upper limit from the earlier, superceded RFC 2279. The patch looks good to me, assuming it bootstraps and passes usual regression testing, but... > > 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..4d707277531 100644 > --- a/libcpp/ChangeLog > +++ b/libcpp/ChangeLog > @@ -1,3 +1,9 @@ > +2022-10-27 Ben Boeckel > + > + * include/charset.cc: Reject encodings of codepoints above > 0x10. > + UTF-16 does not support such codepoints and therefore all > Unicode > + rejects such values. > + > 2022-10-19 Lewis Hyatt ...AIUI we now put ChangeLog entries in the blurb part of the patch, so that server-side git scripts add them to the actual ChangeLog file. Does the patch pass: ./contrib/gcc-changelog/git_check_commit.py ? Thanks Dave > > * include/cpplib.h (struct cpp_string): Use new > "string_length" GTY. > diff --git a/libcpp/charset.cc b/libcpp/charset.cc > index 12a398e7527..e9da6674b5f 100644 > --- a/libcpp/charset.cc > +++ b/libcpp/charset.cc > @@ -216,7 +216,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 +320,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);
Re: [PATCH v2 2/3] libcpp: add a function to determine UTF-8 validity of a C string
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 sufficient. > > Signed-off-by: Ben Boeckel > --- > libcpp/ChangeLog | 6 ++ > libcpp/charset.cc | 18 ++ > libcpp/internal.h | 2 ++ > 3 files changed, 26 insertions(+) > > diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog > index 4d707277531..4e2c7900ae2 100644 > --- a/libcpp/ChangeLog > +++ b/libcpp/ChangeLog > @@ -1,3 +1,9 @@ > +2022-10-27 Ben Boeckel > + > + * include/charset.cc: Add `_cpp_valid_utf8_str` which > determines > + whether a C string is valid UTF-8 or not. > + * include/internal.h: Add prototype for > `_cpp_valid_utf8_str`. > + > 2022-10-27 Ben Boeckel > > * include/charset.cc: Reject encodings of codepoints above > 0x10. The patch looks good to me, with the same potential caveat that you might need to move the ChangeLog entry from the patch "body" to the leading blurb, to satisfy: ./contrib/gcc-changelog/git_check_commit.py Thanks Dave
Re: [PATCH v2 2/3] libcpp: add a function to determine UTF-8 validity of a C string
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 sufficient. > > > > Signed-off-by: Ben Boeckel > > --- > > libcpp/ChangeLog | 6 ++ > > libcpp/charset.cc | 18 ++ > > libcpp/internal.h | 2 ++ > > 3 files changed, 26 insertions(+) > > > > diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog > > index 4d707277531..4e2c7900ae2 100644 > > --- a/libcpp/ChangeLog > > +++ b/libcpp/ChangeLog > > @@ -1,3 +1,9 @@ > > +2022-10-27 Ben Boeckel > > + > > + * include/charset.cc: Add `_cpp_valid_utf8_str` which > > determines > > + whether a C string is valid UTF-8 or not. > > + * include/internal.h: Add prototype for > > `_cpp_valid_utf8_str`. > > + > > 2022-10-27 Ben Boeckel > > > > * include/charset.cc: Reject encodings of codepoints above > > 0x10. > > The patch looks good to me, with the same potential caveat that you > might need to move the ChangeLog entry from the patch "body" to the > leading blurb, to satisfy: > ./contrib/gcc-changelog/git_check_commit.py Ah, I had missed that. Now fixed locally for patches 1 and 2; will be in v3 pending some time for further reviews. THanks, --Ben
Re: [PATCH v2 3/3] p1689r5: initial support
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/modules/modules.exp
> @@ -28,6 +28,7 @@
> # { dg-module-do [link|run] [xfail] [options] } # link [and run]
>
> load_lib g++-dg.exp
> +load_lib modules.exp
>
> # If a testcase doesn't have special options, use these.
> global DEFAULT_CXXFLAGS
> @@ -237,6 +238,13 @@ proc cleanup_module_files { files } {
> }
> }
>
> +# delete the specified set of dep files
> +proc cleanup_dep_files { files } {
> +foreach file $files {
> + file_on_host delete $file
> +}
> +}
> +
> global testdir
> set testdir $srcdir/$subdir
> proc srcdir {} {
> @@ -310,6 +318,7 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
> set std_list [module-init $src]
> foreach std $std_list {
> set mod_files {}
> + set dep_files {}
> global module_do
> set module_do {"compile" "P"}
> set asm_list {}
> @@ -346,6 +355,8 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
> set mod_files [find $DEFAULT_REPO *.gcm]
> }
> cleanup_module_files $mod_files
> +
> + cleanup_dep_files $dep_files
> }
> }
> }
These `cleanup_dep_files` hunks are leftovers from my attempts at
getting the P1689 and flags tests working; they'll be gone in v3.
--Ben
--target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?
Hi! While checking my bot build logs, I noticed that GCC configured for --target=powerpc64-linux_altivec will pull in linux64.h and linuxaltivec.h . linux64.h * Will "#define TARGET_USES_LINUX64_OPT 1" (to make static void rs6000_linux64_override_options() available in rs6000.cc). * Will "#define SUBSUBTARGET_OVERRIDE_OPTIONS" to use rs6000_linux64_override_options(). linuxaltivec.h OTOH * Will undef / "#define SUBSUBTARGET_OVERRIDE_OPTIONS rs6000_altivec_abi = 1" and thus no longer use rs6000_linux64_override_options() * That triggers a warning (unused-function). To silence that warning, should linuxaltivec.h undefine TARGET_USES_LINUX64_OPT? Or set rs6000_altivec_abi=1 and call rs6000_linux64_override_options()? Thanks, Jan-Benedict -- signature.asc Description: PGP signature
Re: --target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?
Hi! On Fri, Oct 28, 2022 at 07:34:24PM +0200, Jan-Benedict Glaw wrote: > While checking my bot build logs, I noticed that GCC configured for > --target=powerpc64-linux_altivec will pull in linux64.h and > linuxaltivec.h . > > linux64.h > * Will "#define TARGET_USES_LINUX64_OPT 1" (to make static void > rs6000_linux64_override_options() available in rs6000.cc). > * Will "#define SUBSUBTARGET_OVERRIDE_OPTIONS" to use > rs6000_linux64_override_options(). > > linuxaltivec.h OTOH > * Will undef / "#define SUBSUBTARGET_OVERRIDE_OPTIONS rs6000_altivec_abi = > 1" > and thus no longer use rs6000_linux64_override_options() > * That triggers a warning (unused-function). > > To silence that warning, should linuxaltivec.h undefine > TARGET_USES_LINUX64_OPT? Or set rs6000_altivec_abi=1 and call > rs6000_linux64_override_options()? Why do you use powerpc64-linux_altivec? This things (normally spelled with a dash, not and underscore, btw) was made for 32-bit targets. It never has done anything useful for 64-bit targets, afaik? (And not for 32-bit targets either really, but that is another issue.) Segher
Re: --target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?
Hi! On Fri, 2022-10-28 14:19:10 -0500, Segher Boessenkool wrote: > On Fri, Oct 28, 2022 at 07:34:24PM +0200, Jan-Benedict Glaw wrote: > > While checking my bot build logs, I noticed that GCC configured for > > --target=powerpc64-linux_altivec will pull in linux64.h and > > linuxaltivec.h . > > > > linux64.h > > * Will "#define TARGET_USES_LINUX64_OPT 1" (to make static void > > rs6000_linux64_override_options() available in rs6000.cc). > > * Will "#define SUBSUBTARGET_OVERRIDE_OPTIONS" to use > > rs6000_linux64_override_options(). > > > > linuxaltivec.h OTOH > > * Will undef / "#define SUBSUBTARGET_OVERRIDE_OPTIONS rs6000_altivec_abi > > = 1" > > and thus no longer use rs6000_linux64_override_options() > > * That triggers a warning (unused-function). > > > > To silence that warning, should linuxaltivec.h undefine > > TARGET_USES_LINUX64_OPT? Or set rs6000_altivec_abi=1 and call > > rs6000_linux64_override_options()? > > Why do you use powerpc64-linux_altivec? This things (normally spelled > with a dash, not and underscore, btw) was made for 32-bit targets. It > never has done anything useful for 64-bit targets, afaik? Because it's listed in ./contrib/config-list.mk: /var/cache/git/gcc [master] # make -f contrib/config-list.mk show | tr ' ' $'\n' | grep altivec powerpc-eabisimaltivec powerpc-eabialtivec powerpc64-linux_altivec > (And not for 32-bit targets either really, but that is another issue.) It seems to be on the target list since the very beginning, when config-list.mk was created by Joern Rennecke. So somebody cared about this configuration I guess? If this configuration isn't ment to be used, we'd just drop it from the list I guess. MfG, JBG -- signature.asc Description: PGP signature
Re: --target=powerpc64-linux_altivec: Use rs6000_linux64_override_options()?
On Fri, Oct 28, 2022 at 10:07:41PM +0200, Jan-Benedict Glaw wrote:
> On Fri, 2022-10-28 14:19:10 -0500, Segher Boessenkool
> wrote:
> > Why do you use powerpc64-linux_altivec? This things (normally spelled
> > with a dash, not and underscore, btw) was made for 32-bit targets. It
> > never has done anything useful for 64-bit targets, afaik?
>
> Because it's listed in ./contrib/config-list.mk:
>
> /var/cache/git/gcc [master] # make -f contrib/config-list.mk show | tr ' '
> $'\n' | grep altivec
> powerpc-eabisimaltivec
> powerpc-eabialtivec
> powerpc64-linux_altivec
Huh. Okay, that is a bug. Has that target ever worked (or
alternatively, has it ever existed at all, other than it is recognised
by config.gcc by not very tight REs)?
> It seems to be on the target list since the very beginning, when
> config-list.mk was created by Joern Rennecke. So somebody cared about
> this configuration I guess?
No idea. rs6000_altivec_abi is always forced on on any linux
configuration that has VMX or VSX or 64 bit enabled:
===
/* The AltiVec ABI is the default for PowerPC-64 GNU/Linux. For
PowerPC-32 GNU/Linux, -maltivec implies the AltiVec ABI. It can
be explicitly overridden in either case. */
if (TARGET_ELF)
{
if (!OPTION_SET_P (rs6000_altivec_abi)
&& (TARGET_64BIT || TARGET_ALTIVEC || TARGET_VSX))
{
if (main_target_opt != NULL &&
!main_target_opt->x_rs6000_altivec_abi)
error ("target attribute or pragma changes AltiVec ABI");
else
rs6000_altivec_abi = 1;
}
}
===
> If this configuration isn't ment to be used, we'd just drop it from
> the list I guess.
Yeah, the config makes no sense.
Thanks,
Segher
gcc-11-20221028 is now available
Snapshot gcc-11-20221028 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20221028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision f2298bd50109e5460e8949290b5337ec28310e91 You'll find: gcc-11-20221028.tar.xz Complete GCC SHA256=66db3e6232f3a853df3c1e924504dacaeb260881e60744486a2cb55170b2c7be SHA1=dd28abe0fe1f198cca26b2a25517349480688469 Diffs from 11-20221021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
