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
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 d
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 .
> >
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 stati
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
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
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
> > ---
> > libc
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 ++
> lib
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,